عیب‌یابی خطاهای 502 و 504 در Nginx

این گام روی همان میزبان آزمایش یا عیب‌یابی اجرا می‌شود. نام و نسخهٔ سیستم‌عامل و بسته‌های فهرست‌شده را با محیط انتخابی تطبیق دهید. اگر ابزاری نصب نیست، ابتدا از مخزن رسمی فعال و روند مجاز مدیریت بستهٔ خود آن را نصب کنید؛ این آموزش سرور موجود را دوباره نصب یا مخزنش را عوض نمی‌کند.

مسیر پیش‌فرض برای Ubuntu 26.10 بررسی شده است؛ گزینه‌های 26.04 LTS و 24.04 LTS نیز در دسترس‌اند. بسته‌ها را با همان انتشار و پیکربندی واقعی میزبان تطبیق دهید.

Nginx باید از قبل نصب و سرویس موجود شناخته‌شده باشد. در بسته‌های متداول این خانواده، سرویس nginx و فایل اصلی nginx.conf زیر شاخهٔ /etc/nginx قرار دارند؛ محل include و لاگ را از پیکربندی مؤثر خودتان پیدا کنید، نه از نام توزیع. روی RPM چیدمان sites-enabled اوبونتو را فرض نکنید.

خروجی کامل پیکربندی ممکن است دادهٔ خصوصی داشته باشد؛ آن را عمومی نکنید. مسیر لاگ خطای فعال را در تنظیمات همین آموزش وارد کنید.

cat /etc/os-release
dpkg-query -W curl iproute2
command -v curl ss nginx
sudo nginx -t
sudo nginx -T 2>&1 | sed -n '1,100p'
systemctl show nginx.service -p FragmentPath -p DropInPaths -p ExecStart

روی سرور Nginx، ساعت و نسخه را ثبت کنید و یک درخواست بدون کوکی، توکن یا پارامتر حساس به app.example.com بفرستید. اگر ریشهٔ سایت برای این کار مناسب نیست، نشانی یک مسیر سلامت تأییدشده را در پنل جایگزین کنید.

زمان اولین بایت در این درخواست شامل کارهای DNS، اتصال و TLS هم هست؛ آن را زمان اجرای خالص برنامه ندانید. کد پاسخ یا خطای curl را همراه زمان UTC نگه دارید تا بتوانید همان رخداد را در لاگ پیدا کنید.

date -u +'%Y-%m-%dT%H:%M:%SZ'
nginx -v
curl --noproxy '*' --connect-timeout 3 --max-time 15 -sS -o /dev/null -w 'status=%{http_code} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' 'https://app.example.com/'

لاگ کرنل را در بازهٔ زمانی همان خطا بررسی کنید. روی میزبان دارای AppArmor، denial پروفایل فعال ممکن است مستقل از مجوز Unix یا شبکه باشد؛ پروفایل را صرفاً برای سبزشدن تست خاموش نکنید. این بررسی جای لاگ برنامه و بررسی سیاست واقعی میزبان را نمی‌گیرد.

sudo journalctl -k --since '-10 min' --no-pager -n 120

از همان میزبان به 127.0.0.1 روی پورت 8000 درخواست بفرستید. نام دامنه را در هدر Host نگه دارید تا برنامهٔ درست انتخاب شود. اگر این مسیر هم مشکل دارد، پیش از تغییر پروکسی، خود برنامه و مسیر اتصال به آن را بررسی کنید.

این درخواست پورت خصوصی را عمومی نمی‌کند. نمونه برای بک‌اند HTTP است؛ اگر ارتباط Nginx با برنامه HTTPS است، باید نام و گواهی همان ارتباط را درست اعتبارسنجی کنید و این نمونه را عیناً اجرا نکنید.

curl --noproxy '*' --connect-timeout 3 --max-time 15 -H 'Host: app.example.com' -sS -o /dev/null -w 'status=%{http_code} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' 'http://127.0.0.1:8000/'

این پنل روی میزبان بک‌اند اجرا می‌شود. شنوندهٔ پورت را با تنظیم واقعی Nginx و فرایند سرویس example-app.service تطبیق دهید. برنامه‌ای که فقط داخل namespace دیگری گوش می‌دهد، الزاماً از میزبان قابل دسترس نیست.

وضعیت active به معنی آماده‌بودن worker یا سالم‌بودن دیتابیس نیست. قبل از restartهای پیاپی، خطاهای اخیر برنامه را بخوانید. لاگ ممکن است اطلاعات خصوصی داشته باشد؛ آن را محلی بررسی و پیش از اشتراک‌گذاری پاک‌سازی کنید.

sudo ss -lntp 'sport = :8000'
sudo systemctl status 'example-app.service' --no-pager
sudo journalctl -u 'example-app.service' --since '-10 min' --no-pager -n 100