Sسامنیزیادداشت‌های فناوری
خانه / عیب‌یابی
عیب‌یابیزمان مطالعه: ۷ دقیقه

چک‌لیست عملی عیب‌یابی خطای 403، 502 و SSL

روشی مرحله‌به‌مرحله برای بررسی DNS، HTTPS، وضعیت سرویس وب و لاگ‌های مرتبط.

اول مسئله را دقیق توصیف کنیم

وقتی یک سایت باز نمی‌شود، قبل از تغییر تنظیمات، این اطلاعات را ثبت کنید: نام دامنه، مسیر دقیق، زمان خطا، IP کلاینت، کد HTTP و اینکه مشکل برای همه کاربران رخ می‌دهد یا فقط بعضی‌ها.

مرحله اول: DNS و مقصد واقعی

dig @1.1.1.1 example.com A +short
getent ahostsv4 example.com
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\\n' https://example.com

اگر DNS عمومی و Resolver سیستم پاسخ متفاوتی می‌دهند، مسیر اتصال و کش DNS را بررسی کنید؛ ممکن است درخواست‌ها به مقصدهای متفاوت برسند.

مرحله دوم: بررسی گواهی TLS

openssl s_client -connect example.com:443 \\
  -servername example.com \\
  -verify_hostname example.com

به نام گواهی، صادرکننده، زمان انقضا و Verify return code دقت کنید. اگر گواهی خودامضا یا نام متفاوتی می‌بینید، ممکن است مقصد ورودی اشتباه یا گواهی مناسب روی سرویس اعمال نشده باشد.

مرحله سوم: بررسی پاسخ سرویس وب

اول وضعیت پاسخ HTTP و آدرس مقصد اتصال را مشاهده کنید. سپس مطمئن شوید سرویس موردنظر روی پورت درست فعال است و گواهی آن به نام دامنه مربوط می‌شود.

curl -I https://example.com
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com
ss -lntp | grep -E ':(80|443)\b'

خطای 403 به معنی منع دسترسی است؛ 502 معمولاً یعنی سرویس واسط از بالادست پاسخ مناسب نگرفته است. برای یافتن علت، نتیجه درخواست را با لاگ و تنظیمات همان سرویس مقایسه کنید.

مرحله چهارم: لاگ و وضعیت Nginx

sudo nginx -t
systemctl status nginx --no-pager
sudo tail -n 50 /var/log/nginx/access.log
sudo tail -n 50 /var/log/nginx/error.log

اگر درخواست مسدودشده اصلاً در Access Log سرور اصلی ثبت نشده باشد، ممکن است قبل از رسیدن به سرویس مقصد پاسخ داده شده باشد؛ برای نتیجه‌گیری، گزارش‌های مسیر جلویی را هم بررسی کنید.

تفسیر ساده خطاها

اصل عیب‌یابی: هر بار فقط یک متغیر را تغییر دهید، نتیجه را ثبت کنید و در صورت نیاز به تنظیم قبلی برگردید.
← بازگشت به صفحه اصلی