«سایت باز نمیشود» یک نشانه است، نه یک مشکل. پشت آن می‌تواند DNS، شبکه، گواهی TLS، وب‌سرور یا خود برنامه باشد؛ و اگر ترتیب بررسی را نداشته باشید، ساعت‌ها در لایه‌ی اشتباه می‌گردید. این راهنما یک مسیر ثابت از پایین به بالا میدهد: اول DNS، بعد اتصال، بعد TLS و در پایان HTTP.
ترتیب درست بررسی
- DNS: نام دامنه به چه IP می‌رسد؟ درست است؟
- اتصال: پورت ۸۰/۴۴۳ آن IP از بیرون باز است؟
- TLS: گواهی معتبر، منقضی‌نشده و کامل است؟
- HTTP: کد وضعیت و ریدایرکت‌ها چیست؟
- برنامه: لاگ‌های وب‌سرور و برنامه چه می‌گویند؟
هر مرحله فقط وقتی معنا دارد که قبلی سالم باشد؛ مثلاً قبل از اینکه گواهی را مقصر بدانید، مطمئن شوید دامنه اصلاً به سرور درست می‌رسد.
۱. DNS: دامنه به کجا اشاره می‌کند؟
dig +short A example.com
dig +short AAAA example.com
dig +short NS example.com
dig +short CNAME www.example.com
# از یک resolver مشخص (ببینید مشکل محلی است یا عمومی)
dig @1.1.1.1 +short A example.comاگر dig در دسترس نیست، nslookup example.com هم همین کار را می‌کند؛ یا از ابزار آنلاین برای دیدن همه‌ی رکوردها و TTL استفاده کنید.
چیزهایی که باید دنبالشان باشید
- IP اشتباه: رکورد A به سرور قدیمی اشاره می‌کند؟ (بعد از مهاجرت رایج است.)
- AAAA فراموش‌شده: اگر رکورد IPv6 دارید ولی سرور روی IPv6 گوش نمی‌دهد، بعضی کاربران (آن‌ها که IPv6 دارند) خطا می‌گیرند و بقیه نه؛ از دلایل رایج مشکل «فقط برای بعضی کاربران کار نمی‌کند» است.
- TTL بالا: تغییر رکورد تا پایان TTL دیده نمیشود. پیش از مهاجرت TTL را کم کنید.
- NS ناهمخوان: اگر دامنه را از ثبت‌کننده به سرویس DNS دیگری منتقل کرده‌اید، مطمئن شوید NSهای ثبت‌کننده و NSهای آن سرویس یکی است.
- CNAME روی دامنهی ریشه (apex): مجاز نیست و باعث خرابی رکوردهای دیگر (مثل MX) می‌شود.
- رکورد TXT برای ایمیل: SPF، DKIM و DMARC همگی در TXT هستند و یک خطای تایپی می‌تواند ایمیل‌ها را به اسپم بفرستد.
۲. اتصال: آیا به پورت می‌رسیم؟
nc -zv 203.0.113.10 443
curl -v --connect-timeout 5 https://example.com -o /dev/nullاگر اتصال برقرار نمیشود: فایروال میزبان (ufw، firewalld)، گروه امنیتی ابر، یا اینکه سرویس اصلاً روی 0.0.0.0 گوش نمی‌دهد. با ss -ltnp روی خود سرور ببینید کدام پورت‌ها باز و روی کدام آدرس‌اند.
۳. TLS: گواهی سالم است؟
از سمت کلاینت، همه‌چیز را یک‌جا با openssl می‌توان دید:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameپرچم -servername را فراموش نکنید؛ سرورهایی که چند دامنه دارند بر اساس SNI گواهی را انتخاب می‌کنند و بدون آن گواهی پیش‌فرض را می‌دهند که معمولاً با دامنهی شما نمی‌خواند. ابزار آنلاین همین اطلاعات را همراه با کل زنجیره نشان میدهد:
خطاهای رایج مرورگر و علت واقعی‌شان
| پیام | علت معمول |
|---|---|
| NET::ERR_CERT_DATE_INVALID | گواهی منقضی شده، یا ساعت دستگاه کاربر اشتباه است |
| NET::ERR_CERT_COMMON_NAME_INVALID | نام دامنه در SAN گواهی نیست (مثلاً گواهی بدون www) |
| NET::ERR_CERT_AUTHORITY_INVALID | گواهی خودامضا یا زنجیرهی میانی ارسال نشده |
| ERR_SSL_PROTOCOL_ERROR | سرور TLS را درست پیکربندی نکرده یا روی آن پورت اصلاً TLS نیست |
| ERR_TOO_MANY_REDIRECTS | حلقه‌ی ریدایرکت (اغلب بین HTTP و HTTPS پشت یک پروکسی) |
| DNS_PROBE_FINISHED_NXDOMAIN | دامنه رکورد ندارد یا هنوز منتشر نشده |
curl، یک اپلیکیشن موبایل یا یک سرویس دیگر خطا میدهد، تقریباً مطمئن باشید زنجیرهی میانی (intermediate) ناقص است. مرورگرها گاهی گواهی میانی را خودشان پیدا و کش می‌کنند؛ کلاینت‌های دیگر نه. فایل fullchain.pem را به‌جای فقط گواهی دامنه به وب‌سرور بدهید.۴. HTTP: کد وضعیت و ریدایرکت‌ها
curl -sIL https://example.com | grep -iE '^(HTTP|location|server|strict-transport|cache-control)'پرچم -L ریدایرکت‌ها را دنبال می‌کند و می‌توانید زنجیره را ببینید. چند الگوی پرتکرار:
- ۳۰۱ به خودش: معمولاً «ریدایرکت به HTTPS» در برنامه و در پروکسی هم‌زمان فعال است و یکدیگر را خنثی می‌کنند. هدر
X-Forwarded-Protoرا بررسی کنید. - ۵۰۲/۵۰۴: وب‌سرور سالم است ولی برنامه‌ی پشتش نه؛ لاگ Nginx یا برنامه را ببینید.
- ۴۰۳ فقط برای بعضی کاربران: محدودیت جغرافیایی، WAF یا فایروال CDN.
- پاسخ کهنه: هدر
Cache-ControlوAgeرا ببینید؛ شاید CDN نسخه‌ی قبلی را نگه داشته است.
چک‌لیست یک‌صفحه‌ای
dig +short A دامنهبه IP درست می‌رسد؟ (و AAAA هم درست است یا وجود ندارد؟)- NS دامنه نزد ثبت‌کننده با سرویس DNS شما یکی است؟
- پورت ۴۴۳ از بیرون باز است؟
- گواهی منقضی نشده، SAN شامل دامنه است و زنجیره کامل است؟
- ریدایرکت‌ها حلقه نمی‌سازند و کد نهایی ۲۰۰ است؟
- لاگ وب‌سرور و برنامه خطایی دارند؟
اگر پشت Nginx هستید، راهنمای پیکربندی Nginx به‌عنوان Reverse Proxy بخش مفصل‌تری درباره‌ی ۵۰۲ و ۵۰۴ دارد.
جمع‌بندی
ترتیب ثابت DNS، اتصال، TLS و HTTP از بررسی‌های تکراری و اتلاف وقت جلوگیری می‌کند. بعد از رفع مشکل، با مانیتورینگ (برای مثال بررسی انقضای گواهی و پاسخ‌گویی HTTP) از تکرار آن جلوگیری کنید؛ هشداردهی اصولی نشان میدهد کدام هشدارها ارزش دارند. اگر شبکه‌ی داخلی را طراحی می‌کنید، راهنمای CIDR و زیرشبکه‌بندی را هم ببینید.