بررسی و رفع مشکل Server Not Found

خطای Server Not Found یعنی مرورگر نتوانسته نام دامنه را به یک آدرس IP تبدیل کند و در نتیجه درخواست شما اصلاً به سرور سایت نرسیده است. برخلاف تصور رایج این خطا از خانوادهٔ خطای ۴۰۴ نیست؛ ۴۰۴ را خودِ وب‌سرور برمی‌گرداند و یعنی سرور پیدا شده ولی آن مسیر وجود ندارد، در حالی که در Server Not Found هنوز به مرحلهٔ گفت‌وگو با سرور نرسیده‌ایم. به همین دلیل ریشهٔ مشکل تقریباً همیشه در لایهٔ دامنه و DNS است، نه در کدهای سایت.

همین خطا با نام‌های دیگر

هر مرورگر و ابزاری این وضعیت را با عبارت خودش نشان می‌دهد، اما همهٔ آن‌ها یک معنی دارند:

• فایرفاکس: Server Not Found
• کروم و اج: DNS_PROBE_FINISHED_NXDOMAIN یا This site can't be reached
• خط فرمان با curl: Could not resolve host
• دستور ping: unknown host یا Ping request could not find host

اگر به‌جای این‌ها «Connection timed out»، «Connection refused» یا خطای ۵۰۰ می‌بینید، مشکل از جنس دیگری است؛ نام دامنه ترجمه شده و بحث بر سر در دسترس بودن سرور است.

چهار لایه‌ای که باید جدا از هم بررسی شوند

عیب‌یابی درست یعنی به‌جای امتحان کردن تصادفی راهکارها، این چهار لایه را به ترتیب کنار بگذاریم:

• دامنه: آیا دامنه ثبت‌شده و فعال است یا منقضی شده؟
• DNS: آیا نیم‌سرورها درست تنظیم شده‌اند و رکورد A وجود دارد؟
• سمت کاربر: کش DNS، فایل hosts، resolver کارت شبکه، پروکسی و VPN.
• سرور: آیا سرویس وب روی سرور بالاست و پورت باز است؟

گام یک: آیا دامنه اصلاً resolve می‌شود؟

ساده‌ترین تست، یک پرس‌وجوی مستقیم DNS است. روی لینوکس یا مک:

• dig example.com +short — اگر خروجی خالی بود، هیچ رکورد A برگردانده نشده است.
• dig NS example.com +short — نیم‌سرورهایی که دامنه به آن‌ها معرفی شده را نشان می‌دهد.
• dig +trace example.com — مسیر پرس‌وجو را از ریشه تا نیم‌سرور نهایی دنبال می‌کند و دقیقاً نشان می‌دهد زنجیره کجا قطع شده است.

روی ویندوز معادل آن nslookup example.com است. اگر پاسخ NXDOMAIN گرفتید یعنی نام اصلاً وجود ندارد؛ ابتدا با whois example.com مطمئن شوید دامنه منقضی نشده باشد، چون دامنهٔ منقضی‌شده دقیقاً همین خطا را تولید می‌کند.

گام دو: مشکل فقط برای شماست یا برای همه؟

حالا همان پرس‌وجو را از یک resolver عمومی بگیرید و نتیجه را با resolver خودتان مقایسه کنید:

• dig @1.1.1.1 example.com +short
• dig @8.8.8.8 example.com +short

اگر resolver عمومی جواب می‌دهد ولی سیستم شما نه، مشکل محلی است و باید سراغ گام سه بروید. اگر هیچ‌کدام جواب نمی‌دهند، مشکل در سمت دامنه یا نیم‌سرور است. برای دیدن تصویر کامل‌تر می‌توانید با ابزار رایگان بررسی سلامت سایت وضعیت رکوردهای DNS، نیم‌سرورها و در دسترس بودن دامنه را هم‌زمان از چند resolver داخلی و بین‌المللی بگیرید؛ نتیجه به‌صورت گزارش قابل اشتراک‌گذاری در می‌آید. ابزارهای بیرونی مثل check-host.net هم برای مقایسهٔ نتیجه از نقاط مختلف جهان مفیدند.

گام سه: کش DNS، فایل hosts و resolver

اگر مشکل فقط روی سیستم شماست، به ترتیب این‌ها را بررسی کنید. اول کش DNS را خالی کنید:

• ویندوز: ipconfig /flushdns
• مک: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• لینوکس با systemd-resolved: sudo resolvectl flush-caches

