خطای DNS_PROBE_FINISHED_NXDOMAIN معمولاً یعنی نام دامنه‌ای که مرورگر می‌خواهد باز کند در مسیر پاسخ‌گویی DNS پیدا نشده است. برای رفع آن، ابتدا املای آدرس و وضعیت ثبت دامنه را بررسی کنید؛ سپس پاسخ دستگاه خودتان را با یک resolver دیگر و در نهایت سرور authoritative دامنه مقایسه کنید. نصب دوباره وردپرس، خرید SSL یا پاک‌کردن فایل‌های هاست، نقطه شروع مناسبی برای این خطا نیست.
این راهنما دو مسیر دارد: اگر بازدیدکننده هستید، با چند آزمون محدود مشخص می‌کنید مشکل به دستگاه و شبکه شما مربوط است یا به خود دامنه. اگر مالک سایت هستید، رکوردها و واگذاری DNS را بررسی می‌کنید. فرمان‌های نمونه برای دامنه فرضی example.com هستند و باید نام دامنه واقعی خودتان را جایگزین کنید؛ خروجی‌های این متن گزارش آزمایش سایت خاصی نیستند.
NXDOMAIN چه تفاوتی با قطعی هاست و خطای SSL دارد؟
مرورگر پیش از برقراری ارتباط HTTPS به یافتن مقصد نیاز دارد. اگر مرحله یافتن نام شکست بخورد، ممکن است اصلاً درخواستی به وب‌سرور نرسد. خطای گواهی SSL بعد از یافتن مقصد و در مرحله ارتباط امن مطرح می‌شود؛ خطاهای HTTP مانند 503 نیز پاسخ یک لایه سرویس هستند. بنابراین یک نشانه ظاهری مشترک، یعنی «سایت باز نمی‌شود»، می‌تواند علت‌های متفاوتی داشته باشد.
| نتیجه بررسی | معنای محتمل | قدم بعدی |
|---|---|---|
| فقط یک دستگاه خطا می‌دهد | کش، تنظیم resolver یا فایل hosts | مقایسه با دستگاه و اتصال دیگر |
| دامنه اصلی باز می‌شود، www باز نمی‌شود | رکورد جداگانه www کامل نیست | بررسی A یا CNAME همان نام |
| چند resolver پاسخ NXDOMAIN می‌دهند | نام، واگذاری یا زون نیازمند بررسی است | بررسی ثبت دامنه و authoritative |
| پاسخ SERVFAIL است | خطای پاسخ‌گویی یا اعتبارسنجی | بررسی DNSSEC و دسترس‌پذیری DNS |
| نام به IP تبدیل می‌شود، سایت خطای دیگری دارد | مرحله DNS عبور کرده است | بررسی HTTPS، وب‌سرور و برنامه |
۱. آدرس و محدوده مشکل را بدون تغییر تنظیمات مشخص کنید
نام را از نوار آدرس کپی کنید و وجود حروف اضافه، فاصله و پسوند اشتباه را بررسی کنید. دامنه اصلی و زیردامنه را جدا بنویسید. آدرس‌های example.com و www.example.com الزاماً یک رکورد مشترک ندارند. اگر لینک در پیام یا ایمیل دریافت شده، آدرس مورد انتظار را از راه شناخته‌شده کسب‌وکار پیدا کنید؛ شباهت نوشتاری نام‌ها دلیل یکسان‌بودن مقصد نیست.
همان آدرس را روی یک دستگاه دیگر و یک اتصال مستقل، مثلاً اینترنت همراه، امتحان کنید. نتیجه را همراه ساعت یادداشت کنید. اگر فقط یک مرورگر مشکل دارد، پنجره خصوصی و وضعیت DNS امن آن مرورگر را هم بررسی کنید. پنجره خصوصی همه کش‌های شبکه و سیستم‌عامل را پاک نمی‌کند؛ این آزمون برای محدودکردن مسئله است، نه اثبات سلامت همه مسیرها.
۲. پاسخ DNS دستگاه را ببینید
در ویندوز Command Prompt را باز کنید. فرمان نخست از resolver تنظیم‌شده دستگاه می‌پرسد و فرمان دوم پاسخ یک resolver عمومی را مقایسه می‌کند. در شبکه سازمانی، resolver داخلی می‌تواند عمداً پاسخ متفاوتی داشته باشد؛ پیش از تغییر تنظیمات عمومی، این تفاوت را با مدیر شبکه بررسی کنید.
nslookup example.com
nslookup example.com 1.1.1.1
nslookup www.example.com 1.1.1.1به نام پرسیده‌شده، آدرس سرور پاسخ‌دهنده و متن نتیجه توجه کنید. پیام timeout با NXDOMAIN یکسان نیست. اولی می‌گوید پاسخ به‌موقع نرسیده، در حالی که دومی پاسخ منفی درباره وجود نام است. همچنین پاسخ موفق A به‌تنهایی وضعیت AAAA یا همه زیردامنه‌ها را مشخص نمی‌کند. از یک نتیجه موفق برای اعلام سلامت کل DNS استفاده نکنید.
اگر resolver عمومی پاسخ درست دارد ولی دستگاه همچنان پاسخ منفی قدیمی نشان می‌دهد، می‌توانید کش DNS ویندوز را با فرمان زیر پاک کنید. این کار رکورد اشتباه روی سرور DNS را اصلاح نمی‌کند و کش مرورگر یا سرویس‌های دیگر ممکن است جدا باشد.
ipconfig /flushdns
۳. اگر مالک سایت هستید، ثبت دامنه و nameserver را بررسی کنید
در پنل ثبت‌کننده دامنه، اعتبار ثبت، وضعیت فعال‌بودن و nameserverهای فعلی را ببینید. نام‌های واردشده باید دقیقاً با اطلاعات ارائه‌دهنده DNS تطبیق داشته باشند. تمدید دامنه و سرویس میزبانی دو موضوع جدا هستند؛ فعال‌بودن هاست به معنی معتبرماندن ثبت دامنه نیست. برای دامنه‌هایی که تازه منتقل شده‌اند، سابقه تغییر واگذاری را هم بررسی کنید.
وجود رکورد در کنترل‌پنل قدیمی کافی نیست. باید همان سرویسی را ویرایش کنید که nameserverهای authoritative دامنه به آن واگذار شده‌اند. یک خطای رایج این است که کاربر رکورد را در cPanel تغییر می‌دهد، در حالی که DNS عمومی دامنه در یک سرویس دیگر مدیریت می‌شود. ابتدا محل واقعی مدیریت را مشخص کنید؛ سپس فقط رکورد مرتبط را تغییر دهید.
۴. رکورد نام اصلی، www و زیردامنه را جدا کنترل کنید
برای هر نام، نوع رکورد و مقصد مورد انتظار را از اطلاعات معتبر سرویس بگیرید. رکورد A به آدرس IPv4 اشاره می‌کند؛ AAAA برای IPv6 است و CNAME یک نام را به نام دیگر مرتبط می‌کند. افزودن یک IP حدسی برای رفع سریع خطا می‌تواند کاربر را به سرور اشتباه بفرستد. اگر سرویس مقصد رکورد مشخصی خواسته، همان مقدار را با نگارش صحیح وارد کنید.
مثلاً پس از انتقال هاست، ممکن است دامنه اصلی به IP جدید اشاره کند، اما CNAME مربوط به www هنوز به نامی حذف‌شده وابسته باشد. در این وضعیت، بررسی هر حلقه زنجیره CNAME مفیدتر از تعویض nameserver کل دامنه است. پیش از ویرایش، از زون خروجی بگیرید و رکوردهای ایمیل و تأیید مالکیت را هم حفظ کنید؛ مشکل وب، مجوز حذف همه TXT و MXها نیست.
۵. پاسخ authoritative را با کش resolver مقایسه کنید
در لینوکس یا محیطی که dig نصب است، ابتدا NSها را ببینید و سپس از یکی از سرورهای authoritative سؤال کنید. در فرمان دوم، نام نمونه ns1.example.net را با nameserver واقعی دامنه جایگزین کنید. ابزار dig ممکن است روی همه سیستم‌ها نصب نباشد؛ در هاست اشتراکی می‌توانید همین بررسی را از پشتیبانی درخواست کنید.
dig example.com NS
dig @ns1.example.net example.com A
dig @1.1.1.1 example.com Aاگر authoritative پاسخ درست دارد ولی resolver پاسخ منفی قبلی را نگه داشته، زمان کش منفی مطرح می‌شود. «همیشه ۲۴ یا ۴۸ ساعت صبر کنید» پاسخ دقیقی برای همه شرایط نیست؛ مدت واقعی به TTL، وضعیت واگذاری و نوع پاسخ بستگی دارد. اگر authoritative نیز رکورد را ندارد، صرف منتظرماندن خطا را درست نمی‌کند. اختلاف پاسخ NSهای مختلف هم باید بررسی شود.
اگر پاسخ SERVFAIL بود چه کنیم؟
SERVFAIL را با NXDOMAIN جایگزین نکنید. اگر پس از انتقال DNS رخ داده، ناسازگاری DS ثبت‌شده در رجیسترار با کلیدهای سرویس جدید از موارد قابل بررسی است. DNSSEC را بدون شناخت وضعیت کلید و واگذاری به‌صورت تصادفی روشن و خاموش نکنید. نام دامنه، زمان تغییر و پاسخ آزمون را برای تیم DNS بفرستید تا زنجیره اعتبارسنجی بررسی شود.
معیار پایان کار: فقط صفحه اصلی را آزمایش نکنید
پس از اصلاح، دامنه اصلی، www و زیردامنه‌های ضروری را از دو مسیر مستقل بررسی کنید. سپس بازشدن HTTPS، صفحه ورود و سرویس ایمیل را بسنجید. نتیجه موفق باید با مقصد مورد انتظار تطبیق داشته باشد. اگر DNS پاسخ درست دارد اما سایت هنوز 503 می‌دهد، از راهنمای رفع خطای 503 وردپرس استفاده کنید؛ ادامه تغییر DNS در آن مرحله احتمالاً مسیر درستی نیست.
برای درخواست پشتیبانی، بنویسید کدام نام خطا دارد، از چه شبکه‌ای تست شده و خروجی resolverها چه تفاوتی دارد. رمز پنل یا اطلاعات مشتری را در گزارش عمومی نگذارید. بررسی سلامت سایت آفاق هاست برای بررسی اولیه مفید است و برای پیگیری ثبت و واگذاری می‌توانید از خدمات دامنه آفاق هاست کمک بگیرید.
پرسش‌های رایج
آیا تعویض DNS دستگاه همیشه مشکل را حل می‌کند؟
فقط وقتی مشکل به resolver مسیر شما مربوط باشد ممکن است نتیجه تغییر کند. رکورد حذف‌شده یا دامنه منقضی با این کار اصلاح نمی‌شود؛ ابتدا مقایسه پاسخ‌ها را انجام دهید.
آیا رکورد AAAA اشتباه همان NXDOMAIN است؟
الزاماً خیر. وجود نام با مقصد اشتباه می‌تواند به خطای اتصال منجر شود. پاسخ DNS و رفتار اتصال را جدا بررسی کنید و از حذف IPv6 بدون شواهد پرهیز کنید.
آیا برای این خطا باید وردپرس را دوباره نصب کنم؟
خیر. ابتدا یافتن نام و مقصد شبکه را اصلاح کنید. اجرای وردپرس بعد از دسترسی به وب‌سرور مطرح می‌شود و نصب دوباره می‌تواند داده و تنظیمات سایت را بی‌دلیل در معرض تغییر قرار دهد.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.