اینترنت قطع شده یا فقط DNS مشکل دارد؟
پیش از عوضکردن DNS یا ریاستارت مودم، مشکل را مرحلهبهمرحله محدود کنید؛ چند بررسی ساده برای تفکیک خطای شبکه، نامگذاری و سرویس.

منبع فنی: DNS troubleshooting guidance — Microsoft Learn. مسیر تشخیص و مثال زیر، پیشنهاد تحلیلی این یادداشت است.
بازنشدن یک سایت، بهتنهایی معنای «قطع اینترنت» ندارد. ممکن است شبکه وصل باشد، نام دامنه اشتباه ترجمه شود یا خود سرویس پاسخ ندهد. از نظر من، اولین کار پشتیبانی باید تبدیل یک شکایت کلی به یک سؤال قابلآزمون باشد.
اول دامنه مشکل را کوچک کنیم
از کاربر بپرسید فقط یک سایت مشکل دارد یا چند سرویس؟ همکار کناری هم همین وضعیت را دارد؟ پاسخ این سؤالها گاهی از چند بار خاموش و روشنکردن مودم مفیدتر است. زمان شروع مشکل و نام دقیق سرویس را ثبت کنید.
سه بررسی بدون تغییر تنظیمات
در ویندوز، این فرمانها اطلاعات اولیه میدهند. نام نمونه را با دامنه واقعی سرویس جایگزین کنید.
ipconfig /all
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443
فرمان اول آدرس، دروازه و DNS تنظیمشده را نشان میدهد. فرمان دوم پاسخ نامگذاری را بررسی میکند. فرمان سوم برقراری اتصال TCP به پورت مشخص را میسنجد؛ موفقیت آن هنوز سلامت کامل وبسایت را ثابت نمیکند.
| مشاهده | بررسی بعدی |
|---|---|
| نام دامنه پاسخ نمیگیرد | دسترسی به DNS تنظیمشده و درستی نام |
| نام پاسخ میگیرد ولی اتصال پورت شکست میخورد | مسیر، فایروال یا شنونده سرویس |
| اتصال پورت برقرار است ولی صفحه خطا دارد | TLS، برنامه و وابستگیهای آن |
دام رایج: پاککردن شواهد
در یک سناریوی فرضی، فقط سامانه داخلی باز نمیشود ولی سایتهای عمومی سالماند. تغییر DNS کلاینت دامین به یک DNS عمومی ممکن است وضعیت را بدتر کند. همچنین بازکردن سایت HTTPS با IP، آزمون معادل دامنه نیست؛ نام میزبان و گواهی در نتیجه اثر دارند. پاسخندادن ping هم بهتنهایی قطع مسیر را اثبات نمیکند.
پیشنهاد من این است که پیش از هر تغییر، خروجی همان بررسی را نگه داریم و بعد فقط یک متغیر را تغییر دهیم. هدف، پیدا کردن مرز خرابی است؛ نتیجه باید بگوید «کدام مرحله شکست خورد»، نه صرفاً «با ریاستارت درست شد».
مطالعه مرتبط: بررسی سلامت واقعی سرویس.