بعد فایل hosts را نگاه کنید؛ در ویندوز C:\Windows\System32\drivers\etc\hosts و در لینوکس و مک /etc/hosts. اگر روزی برای تست، دامنه را به یک IP قدیمی نگاشت کرده‌اید و آن خط باقی مانده، مرورگر همیشه به همان IP می‌رود. این فایل ابزار خوبی برای تست موقت است، اما هر خطی که اضافه می‌کنید را بعد از تست حتماً حذف کنید.

در نهایت resolverهای کارت شبکه یا فایل /etc/resolv.conf سرور را بررسی کنید؛ یک resolver خاموش یا اشتباه، عملاً همهٔ ترجمه‌های نام را از کار می‌اندازد. اگر به VPN یا پروکسی متصل هستید، آن را قطع کنید و دوباره تست کنید، چون بسیاری از VPNها DNS را هم از مسیر خودشان عبور می‌دهند.

گام چهار: نیم‌سرورها و انتشار تغییرات

اگر تازه دامنه را ثبت کرده‌اید یا نیم‌سرورها را تغییر داده‌اید، این خطا کاملاً طبیعی است تا زمانی که تغییر منتشر شود. مدت انتشار ثابت نیست و به TTL رکوردها، سیاست کش ISPها و رویهٔ ثبت‌کنندهٔ دامنه بستگی دارد. در این فاصله بخشی از کاربران سایت را می‌بینند و بخشی نه، که کاملاً مورد انتظار است.

نکتهٔ مهم این است که نیم‌سرورها در پنل ثبت دامنه، و رکوردها در همان نیم‌سرورها تنظیم شوند؛ خطای رایج این است که رکورد A روی یک سرویس DNS ساخته می‌شود ولی دامنه هنوز به نیم‌سرورهای قبلی اشاره می‌کند. اگر می‌خواهید مدیریت رکوردها را از هاست جدا کنید و روی یک کلاستر مستقل نگه دارید، سرویس هاست DNS آنلاین سرور امکان افزودن و ویرایش آنی رکوردهای A، AAAA، CNAME، MX و TXT را روی کلاستر چهار نیم‌سروری فراهم می‌کند. برای گرفتن یک گزارش فنی از سلامت ناحیهٔ DNS هم intodns.com همچنان ابزار خوبی است.

گام پنج: دامنه resolve می‌شود ولی سایت بالا نمی‌آید

اگر dig یک IP سالم برمی‌گرداند، دیگر با Server Not Found طرف نیستید و باید در دسترس بودن سرویس را بسنجید:

• ping 203.0.113.10 — توجه کنید بی‌پاسخ ماندن ping لزوماً به معنی خاموش بودن سرور نیست، چون بسیاری از شبکه‌ها ICMP را فیلتر می‌کنند.
• nc -vz 203.0.113.10 443 — باز بودن پورت وب را مستقیم تست می‌کند.
• curl -I --resolve example.com:443:203.0.113.10 https://example.com — سایت را بدون دخالت DNS و مستقیماً از روی IP صدا می‌زند؛ بهترین راه برای جدا کردن مشکل DNS از مشکل وب‌سرور.

اگر پورت بسته است، سراغ فایروال بروید؛ اما به‌جای غیرفعال کردن کامل فایروال، فقط قانون مربوط به پورت‌های ۸۰ و ۴۴۳ را بررسی و در صورت نیاز اضافه کنید. خاموش کردن فایروال روی سرور عمومی یک ریسک امنیتی جدی است و اگر برای تست لازم شد، باید کوتاه و کنترل‌شده باشد. روی VPS هم فراموش نکنید که سرویس وب ممکن است بعد از یک ری‌استارت بالا نیامده باشد؛ وضعیت سرویس را با systemctl status nginx یا معادل آن بررسی کنید.

جمع‌بندی

مسیر عیب‌یابی را کوتاه کنید: اول با dig یا nslookup ببینید دامنه resolve می‌شود یا نه، بعد همان تست را از یک resolver عمومی تکرار کنید تا محلی یا سراسری بودن مشکل مشخص شود، سپس کش و فایل hosts را پاک‌سازی کنید و در آخر نیم‌سرورها و رکوردها را بازبینی کنید. اگر پس از این مراحل هنوز به نتیجه نرسیدید یا دسترسی لازم برای بررسی سمت سرور را ندارید، تیم پشتیبانی و مدیریت سرور می‌تواند بررسی لایهٔ DNS و وب‌سرور را برای شما انجام دهد.