عیب‌یابی مشکلات DNS و آی‌پی ثابت: راهنمای گام‌به‌گام

عیب‌یابی DNS و ریشه‌یابی مشکلات مربوط به آی‌پی ثابت، یکی از پرتکرارترین کارهای روزمره‌ی هر کسی است که با شبکه سروکار دارد؛ از مدیر سیستمی که ده‌ها سرور را نگه می‌دارد تا کاربری که تازه یک آی‌پی ثابت روی رایانه‌ی خانگی‌اش گرفته و انتظار دارد همه‌چیز بی‌نقص کار کند. واقعیت این است که وقتی «اینترنت کار نمی‌کند»، مشکل تقریباً هیچ‌وقت یک چیز مبهم و جادویی نیست؛ بلکه یک نقص مشخص در یکی از لایه‌های اتصال است که با یک روش منظم می‌توان دقیقاً به آن رسید. هدف این راهنما این است که به‌جای حدس‌زدن‌های تصادفی، یک روش گام‌به‌گام و لایه‌به‌لایه به شما بدهد.

در این مقاله ابتدا یک مدل ذهنی هفت‌لایه معرفی می‌کنیم که هر بار که چیزی از کار افتاد، بتوانید از پایین به بالا آن را دنبال کنید: از سلامت فیزیکی کابل و کارت شبکه تا درست‌بودن آدرس، ماسک زیرشبکه، دروازه، مسیریابی، و در نهایت تبدیل نام به آدرس (همان کاری که DNS انجام می‌دهد). سپس با ابزارهای استانداردی مثل ipconfig /all، ip addr، ping، tracert، nslookup و dig یاد می‌گیرید هر لایه را جداگانه بیازمایید و خطا را دقیقاً محدود کنید.

تمرکز اصلی روی دو دسته مشکل است که بیش از همه سردرگم‌کننده‌اند: خطای DNS (وقتی نام دامنه به آدرس تبدیل نمی‌شود یا اشتباه تبدیل می‌شود) و مشکل آی‌پی ثابت (وقتی آدرس ثابتی که تعیین کرده‌اید کار نمی‌کند، بعد از ری‌استارت می‌پرد، یا با دستگاه دیگری تعارض پیدا می‌کند). در پایان یک فلوچارت به‌صورت فهرست مرتب و یک چک‌لیست کپی-پیست خواهید داشت که می‌توانید هر بار عیناً دنبالش کنید.

#روش لایه‌ای: چرا باید از پایین شروع کنید

بزرگ‌ترین اشتباه در عیب‌یابی شبکه این است که آدم از وسط یا از بالا شروع می‌کند. مثلاً مرورگر خطای «سایت پیدا نشد» می‌دهد و کاربر بلافاصله سراغ عوض‌کردن DNS می‌رود، در حالی که شاید اصلاً کابل شبکه شل شده یا آدرس آی‌پی دستگاه با یک دستگاه دیگر تعارض دارد. روش درست دقیقاً برعکس است: از پایین‌ترین لایه‌ی ممکن شروع کنید و فقط وقتی مطمئن شدید آن لایه سالم است، یک پله بالاتر بروید. این کار باعث می‌شود هیچ‌وقت وقت‌تان را صرف حدس‌های بی‌ربط نکنید.

ما اتصال را به هفت پرسش ساده تقسیم می‌کنیم. هر پرسش یک لایه است و برای هر لایه یک ابزار مشخص وجود دارد که فقط همان لایه را می‌آزماید. اگر پاسخ یک لایه «خراب» بود، همان‌جا بایستید و مشکل را حل کنید؛ چون تا وقتی لایه‌ی پایینی خراب است، آزمودن لایه‌های بالاتر هیچ معنایی ندارد. برای مثال، تا وقتی دستگاه شما اصلاً آدرس آی‌پی درستی ندارد، تست DNS مثل این است که بخواهید در خانه‌ای که هنوز ساخته نشده زنگ در را امتحان کنید.

لایه	پرسش کلیدی	ابزار اصلی	نشانه‌ی سلامت
۱. فیزیکی	آیا کابل/کارت شبکه برق و سیگنال دارد؟	چراغ پورت، ip link	وضعیت UP و لینک فعال
۲. پیوند	آیا با دروازه در همان شبکه‌ی محلی حرف می‌زنیم؟	arp -a	مک‌آدرس دروازه دیده می‌شود
۳. آدرس	آیا آی‌پی، ماسک و دروازه درست‌اند؟	ipconfig /all، ip addr	آدرس معتبر و بدون تعارض
۴. مسیریابی	آیا بسته به مقصد بیرونی می‌رسد؟	ping، tracert	پاسخ از دروازه و از اینترنت
۵. تبدیل نام	آیا نام دامنه به آدرس تبدیل می‌شود؟	nslookup، dig	پاسخ NOERROR با رکورد
۶. انتقال	آیا پورت مقصد باز است و بسته کامل می‌رسد؟	Test-NetConnection، curl	اتصال برقرار، بدون افت MTU
۷. برنامه	آیا خودِ نرم‌افزار درست رفتار می‌کند؟	لاگ برنامه، مرورگر	پاسخ صحیح از سرویس

نکته‌ی کلیدی: هر بار که چیزی کار نکرد، این جمله را از خودتان بپرسید: «پایین‌ترین لایه‌ای که هنوز مطمئن نیستم سالم است کدام است؟» و دقیقاً از همان‌جا شروع کنید. این یک عادت است که ساعت‌ها وقت‌تان را نجات می‌دهد.

#لایه‌ی فیزیکی و پیوند: قبل از هر چیز، سیم و سیگنال

ممکن است بدیهی به نظر برسد، اما شمار زیادی از تماس‌های پشتیبانی با یک کابل شل، یک پورت سوخته، یا یک آداپتور غیرفعال حل می‌شوند. پیش از باز کردن هر ابزار نرم‌افزاری، مطمئن شوید لایه‌ی فیزیکی سالم است. روی اتصال سیمی، چراغ کنار پورت شبکه باید روشن یا در حال چشمک‌زدن باشد؛ خاموش‌بودن آن یعنی یا کابل مشکل دارد، یا سوییچ/مودم آن سر خاموش است، یا کارت شبکه در سیستم‌عامل غیرفعال شده است. روی اتصال بی‌سیم، به قدرت سیگنال و درست‌بودن نام شبکه دقت کنید.

در ویندوز می‌توانید وضعیت آداپتور را با دستور زیر ببینید و مطمئن شوید اصلاً فعال و متصل است. اگر آداپتوری در حالت Disconnected یا Media disconnected باشد، هیچ آدرس آی‌پی معتبری نخواهد گرفت و بقیه‌ی مراحل بی‌فایده است:

C:> netsh interface show interface

Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Connected      Dedicated        Ethernet
Enabled        Disconnected   Dedicated        Wi-Fi

در لینوکس، دستور ip link وضعیت هر واسط را نشان می‌دهد. عبارت کلیدی که دنبالش می‌گردید state UP و پرچم LOWER_UP است؛ این یعنی هم سیستم‌عامل واسط را بالا آورده و هم سیگنال فیزیکی (لینک) برقرار است. اگر NO-CARRIER ببینید، یعنی کابل وصل نیست یا آن‌سرِ کابل مرده است:

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether a4:bb:6d:2f:11:07 brd ff:ff:ff:ff:ff:ff

وقتی لایه‌ی فیزیکی سالم بود، یک پله بالاتر می‌رویم: لایه‌ی پیوند. در این لایه دستگاه شما باید بتواند با دروازه‌ی پیش‌فرض (همان مودم/روتر) در سطح شبکه‌ی محلی گفت‌وگو کند. ابزار این کار جدول ARP است که آدرس آی‌پی محلی را به آدرس فیزیکی (مک) نگاشت می‌کند. اگر مک‌آدرس دروازه در جدول ARP ظاهر شود، یعنی لایه‌ی پیوند سالم است. این موضوع را در بخش تعارض آدرس با جزئیات می‌بینیم.

#خواندن آدرس شبکه: ‎ipconfig /all و ‎ip addr

قلب عیب‌یابی آی‌پی ثابت، توانایی خواندن درست وضعیت آدرس‌دهی دستگاه است. در ویندوز، فرمانده‌ی اصلی شما دستور ipconfig /all است. برخلاف ipconfig ساده که فقط آدرس و دروازه را می‌دهد، نسخه‌ی /all همه‌چیز را نشان می‌دهد: این‌که آدرس به‌صورت دستی تعیین شده یا از سرویس‌دهنده گرفته شده، سرورهای DNS، مدت اجاره‌ی آدرس، و مک‌آدرس کارت. بیایید یک خروجی واقعی را خط‌به‌خط بخوانیم:

C:> ipconfig /all

   Host Name . . . . . . . . . . . . : DESKTOP-Q22
   DNS Suffix Search List. . . . . . : lan

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
   Physical Address. . . . . . . . . : A4-BB-6D-2F-11-07
   DHCP Enabled. . . . . . . . . . . : No
   IPv4 Address. . . . . . . . . . . : 192.168.1.50(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 1.1.1.1
                                       9.9.9.9
   NetBIOS over Tcpip. . . . . . . . : Enabled

در این خروجی چند چیز حیاتی را باید کنترل کنید. اول، سطر DHCP Enabled : No به‌همراه یک IPv4 Address معتبر یعنی آدرس به‌صورت دستی و ثابت تعیین شده است؛ دقیقاً همان چیزی که برای یک آدرس ثابت در برابر آدرس داینامیک انتظار داریم. اگر DHCP Enabled : Yes بود، یعنی آدرس هنوز دارد از سرویس‌دهنده گرفته می‌شود و پیکربندی ثابت شما اعمال نشده است. دوم، برچسب (Preferred) کنار آدرس نشانه‌ی سلامت است؛ اگر به‌جای آن (Duplicate) ببینید، یعنی تعارض آدرس رخ داده که در بخش بعد به آن می‌پردازیم.

سومین چیز، آدرس 169.254.x.x است. اگر دستگاه به‌جای آدرس مورد انتظار یک آدرس در این محدوده گرفته باشد، یعنی نتوانسته از سرویس‌دهنده آدرس بگیرد و خودش یک آدرس خودتخصیصی (APIPA) ساخته است. این تقریباً همیشه نشانه‌ی قطع‌بودن ارتباط با مودم یا خرابی سرویس آدرس‌دهی است. در معادل لینوکسی، دستور ip addr همین اطلاعات را می‌دهد:

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    link/ether a4:bb:6d:2f:11:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a6bb:6dff:fe2f:1107/64 scope link
       valid_lft forever preferred_lft forever

در خروجی ip addr عبارت 192.168.1.50/24 هم آدرس و هم طول ماسک را یک‌جا نشان می‌دهد؛ /24 همان 255.255.255.0 است. عبارت valid_lft forever یعنی این آدرس اجاره‌ی زمان‌دار ندارد و ثابت است. برای دیدن دروازه‌ی پیش‌فرض در لینوکس از ip route استفاده می‌کنید که سطر default via 192.168.1.1 را نشان می‌دهد. تا این‌جا سه ستون اطلاعات کلیدی داریم: آدرس، ماسک، و دروازه. درستی این سه با هم، پایه‌ی هر اتصال سالمی است و در بخش‌های بعد نشان می‌دهیم اشتباه در هرکدام چه علائمی می‌سازد.

#تشخیص آدرس تکراری و تعارض ARP

یکی از گیج‌کننده‌ترین مشکلات آی‌پی ثابت این است که اتصال گاه‌به‌گاه قطع و وصل می‌شود؛ چند دقیقه کار می‌کند، بعد چند دقیقه نه. یکی از شایع‌ترین علت‌های این رفتار، تعارض آدرس است: دو دستگاه در یک شبکه‌ی محلی هر دو روی یک آدرس آی‌پی یکسان تنظیم شده‌اند. این وقتی رخ می‌دهد که شما یک آدرس ثابت را از دل محدوده‌ی سرویس‌دهنده‌ی خودکار انتخاب کنید و بعد همان آدرس به دستگاه دیگری هم اجاره داده شود. نتیجه، جنگ بر سر یک هویت است و شبکه نمی‌داند بسته را به کدام کارت شبکه بفرستد.

ویندوز معمولاً با یک پیام «تعارض آدرس آی‌پی» هشدار می‌دهد، اما همیشه این کار را نمی‌کند. راه قطعی تشخیص، نگاه‌کردن به جدول ARP است. هر دستگاه در شبکه یک مک‌آدرس یکتا دارد. اگر یک آدرس آی‌پی در بازه‌های زمانی مختلف با مک‌آدرس‌های متفاوت ظاهر شود، یعنی دو دستگاه دارند سر آن آدرس دعوا می‌کنند. با دستور arp -a جدول را ببینید:

C:> arp -a

Interface: 192.168.1.50 --- 0xb
  Internet Address      Physical Address      Type
  192.168.1.1           b8-27-eb-4a-1c-92     dynamic
  192.168.1.50          a4-bb-6d-2f-11-07     dynamic
  192.168.1.77          00-1a-2b-3c-4d-5e     dynamic
  192.168.1.255         ff-ff-ff-ff-ff-ff     static

برای اثبات تعارض، این آزمایش ساده را انجام دهید: کارت شبکه‌ی رایانه‌ی خودتان را موقتاً غیرفعال کنید و از یک دستگاه دیگر همان آدرس را ping کنید. اگر با وجود خاموش‌بودن دستگاه شما همچنان پاسخ آمد، یعنی یک دستگاه دیگر دارد از همان آدرس استفاده می‌کند. راه‌حل قطعی این است که آدرس ثابت را از بازه‌ای بیرون محدوده‌ی تخصیص خودکار سرویس‌دهنده انتخاب کنید، یا بهتر از آن، در تنظیمات مودم یک «رزرو آدرس» بر اساس مک‌آدرس دستگاه تعریف کنید تا هیچ‌وقت آن آدرس به کس دیگری داده نشود. اگر می‌خواهید تفاوت بنیادین این دو مدل آدرس‌دهی را عمیق‌تر بفهمید، مقاله‌ی تفاوت آی‌پی ثابت و داینامیک پایه‌ی خوبی است.

هرگز یک آدرس ثابت را از وسط محدوده‌ای که مودم به‌صورت خودکار پخش می‌کند برندارید. یا آدرس را بیرون آن محدوده بگذارید، یا در مودم برای مک‌آدرس دستگاه یک رزرو ثابت تعریف کنید. این یک قانون است، نه یک سلیقه.

#ماسک زیرشبکه و دروازه‌ی اشتباه: خطاهایی که «تقریباً» کار می‌کنند

خطرناک‌ترین نوع خطای آدرس‌دهی آن است که همه‌چیز را تا حدی درست جلوه می‌دهد. ماسک زیرشبکه‌ی اشتباه دقیقاً از این جنس است. فرض کنید آدرس شما 192.168.1.50 است و دروازه 192.168.1.1، اما به‌اشتباه ماسک را 255.255.255.128 (یعنی /25) گذاشته‌اید در حالی که شبکه واقعاً /24 است. در این حالت شاید بتوانید بعضی دستگاه‌های محلی را ببینید ولی بعضی دیگر را نه، و رفتار شبکه غیرقابل‌پیش‌بینی می‌شود. ماسک تعیین می‌کند کدام آدرس‌ها «همسایه‌ی مستقیم» شمرده می‌شوند و کدام‌ها باید از دروازه عبور کنند؛ اشتباه در آن یعنی دستگاه گاهی سعی می‌کند مستقیم با کسی حرف بزند که باید از راه دروازه به او برسد.

نشانه‌ی کلاسیک ماسک اشتباه این است: ping به بعضی آدرس‌های محلی جواب می‌دهد و به بعضی نه، بی‌آنکه الگوی روشنی داشته باشد. برای بررسی، آدرس و ماسک را کنار هم بگذارید و مرز زیرشبکه را حساب کنید. جدول زیر چند ماسک رایج و تعداد میزبان‌های قابل‌استفاده‌شان را نشان می‌دهد تا سریع بفهمید آدرس‌تان باید در کدام بازه باشد:

نماد CIDR	ماسک زیرشبکه	تعداد میزبان قابل‌استفاده	کاربرد رایج
/24	255.255.255.0	۲۵۴	شبکه‌ی خانگی و اداری معمول
/25	255.255.255.128	۱۲۶	تقسیم یک شبکه به دو نیمه
/26	255.255.255.192	۶۲	زیرشبکه‌های کوچک
/30	255.255.255.252	۲	لینک نقطه‌به‌نقطه بین دو مسیریاب
/16	255.255.0.0	۶۵۵۳۴	شبکه‌های بزرگ سازمانی

دروازه‌ی اشتباه علائم متفاوتی دارد: دستگاه‌های داخل شبکه‌ی محلی را کامل می‌بینید (چون برای آن‌ها به دروازه احتیاجی نیست)، اما هیچ چیزی از اینترنت بالا نمی‌آید. یک آزمون سریع این است: اول دروازه را ping کنید؛ اگر جواب داد یعنی دروازه در دسترس است. بعد یک آدرس بیرونی مثل 1.1.1.1 را ping کنید؛ اگر دروازه جواب داد اما آدرس بیرونی نه، مشکل یا در دروازه است یا در تنظیم مسیر پیش‌فرض. نکته‌ی مهم این است که دروازه باید حتماً در همان زیرشبکه‌ی آدرس شما باشد؛ دروازه‌ای که بیرون بازه‌ی ماسک قرار بگیرد اصلاً قابل‌دسترسی نیست و هیچ ترافیکی از آن عبور نخواهد کرد.

#آیا آدرس ثابت بعد از ری‌استارت ماند؟

یک شکایت رایج این است: «آدرس ثابت را تنظیم کردم، کار کرد، ولی بعد از خاموش-روشن‌کردن سیستم دوباره پرید.» این تقریباً همیشه یعنی پیکربندی به‌صورت موقتی اعمال شده، نه دائمی. در لینوکس، دستوری مثل ip addr add که مستقیم در ترمینال بزنید فقط تا ری‌استارت بعدی می‌ماند؛ برای ماندگاری باید آن را در فایل تنظیمات شبکه‌ی توزیع (مثلاً netplan یا NetworkManager) بنویسید. در ویندوز هم اگر آدرس را با ابزار خط‌فرمان و به‌صورت موقت ست کرده باشید، ممکن است پس از ری‌استارت به حالت خودکار برگردد.

روش درست بررسی ماندگاری این است: پس از تنظیم آدرس ثابت، یک بار سیستم را کامل ری‌استارت کنید و بلافاصله ipconfig /all (یا ip addr) را دوباره بخوانید. اگر همچنان DHCP Enabled : No و همان آدرس مورد نظر را دیدید، پیکربندی دائمی است. اگر آدرس به یک مقدار دیگر یا به حالت خودکار برگشت، یعنی تنظیم شما در جای درستی ذخیره نشده است. جدول زیر خلاصه‌ی محل درست تنظیم دائمی در سیستم‌عامل‌های مختلف است:

سیستم‌عامل	محل تنظیم دائمی آدرس ثابت	تأیید پس از ری‌استارت
ویندوز	تنظیمات آداپتور شبکه ← IPv4 ← «استفاده از آدرس زیر»	ipconfig /all
اوبونتو (نتپلن)	/etc/netplan/*.yaml سپس netplan apply	ip addr
لینوکس با NetworkManager	nmcli con mod با ipv4.method manual	nmcli con show
مک	تنظیمات سیستم ← شبکه ← جزئیات ← TCP/IP ← «به‌صورت دستی»	ipconfig getifaddr en0

#لایه‌ی مسیریابی: ‎ping در برابر ‎tracert

وقتی مطمئن شدید آدرس، ماسک و دروازه درست‌اند، وقت آزمودن مسیریابی است: آیا بسته‌ی شما واقعاً از دستگاه بیرون می‌رود، از دروازه عبور می‌کند، و به مقصد بیرونی می‌رسد؟ دو ابزار بنیادی اینجا داریم که مکمل هم‌اند اما کار متفاوتی می‌کنند. ping فقط یک پرسش بله/خیر است: «آیا این مقصد زنده است و چقدر طول می‌کشد جواب بدهد؟» اما tracert (در ویندوز) یا traceroute (در لینوکس و مک) کل مسیر را قدم‌به‌قدم نشان می‌دهد: بسته از کدام مسیریاب‌ها عبور می‌کند و در کدام نقطه کند یا گم می‌شود.

هر دو ابزار بر پایه‌ی پروتکل ICMP کار می‌کنند که در RFC 792 تعریف شده است. یک ping ساده این‌طور به نظر می‌رسد. به مقدار TTL و زمان رفت‌وبرگشت (time) دقت کنید؛ این دو، معدن اطلاعات‌اند:

C:> ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=14ms TTL=57
Reply from 1.1.1.1: bytes=32 time=13ms TTL=57
Reply from 1.1.1.1: bytes=32 time=15ms TTL=57
Reply from 1.1.1.1: bytes=32 time=13ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 15ms, Average = 13ms

مقدار TTL (طول عمر بسته) یک شمارنده است که در مبدأ روی عددی مثل ۶۴ یا ۱۲۸ تنظیم می‌شود و هر مسیریابی که بسته از آن عبور کند یک واحد از آن کم می‌کند. اگر به صفر برسد، بسته دور انداخته می‌شود تا در حلقه‌های بی‌پایان نچرخد. وقتی در پاسخ ping عدد TTL=57 می‌بینید و می‌دانید مبدأ معمولاً ۶۴ بوده، یعنی بسته حدود ۷ پرش (۶۴ منهای ۵۷) طی کرده تا برسد. این عدد به شما حس تقریبی فاصله‌ی شبکه‌ای می‌دهد. اعداد رایج مبدأ TTL برای سیستم‌عامل‌های مختلف متفاوت است و همین گاهی سرنخ می‌دهد که آن‌سوی خط چه نوع سیستمی است.

حالا اگر ping جواب نداد یا کند بود، tracert نشان می‌دهد دقیقاً کجا. هر خط یک پرش (hop) است و سه عدد زمان برای سه بسته‌ی آزمایشی می‌دهد. جهش ناگهانی تأخیر یا ظاهرشدن ستاره (*) نقطه‌ی مشکل را لو می‌دهد:

C:> tracert -d google.com

Tracing route to google.com [142.250.185.78] over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2     8 ms     9 ms     8 ms  10.20.30.1
  3    12 ms    11 ms    13 ms  85.15.16.1
  4    28 ms    31 ms   140 ms  213.232.124.9
  5     *        *        *     Request timed out.
  6    32 ms    33 ms    31 ms  142.250.185.78

Trace complete.

این خروجی را چطور بخوانیم؟ پرش اول همیشه دروازه‌ی محلی شماست؛ اگر همین‌جا شکست بخورد، مشکل داخل شبکه‌ی خودتان است. پرش‌های میانی مسیریاب‌های سرویس‌دهنده و بین‌راهی‌اند. یک نکته‌ی مهم که خیلی‌ها را می‌ترساند: ستاره‌ی * در یک پرش میانی الزاماً به‌معنای مشکل نیست؛ بسیاری از مسیریاب‌ها عمداً به بسته‌های آزمایشی traceroute پاسخ نمی‌دهند اما بسته‌های عبوری را کامل رد می‌کنند. فقط وقتی نگران باشید که تأخیر از یک پرش به بعد به‌طور دائمی بالا برود و تا مقصد بالا بماند، یا ترِیس اصلاً به مقصد نرسد. برای درک عمیق‌تر منطق پشت این ابزار، صفحه‌ی Traceroute در ویکی‌پدیا توضیح روشنی دارد. جدول زیر تفاوت کاربردی این دو ابزار را جمع می‌کند:

ویژگی	ping	tracert / traceroute
چه می‌گوید	مقصد زنده است یا نه، و با چه تأخیری	بسته از چه مسیری و چند پرش می‌رود
بهترین کاربرد	تأیید سریع دسترسی و اندازه‌گیری تأخیر	پیداکردن نقطه‌ی دقیق قطع یا کندی
معنی ستاره / timeout	بسته گم شد یا مقصد پاسخ نداد	آن پرش به آزمون پاسخ نداد (شاید عادی)
سرنخ کلیدی	مقدار TTL و درصد گم‌شدن	پرشی که تأخیر از آن به بعد بالا می‌ماند
وقتی به کار می‌آید	«اصلاً وصل هست؟»	«کجای مسیر خراب است؟»

#لایه‌ی تبدیل نام: با ‎nslookup و ‎dig مقصر را پیدا کنید

حالا به قلب ماجرا رسیدیم. اگر تا این‌جا آدرس‌دهی و مسیریابی سالم بوده‌اند اما هنوز سایت‌ها باز نمی‌شوند، تقریباً همیشه پای تبدیل نام در میان است. کار DNS این است که یک نام خواندنی مثل example.com را به یک آدرس عددی مثل 93.184.216.34 ترجمه کند؛ سازوکار کاملش در مقاله‌ی DNS چیست و چگونه کار می‌کند آمده و ساختار داده‌هایش در راهنمای رکوردهای DNS شرح داده شده است. اما وقتی این ترجمه شکست می‌خورد، سؤال کلیدی این است: مقصر کیست؟ سه مظنون داریم و باید هر کدام را جدا بازجویی کنیم:

• حل‌کننده‌ی محلی (resolver): همان سروری که دستگاه شما پرسش‌ها را به آن می‌فرستد؛ معمولاً مودم یا یک سرور عمومی مثل 1.1.1.1.
• سرور معتبر (authoritative): سروری که پاسخ نهایی و رسمی یک دامنه را نگه می‌دارد.
• کش (cache): پاسخی که قبلاً ذخیره شده و شاید کهنه یا اشتباه باشد.

ابزار سریع در ویندوز nslookup است. یک پرسش ساده این‌طور است و اولین چیزی که باید ببینید، خط Server است که می‌گوید پاسخ از کدام حل‌کننده آمده:

C:> nslookup example.com

Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    example.com
Address:  93.184.216.34

عبارت Non-authoritative answer یعنی این پاسخ از کش حل‌کننده آمده، نه مستقیم از سرور معتبر دامنه؛ این کاملاً عادی است و نشانه‌ی خطا نیست. اما اگر می‌خواهید حل‌کننده را دور بزنید و مستقیم از یک سرور مشخص بپرسید تا بفهمید آیا مشکل از حل‌کننده‌ی محلی است یا نه، ابزار حرفه‌ای‌تر dig را با نشانه‌ی @server به کار ببرید. این تکنیک ستون فقرات عیب‌یابی DNS است: با پرسیدن یک نام از دو حل‌کننده‌ی مختلف و مقایسه‌ی پاسخ‌ها، فوراً می‌فهمید مشکل سراسری است یا فقط مال حل‌کننده‌ی شما.

$ dig @1.1.1.1 example.com +short
93.184.216.34

$ dig @8.8.8.8 example.com +short
93.184.216.34

اگر هر دو حل‌کننده یک آدرس یکسان دادند، تبدیل نام سالم است و مشکل جای دیگری است. اگر یکی جواب درست داد و دیگری جواب اشتباه یا خالی، مقصر همان حل‌کننده‌ی خطاکار است و کافی است سرور DNS دستگاه‌تان را به حل‌کننده‌ی سالم تغییر DNS بدهید. نشانه‌ی +short فقط جوابِ خالص را می‌دهد و شلوغی را حذف می‌کند؛ برای عیب‌یابی روزمره فوق‌العاده است.

#ردیابی کامل زنجیره با ‎dig +trace

گاهی می‌خواهید کل سفر یک پرسش را از ریشه تا سرور معتبر ببینید تا بفهمید زنجیره‌ی واگذاری (delegation) دقیقاً کجا می‌شکند. اینجا dig +trace بی‌رقیب است. این دستور به‌جای اعتماد به کش، از سرورهای ریشه شروع می‌کند و پله‌پله پایین می‌آید: از ریشه به سرورهای دامنه‌ی سطح‌بالا (مثل .com) و از آن‌جا به سرورهای معتبر خودِ دامنه:

$ dig +trace example.com

.                     518400  IN  NS  a.root-servers.net.
.                     518400  IN  NS  b.root-servers.net.
;; Received 811 bytes from 1.1.1.1#53(1.1.1.1) in 12 ms

com.                  172800  IN  NS  a.gtld-servers.net.
com.                  172800  IN  NS  b.gtld-servers.net.
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

example.com.          172800  IN  NS  a.iana-servers.net.
example.com.          172800  IN  NS  b.iana-servers.net.
;; Received 508 bytes from 192.5.6.30#53(a.gtld-servers.net) in 30 ms

example.com.          86400   IN  A   93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 ms

هر بلوک یک پله از زنجیره است. اگر ترِیس تا یک نقطه پیش برود و بعد گیر کند یا خطا بدهد، همان نقطه محل شکستِ واگذاری است. مثلاً اگر بلوک .com سرورهای معتبر دامنه را نشان بدهد اما پرسش از آن سرورها بی‌پاسخ بماند، مشکل در سرورهای معتبر خودِ دامنه است، نه در حل‌کننده‌ی شما. این تمایز حیاتی است چون مسیر رفع مشکل را کاملاً عوض می‌کند: یکی را شما به‌عنوان کاربر حل می‌کنید (تغییر حل‌کننده)، دیگری را فقط صاحب دامنه. مفاهیم دقیق «حل‌کننده»، «معتبر» و «واگذاری» در استاندارد اصطلاح‌شناسی RFC 8499 و پروتکل پایه در RFC 1035 تعریف شده‌اند.

#خواندن کد پاسخ DNS: ‏NXDOMAIN در برابر SERVFAIL و REFUSED

وقتی یک پرسش DNS می‌فرستید، پاسخ همیشه یک «کد وضعیت» همراه دارد که در قالب status: در خروجی کامل dig دیده می‌شود. تشخیص این کدها از هم، تفاوت بین ده دقیقه و دو ساعت عیب‌یابی است، چون هر کد دقیقاً به یک نوع مشکل اشاره می‌کند. بیایید خروجی کامل (بدون +short) را ببینیم و روی خط status تمرکز کنیم:

$ dig example.com

; <<>> DiG 9.18.1 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43125
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

در این نمونه status: NOERROR است و بخش ANSWER یک رکورد دارد؛ یعنی همه‌چیز درست است. اما وقتی چیزی خراب باشد، همین خط status نوع دقیق مشکل را لو می‌دهد. جدول زیر پرتکرارترین کدها را با معنا و اقدام درست هرکدام جمع کرده است. این جدول را حفظ کنید؛ نیمی از خطاهای DNS با شناختن همین چند کد حل می‌شوند:

کد پاسخ	معنا	علت محتمل	اقدام درست
NOERROR	پرسش موفق بود	—	اگر بخش ANSWER خالی است، شاید نوع رکورد اشتباه است
NXDOMAIN	این نام اصلاً وجود ندارد	غلط املایی، دامنه‌ی حذف‌شده، رکورد ساخته‌نشده	املای دامنه و وجود رکورد را بررسی کنید
SERVFAIL	سرور نتوانست پاسخ بدهد	خطای امضای امنیتی، سرور معتبر خراب، زنجیره‌ی شکسته	با حل‌کننده‌ی دیگر و +trace بیازمایید
REFUSED	سرور از پاسخ‌دادن سر باز زد	سیاست دسترسی، پرسش از سروری که مسئول این دامنه نیست	از حل‌کننده‌ی درست بپرسید
timeout	هیچ پاسخی نیامد	حل‌کننده در دسترس نیست، بسته UDP گم شد، پورت ۵۳ بسته است	دسترسی به حل‌کننده و مسیر شبکه را چک کنید

تمایز NXDOMAIN از SERVFAIL از همه مهم‌تر است. NXDOMAIN یک پاسخ قطعی و معتبر است؛ سرور با اطمینان می‌گوید «چنین نامی وجود ندارد». پس اگر مطمئنید دامنه باید وجود داشته باشد، مشکل در طرف داده است: یا رکورد ساخته نشده، یا اشتباه تایپ کرده‌اید. در مقابل SERVFAIL یعنی سرور نتوانست به نتیجه برسد؛ این معمولاً یک نقص موقتی یا پیکربندی خراب در سمت سرور است، مثلاً خطای اعتبارسنجی امضای امنیتی دامنه. کش‌شدن پاسخ‌های منفی مثل NXDOMAIN هم قاعده‌ی خودش را دارد که در RFC 2308 تعریف شده و در بخش بعد به آن می‌رسیم.

#پاک‌سازی کش: وقتی پاسخ کهنه گیر کرده

یکی از پرتکرارترین سناریوها این است: آدرس یک سایت عوض شده، از یک دستگاه دیگر باز می‌شود اما روی دستگاه شما هنوز به آدرس قدیمی می‌رود. مقصر تقریباً همیشه کش است. برای سرعت، هر لایه پاسخ‌ها را برای مدتی ذخیره می‌کند: سیستم‌عامل یک کش دارد، مرورگر کش جدا دارد، و حل‌کننده‌ی بالادست هم کش خودش را. وقتی داده تغییر می‌کند، این کش‌ها تا انقضای زمان‌شان همان پاسخ کهنه را می‌دهند. راه‌حل، خالی‌کردن دستی کش است. جدول زیر فرمان درست هر محیط را می‌دهد:

محیط	فرمان پاک‌سازی کش DNS
ویندوز	ipconfig /flushdns
مک	sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
لینوکس (systemd)	sudo resolvectl flush-caches
لینوکس (nscd)	sudo systemctl restart nscd
مرورگر کروم	نشانی chrome://net-internals/#dns ← دکمه‌ی Clear host cache
مرورگر فایرفاکس	نشانی about:networking#dns ← Clear DNS Cache

در ویندوز، پس از اجرای ipconfig /flushdns می‌توانید با ipconfig /displaydns محتوای فعلی کش را ببینید و مطمئن شوید خالی شده است. نکته‌ی مهم این است که خالی‌کردن کش سیستم‌عامل، کش مرورگر را پاک نمی‌کند؛ مرورگرهای امروزی کش DNS داخلی خودشان را دارند و بعضی حتی از حل‌کننده‌ی رمزنگاری‌شده‌ی مستقل استفاده می‌کنند. بنابراین اگر بعد از پاک‌کردن کش سیستم هنوز مشکل پابرجاست، حتماً کش مرورگر را هم جداگانه خالی کنید یا با یک پنجره‌ی ناشناس آزمایش کنید.

#‏TTL کهنه و افسانه‌ی «صبر برای انتشار»

یک باور غلط بسیار رایج این است که وقتی رکوردی را عوض می‌کنید، باید «۲۴ تا ۴۸ ساعت صبر کنید تا در کل دنیا منتشر شود». این تصویر ذهنی از اساس اشتباه است. DNS چیزی را «پخش» نمی‌کند؛ هیچ موجی از سرور شما به سمت بیرون حرکت نمی‌کند. آنچه واقعاً اتفاق می‌افتد این است: هر رکورد یک مقدار TTL دارد که می‌گوید «این پاسخ را چند ثانیه می‌توانی نگه داری». هر حل‌کننده‌ای که پاسخ قدیمی را کش کرده، دقیقاً تا پایان همان TTL آن را نگه می‌دارد و بعد دوباره می‌پرسد. پس آنچه شبیه «انتشار کند» به نظر می‌رسد، در واقع «انقضای کش‌های پراکنده» است.

پیامد عملی این است: اگر می‌دانید قرار است رکوردی را عوض کنید، از قبل TTL آن را پایین بیاورید (مثلاً از ۸۶۴۰۰ ثانیه به ۳۰۰ ثانیه)، چند ساعت صبر کنید تا مقادیر بالای قبلی منقضی شوند، بعد تغییر را اعمال کنید. آن‌وقت تغییر ظرف چند دقیقه همه‌جا دیده می‌شود، نه چند روز. جدول زیر مقادیر رایج TTL و کاربردشان را نشان می‌دهد:

مقدار TTL	معادل زمانی	کاربرد
300	۵ دقیقه	پیش از تغییرات برنامه‌ریزی‌شده
3600	۱ ساعت	رکوردهایی که گاهی عوض می‌شوند
86400	۲۴ ساعت	رکوردهای پایدار و کم‌تغییر
0	بدون کش	مواردی که هیچ کشی نباید بماند (به‌ندرت)

«انتشار DNS» یک افسانه است. چیزی منتشر نمی‌شود؛ کش‌های قدیمی صرفاً منقضی می‌شوند. اگر می‌خواهید تغییر سریع اعمال شود، به‌جای «صبر کردن»، از قبل TTL را کم کنید. این یک تصمیم است، نه یک انتظار.

#بازنویسی با فایل ‏hosts: میان‌بری قدرتمند و خطرناک

گاهی می‌خواهید یک نام دامنه را برای فقط همین یک دستگاه به یک آدرس مشخص وصل کنید، بدون دست‌زدن به هیچ سروری. اینجا فایل hosts وارد می‌شود. این فایل ساده‌ی متنی پیش از هر پرسش DNS بررسی می‌شود؛ اگر نامی در آن باشد، سیستم اصلاً از حل‌کننده نمی‌پرسد و مستقیم همان آدرس را به کار می‌برد. این ابزار برای آزمایش فوق‌العاده است: مثلاً می‌خواهید ببینید سرور جدید درست کار می‌کند یا نه، پیش از آنکه رکورد رسمی را عوض کنید.

محل این فایل در ویندوز C:WindowsSystem32driversetchosts و در لینوکس و مک /etc/hosts است. قالب آن ساده است: هر خط یک آدرس و بعد یک یا چند نام. برای مثال:

# C:WindowsSystem32driversetchosts
93.184.216.34    example.com
203.0.113.10     test.mysite.local
127.0.0.1        localhost

اما همین قدرت، آن را خطرناک می‌کند. اگر یک خط آزمایشی را در فایل hosts جا بگذارید و فراموش کنید، ماه‌ها بعد که آدرس واقعی سایت عوض شده، دستگاه شما همچنان سرسختانه به آدرس قدیمیِ نوشته‌شده در hosts می‌رود و شما ساعت‌ها دنبال مشکلی می‌گردید که در DNS نیست. بنابراین یک قانون طلایی: هر بار که DNS رفتار عجیبی داشت و از یک دستگاه خاص فقط، اولین کاری که می‌کنید باز کردن فایل hosts و مطمئن‌شدن از خالی‌بودن (یا درست‌بودن) آن است. ورودی‌های فراموش‌شده‌ی hosts از رایج‌ترین علل «خطای DNS»ای هستند که اصلاً ربطی به DNS ندارند.

#‏MTU و تکه‌تکه‌شدن بسته: وقتی سایت‌ها نیمه‌کاره باز می‌شوند

این یکی از موذی‌ترین مشکلات شبکه است چون علائمش گمراه‌کننده‌اند. نشانه‌ی کلاسیک: ping کار می‌کند، تبدیل نام درست است، صفحه‌های کوچک باز می‌شوند، اما صفحه‌های سنگین نیمه‌کاره می‌مانند یا اتصال‌های امن وسط دست‌دادن قطع می‌شوند. مقصر معمولاً MTU است. MTU بزرگ‌ترین اندازه‌ی بسته‌ای است که یک لینک می‌تواند بدون شکستن حمل کند و مقدار استاندارد آن روی اترنت ۱۵۰۰ بایت است. اگر جایی در مسیر، لینکی MTU کوچک‌تری داشته باشد و پرچم «تکه‌تکه نکن» روی بسته باشد، آن بسته‌ی بزرگ بی‌صدا دور انداخته می‌شود.

خوشبختانه یک آزمون دقیق برای این کار داریم: ping با پرچم «تکه‌تکه نکن» و اندازه‌ی مشخص. در ویندوز پرچم -f بسته را از تکه‌شدن منع می‌کند و -l اندازه‌ی بار داده را تعیین می‌کند. با کم‌وزیادکردن اندازه، بزرگ‌ترین بسته‌ای را که بی‌تکه‌شدن عبور می‌کند پیدا می‌کنید:

C:> ping -f -l 1472 1.1.1.1
Reply from 1.1.1.1: bytes=32 time=14ms TTL=57      <- عبور کرد

C:> ping -f -l 1473 1.1.1.1
Packet needs to be fragmented but DF set.          <- بزرگ‌تر از حد مجاز

چرا ۱۴۷۲؟ چون به بار داده باید ۲۸ بایت سربار (۲۰ بایت سرآیند IP و ۸ بایت سرآیند ICMP) اضافه شود: ۱۴۷۲ به‌علاوه‌ی ۲۸ می‌شود دقیقاً ۱۵۰۰. پس اگر 1472 عبور کند اما 1473 نه، یعنی MTU مسیر شما همان ۱۵۰۰ سالم است. اگر حتی 1472 هم رد نشد و مجبور شدید عدد را پایین بیاورید تا عبور کند، یعنی جایی در مسیر MTU کوچک‌تری دارد و همان عددِ عبورکرده به‌علاوه‌ی ۲۸، MTU واقعی مسیر است. جدول زیر مقادیر رایج را جمع کرده:

نوع لینک	MTU رایج	بزرگ‌ترین بار ping بدون تکه‌شدن
اترنت استاندارد	1500	1472
اتصال‌های کپسوله‌شده (PPPoE)	1492	1464
برخی لینک‌های لایه‌دار	1400	1372
فریم‌های جامبو (شبکه‌ی محلی)	9000	8972

راه‌حل‌های MTU دو دسته‌اند. اگر خودتان مسیریاب لبه را کنترل می‌کنید، مکانیزم «کشف MTU مسیر» که در RFC 1191 تعریف شده باید به‌طور خودکار اندازه را تنظیم کند؛ اما این مکانیزم به بسته‌های خطای ICMP وابسته است و اگر جایی در مسیر آن‌ها را دور بیندازد، کشف MTU می‌شکند و همان علائم نیمه‌کاره ظاهر می‌شود. راه‌حل عملی، پایین‌آوردن دستی MTU روی واسط شبکه است تا زیر کوچک‌ترین مقدار مسیر بیفتد. یک آی‌پی ثابت خانگی یا آی‌پی ثابت ابری که روی زیرساخت پایدار سوار است معمولاً MTU یکنواخت و پیش‌بینی‌پذیری دارد و همین یکی از دلایلی است که چنین سرویس‌هایی این کلاس مشکلات را کم‌تر تجربه می‌کنند.

#ناسازگاری Reverse DNS و خرابی ایمیل

تا این‌جا درباره‌ی تبدیل نام به آدرس (رکورد A) حرف زدیم، اما یک جهت معکوس هم وجود دارد: تبدیل آدرس به نام، که به آن Reverse DNS یا رکورد PTR می‌گویند. برای مرور وب معمولاً اهمیتی ندارد، اما برای یک سرویس حیاتی است: ارسال ایمیل. تقریباً همه‌ی سرورهای ایمیل بزرگ، وقتی از آدرسی ایمیل دریافت می‌کنند، آن آدرس را معکوس جست‌وجو می‌کنند تا ببینند نام برگشتی با نامی که سرور فرستنده ادعا می‌کند هم‌خوان است یا نه. اگر رکورد معکوس وجود نداشته باشد یا با نام میزبان نخواند، ایمیل شما یا به پوشه‌ی هرزنامه می‌رود یا کاملاً رد می‌شود.

برای بررسی رکورد معکوس یک آدرس، از dig با نشانه‌ی -x استفاده کنید. این دستور به‌طور خودکار آدرس را در قالب معکوس ویژه‌ی PTR قرار می‌دهد و نام مرتبط را برمی‌گرداند:

$ dig -x 203.0.113.10 +short
mail.example.com.

$ dig mail.example.com +short
203.0.113.10

آزمون سلامت این است: نامی که از جست‌وجوی معکوس می‌گیرید (mail.example.com) را دوباره مستقیم جست‌وجو کنید؛ اگر به همان آدرس اولیه برگشت، زنجیره «رفت‌وبرگشت» سالم است و سرورهای ایمیل مقصد خیال‌شان راحت می‌شود. اگر جست‌وجوی معکوس خالی برگشت یا نامی داد که به آدرس دیگری می‌رسد، مشکل رکورد معکوس دارید. نکته‌ی مهم این است که رکورد معکوس معمولاً در اختیار صاحب آدرس آی‌پی است، نه صاحب دامنه؛ برای همین وقتی یک آی‌پی ثابت اختصاصی می‌گیرید، باید مطمئن شوید امکان تنظیم رکورد PTR روی آن آدرس فراهم است، وگرنه راه‌اندازی سرویس ایمیل روی آن با دیوار روبه‌رو می‌شود.

#بررسی مسدودبودن یا حضور در فهرست سیاه

گاهی همه‌چیز از دید فنی سالم است اما یک سرویس خاص با آدرس ثابت شما بد رفتار می‌کند: ایمیل‌هایتان رد می‌شوند، یا یک سایت خاص شما را نمی‌پذیرد. یک علت رایج این است که آدرس شما در یک «فهرست سیاه» شهرت (که به آن DNSBL هم می‌گویند) قرار گرفته است. این فهرست‌ها آدرس‌هایی را که سابقه‌ی ارسال هرزنامه یا رفتار مشکوک داشته‌اند فهرست می‌کنند و بسیاری از سرویس‌ها پیش از پذیرش ارتباط، آدرس مبدأ را در برابر این فهرست‌ها بررسی می‌کنند. نکته‌ی مهم برای دارندگان آدرس ثابت این است: اگر آدرسی را دست دوم و با سابقه‌ی نامعلوم بگیرید، ممکن است از قبل بدنام باشد.

جالب این‌جاست که خودِ این فهرست‌ها بر پایه‌ی DNS کار می‌کنند. برای بررسی حضور یک آدرس در یک فهرست، اکتت‌های آدرس را معکوس می‌کنید و به دامنه‌ی سرویس فهرست می‌چسبانید و یک پرسش A می‌فرستید؛ اگر پاسخی مثل 127.0.0.x بیاید یعنی آدرس در فهرست است، و اگر NXDOMAIN بیاید یعنی پاک است. این دقیقاً همان کدهای پاسخی است که پیش‌تر یاد گرفتیم:

$ dig +short 10.113.0.203.zen.example-dnsbl.org
127.0.0.2          <- آدرس در فهرست سیاه است

$ dig +short 50.1.168.192.zen.example-dnsbl.org
;; ->> NXDOMAIN         <- آدرس پاک است، در فهرست نیست

اگر فهمیدید آدرس‌تان در فهرست است، بیش‌تر سرویس‌های معتبر یک صفحه‌ی «درخواست حذف» دارند؛ اما پیش از آن باید علت اصلی (مثلاً یک دستگاه آلوده در شبکه یا پیکربندی نادرست ایمیل) را رفع کنید وگرنه دوباره فهرست می‌شوید. مزیت یک آدرس ثابت تمیز و اختصاصی دقیقاً همین‌جا روشن می‌شود: چون آدرس فقط در اختیار شماست و سابقه‌اش شفاف است، ریسک بدنامی موروثی و ناگهانی به‌شدت پایین می‌آید و شهرت آدرس در کنترل خودتان می‌ماند.

#‏IPv6، دو-پشته و دام‌های Happy Eyeballs

امروزه بیش‌تر سیستم‌ها «دو-پشته»‌اند: هم آدرس IPv4 دارند و هم IPv6. این معمولاً خوب است، اما یک کلاس مشکل عیب‌یابی مخصوص خودش را می‌سازد که فهمیدنش دشوار است. سناریو این است: مرورگر شما هم آدرس IPv4 مقصد را دارد و هم IPv6. برای این‌که کاربر معطل نشود، الگوریتمی به نام «چشمان شاد» (Happy Eyeballs) که در RFC 8305 تعریف شده، تقریباً هم‌زمان هر دو را امتحان می‌کند و هرکدام زودتر جواب داد برنده است. مشکل وقتی پیش می‌آید که IPv6 روی کاغذ پیکربندی شده اما در عمل مسیرش خراب است.

در این حالت علائم عجیب و متناقض می‌شوند: بعضی سایت‌ها فوری باز می‌شوند و بعضی با تأخیر چند ثانیه‌ای، یا یک سایت روی یک دستگاه کار می‌کند و روی دیگری نه، بی‌آنکه الگوی روشنی داشته باشد. علت این است که Happy Eyeballs تلاش IPv6 را می‌کند، منتظر می‌ماند، شکست می‌خورد، و بعد به IPv4 برمی‌گردد؛ همان تأخیر برگشت، همان کندی مرموز است. برای تشخیص، تبدیل نام را جداگانه برای هر دو خانواده آزمایش کنید: رکورد A برای IPv4 و رکورد AAAA برای IPv6:

$ dig example.com A +short
93.184.216.34

$ dig example.com AAAA +short
2606:2800:220:1:248:1893:25c8:1946

$ ping -6 example.com
Reply from 2606:2800:220:1:248:1893:25c8:1946: time=142ms

اگر رکورد AAAA وجود دارد اما ping -6 به آن نمی‌رسد، یعنی IPv6 شما «نیمه‌فعال» است: نام حل می‌شود ولی مسیر خراب است، و این بدترین حالت ممکن است چون سیستم فکر می‌کند IPv6 کار می‌کند و مدام آن را امتحان می‌کند. دو راه‌حل دارید: یا مسیر IPv6 را کاملاً درست کنید، یا اگر به آن نیاز ندارید، IPv6 را روی واسط به‌طور کامل غیرفعال کنید تا سیستم فقط از IPv4 سالم استفاده کند. آنچه نباید بکنید این است که آن را در حالت نیمه‌کاره رها کنید. برای درک بهتر مفهوم آدرس در هر دو خانواده، تعریف پایه‌ای آدرس آی‌پی در MDN نقطه‌ی شروع خوبی است.

یک نکته‌ی مرتبط برای کاربران خانگی: بعضی سرویس‌دهنده‌ها به‌جای آدرس عمومی واقعی، آدرسی از محدوده‌ی اشتراکی می‌دهند که در RFC 6598 (محدوده‌ی 100.64.0.0/10) تعریف شده است. در این حالت آدرسی که در مودم می‌بینید با آدرسی که دنیای بیرون از شما می‌بیند فرق دارد و هیچ اتصال ورودی‌ای مستقیم به شما نمی‌رسد. اگر می‌خواهید سرویسی روی خانه میزبانی کنید، همین یکی از دلایل اصلی نیاز به یک آدرس عمومی و ثابت واقعی است.

#فلوچارت عیب‌یابی به‌صورت فهرست مرتب

حالا همه‌ی آنچه گفتیم را در یک مسیر تصمیم‌گیری واحد جمع می‌کنیم. هر بار که شبکه از کار افتاد، دقیقاً این ترتیب را از بالا دنبال کنید و در اولین جایی که پاسخ «نه» گرفتید، همان‌جا بایستید و مشکل همان لایه را حل کنید. این ترتیب عمداً از پایین به بالاست تا هیچ‌وقت لایه‌ی بالاتر را پیش از اطمینان از لایه‌ی پایین‌تر نیازمایید:

1. آیا لایه‌ی فیزیکی سالم است؟ چراغ پورت روشن است و ip link وضعیت UP می‌دهد؟ اگر نه ← کابل، پورت و فعال‌بودن آداپتور را بررسی کنید.
2. آیا دستگاه آدرس معتبر دارد؟ ipconfig /all یک آدرس درست نشان می‌دهد، نه 169.254.x.x؟ اگر نه ← مشکل آدرس‌دهی یا سرویس تخصیص آدرس است.
3. آیا ماسک و دروازه درست‌اند و آدرس تعارض ندارد؟ (Preferred) است نه (Duplicate)؟ اگر نه ← بخش تعارض ARP و ماسک را ببینید.
4. آیا دروازه پاسخ می‌دهد؟ ping به دروازه جواب می‌دهد؟ اگر نه ← مشکل شبکه‌ی محلی یا خودِ دروازه است.
5. آیا اینترنت با آدرس عددی در دسترس است؟ ping 1.1.1.1 جواب می‌دهد؟ اگر نه ← مسیریابی بیرونی را با tracert دنبال کنید.
6. آیا تبدیل نام کار می‌کند؟ nslookup example.com آدرس می‌دهد؟ اگر نه ← این یک خطای DNS است؛ سراغ گام بعد بروید.
7. آیا مشکل از حل‌کننده‌ی شماست؟ dig @1.1.1.1 جواب می‌دهد اما حل‌کننده‌ی فعلی نه؟ اگر بله ← DNS دستگاه را تغییر دهید.
8. آیا کش کهنه است؟ از دستگاه دیگر درست است ولی از این یکی نه؟ اگر بله ← کش سیستم و مرورگر و فایل hosts را بررسی و پاک کنید.
9. آیا صفحه‌های بزرگ نیمه‌کاره می‌مانند؟ اگر بله ← آزمون MTU با ping -f -l را اجرا کنید.
10. آیا فقط یک سرویس خاص (مثل ایمیل) خراب است؟ اگر بله ← رکورد معکوس و فهرست سیاه آدرس را بررسی کنید.

#جدول مرجع: نشانه، علت، فرمان، راه‌حل

این جدول را می‌توانید کنار دست‌تان نگه دارید. ستون اول نشانه‌ای است که می‌بینید، ستون‌های بعد شما را مستقیم به علت محتمل، فرمان تشخیص، و راه‌حل می‌رساند:

نشانه	علت محتمل	فرمان تشخیص	راه‌حل
هیچ اتصالی نیست	آداپتور غیرفعال یا کابل قطع	netsh interface show interface	فعال‌سازی آداپتور، بررسی کابل
آدرس 169.254.x.x	عدم دریافت آدرس از سرویس‌دهنده	ipconfig /all	بررسی اتصال مودم یا تنظیم آدرس ثابت
اتصال قطع و وصل می‌شود	تعارض آدرس (ARP)	arp -a	آدرس یکتا یا رزرو بر پایه‌ی مک
محلی هست، اینترنت نیست	دروازه یا مسیر پیش‌فرض اشتباه	ping دروازه سپس 1.1.1.1	تصحیح دروازه در تنظیمات آدرس
آدرس کار می‌کند، نام نه	خطای DNS در حل‌کننده	nslookup و dig @1.1.1.1	تغییر DNS به حل‌کننده‌ی سالم
پاسخ SERVFAIL	سرور معتبر یا امضای امنیتی خراب	dig +trace	بررسی سمت سرور دامنه
پاسخ NXDOMAIN	نام وجود ندارد یا رکورد ساخته نشده	dig example.com	بررسی املا و ساخت رکورد
آدرس قدیمی گیر کرده	کش کهنه یا ورودی hosts	ipconfig /displaydns	پاک‌سازی کش و بررسی hosts
صفحه‌های بزرگ نیمه‌کاره	افت MTU در مسیر	ping -f -l 1472	کاهش دستی MTU واسط
ایمیل رد می‌شود	رکورد معکوس یا فهرست سیاه	dig -x و پرسش DNSBL	تنظیم PTR و درخواست حذف از فهرست

#چک‌لیست کپی-پیست عیب‌یابی

این فهرست فرمان‌ها را پشت‌سرهم اجرا کنید تا یک تصویر کامل از وضعیت شبکه‌تان بگیرید. خروجی هر کدام را با آنچه در بخش‌های بالا یاد گرفتید بسنجید:

# ۱) وضعیت کامل آدرس‌دهی
ipconfig /all

# ۲) آیا دروازه و اینترنت عددی در دسترس‌اند؟
ping 192.168.1.1
ping 1.1.1.1

# ۳) مسیر تا مقصد بیرونی
tracert -d 1.1.1.1

# ۴) تبدیل نام از دو حل‌کننده‌ی مستقل
nslookup example.com
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short

# ۵) پاک‌سازی کش و بررسی مجدد
ipconfig /flushdns
ipconfig /displaydns

# ۶) آزمون MTU (کاهش عدد تا عبور بدون خطا)
ping -f -l 1472 1.1.1.1

#جمع‌بندی

عیب‌یابی شبکه وقتی سخت به نظر می‌رسد که آدم بخواهد همه‌چیز را یک‌جا حدس بزند. اما همان مشکل، وقتی به هفت لایه‌ی مستقل تقسیم شود و هر لایه با ابزار مخصوص خودش جدا آزموده شود، به یک فرایند ساده و تکرارپذیر تبدیل می‌شود. کلید کار این است که همیشه از پایین شروع کنید، در اولین لایه‌ی خراب بایستید، و پیش از رفتن به بالا مطمئن شوید لایه‌ی زیرین سالم است. با تسلط بر ipconfig /all، ping، tracert، nslookup و dig، و با شناختن کدهای پاسخ DNS، شما تقریباً هر مشکلی را که یک آدرس ثابت یا یک نام دامنه می‌تواند بسازد، ظرف چند دقیقه محدود و حل می‌کنید.

اگر به دنبال زیرساختی هستید که خودِ این کلاس مشکلات را از ریشه کم کند — آدرسی تمیز و اختصاصی با شهرت شفاف، MTU پایدار، و امکان تنظیم رکوردهای معکوس — می‌توانید سرویس‌های آی‌پی ثابت و DNS اختصاصی dnsplus را ببینید، در صفحه‌ی درباره‌ی ما با تیم پشت آن آشنا شوید، و برای پرسش‌های فنی از راه تماس با ما در ارتباط باشید. مرجع رسمی همه‌ی کدها و پارامترهای DNS هم در جدول پارامترهای DNS در IANA در دسترس است.

#پرسش‌های پرتکرار

#چطور بفهمم مشکل از DNS است یا از خودِ اتصال؟

یک آزمون قطعی وجود دارد: یک آدرس عددی مثل 1.1.1.1 را مستقیم ping کنید و بعد یک نام دامنه مثل example.com را. اگر آدرس عددی جواب داد اما نام نه، اتصال شبکه‌تان سالم است و مشکل دقیقاً در تبدیل نام یعنی DNS است. اگر حتی آدرس عددی هم جواب نداد، مشکل پایین‌تر از DNS و در لایه‌ی مسیریابی یا آدرس‌دهی است. این تنها آزمون، بلافاصله نیمی از حالت‌ها را کنار می‌گذارد.

#تفاوت ‏NXDOMAIN و SERVFAIL چیست و کدام جدی‌تر است؟

NXDOMAIN یک پاسخ قطعی است: سرور با اطمینان می‌گوید این نام وجود ندارد؛ پس اگر انتظار داشتید نام موجود باشد، مشکل در طرف داده است (غلط املایی یا رکورد ساخته‌نشده). اما SERVFAIL یعنی سرور اصلاً نتوانست به نتیجه برسد و معمولاً نشانه‌ی نقص سمت سرور یا خطای اعتبارسنجی امنیتی است. برای رفع، NXDOMAIN را با بررسی املا و وجود رکورد دنبال کنید و SERVFAIL را با dig +trace و آزمودن حل‌کننده‌ی دیگر.

#آیا واقعاً باید برای تغییر DNS ۲۴ ساعت صبر کنم؟

نه. مفهوم «انتشار» یک تصور نادرست است؛ چیزی پخش نمی‌شود، بلکه کش‌های قدیمی صرفاً منتظر انقضای TTL خودشان می‌مانند. اگر پیش از تغییر، مقدار TTL رکورد را از چند ساعت به مثلاً ۳۰۰ ثانیه کاهش دهید و چند ساعت صبر کنید تا مقادیر بالای قبلی منقضی شوند، تغییر بعدی ظرف چند دقیقه همه‌جا دیده می‌شود. کنترل واقعی در دست شماست، نه در گذر زمان.

#آدرس ثابتم بعد از ری‌استارت می‌پرد؛ چرا؟

تقریباً همیشه به این دلیل که آدرس را به‌صورت موقتی تنظیم کرده‌اید، نه دائمی. فرمان‌های خط‌فرمانی که مستقیم آدرس را ست می‌کنند معمولاً فقط تا ری‌استارت بعدی می‌مانند. باید آدرس را در محل تنظیمات دائمی سیستم‌عامل ذخیره کنید (در ویندوز از پنجره‌ی تنظیمات آداپتور، در لینوکس در فایل تنظیمات شبکه‌ی توزیع). برای اطمینان، پس از ری‌استارت با ipconfig /all بررسی کنید که DHCP Enabled : No و همان آدرس مورد نظر باقی مانده باشد.

#پاک‌کردن کش DNS چه کاری می‌کند و کِی لازم است؟

کش، پاسخ‌های قبلی را برای سرعت نگه می‌دارد؛ اما اگر آدرس یک سایت عوض شده باشد، همان کش پاسخ کهنه می‌دهد. با ipconfig /flushdns در ویندوز کش سیستم‌عامل خالی می‌شود. یادتان باشد مرورگرها کش جدای خودشان را دارند؛ پس اگر بعد از پاک‌کردن کش سیستم هنوز مشکل هست، کش مرورگر را هم جداگانه خالی کنید یا با پنجره‌ی ناشناس آزمایش کنید.

#چرا بعضی سایت‌ها کند باز می‌شوند اما بعضی سریع؟

دو مظنون اصلی دارید. اول، مشکل IPv6 نیمه‌فعال: اگر رکورد AAAA وجود دارد ولی مسیر IPv6 خراب است، الگوریتم Happy Eyeballs اول IPv6 را امتحان می‌کند، شکست می‌خورد و با تأخیر به IPv4 برمی‌گردد؛ همان تأخیر، کندی مرموز است. دوم، افت MTU که باعث می‌شود صفحه‌های سنگین نیمه‌کاره بمانند. هر دو را با آزمون‌های ping -6 و ping -f -l که در متن آمد می‌توانید جدا کنید.

#معنی ستاره در خروجی ‏tracert چیست؟ یعنی مشکل دارم؟

نه لزوماً. بسیاری از مسیریاب‌های میانی عمداً به بسته‌های آزمایشی tracert پاسخ نمی‌دهند اما ترافیک واقعی را کامل عبور می‌دهند؛ پس یک ستاره در وسط مسیر معمولاً بی‌ضرر است. فقط وقتی نگران باشید که تأخیر از یک پرش به بعد به‌طور دائمی بالا برود و تا مقصد بالا بماند، یا ترِیس اصلاً به مقصد نرسد. الگو مهم است، نه یک ستاره‌ی تنها.

#چطور بفهمم آدرس ثابتم در فهرست سیاه است؟

می‌توانید اکتت‌های آدرس را معکوس کنید، به دامنه‌ی سرویس فهرست بچسبانید و یک پرسش DNS بفرستید؛ پاسخ 127.0.0.x یعنی آدرس در فهرست است و NXDOMAIN یعنی پاک است. اگر در فهرست بودید، اول علت اصلی (مثلاً پیکربندی نادرست ایمیل یا دستگاه آلوده) را رفع کنید و بعد از صفحه‌ی حذفِ همان سرویس درخواست خروج بدهید. داشتن یک آدرس اختصاصی و تمیز از ابتدا، این ریسک را به‌شدت کم می‌کند.