Nginx’da 502 Bad Gateway va 504 Gateway Timeout: sabablari va yechimi

502 va 504 nimasi bilan farq qiladi

Reverse proxy sifatida Nginx sahifani o‘zi yaratmaydi — so‘rovni upstream ilovaga (PHP-FPM, Node.js, Python, Go) uzatadi va uning javobini qaytaradi.

• 502 Bad Gateway — Nginx normal javob ola olmadi: ulanish rad etildi, soket topilmadi, jarayon javob o‘rtasida qulab tushdi yoki javob sarlavhalari buferga sig‘madi.
• 504 Gateway Timeout — ulanish bor, lekin backend ajratilgan vaqtga ulgurmadi.

Soddaroq aytganda: 502 — «backend yo‘q yoki noto‘g‘ri javob berdi», 504 — «backend bor, lekin juda sekin».

1-qadam. error.log’ni o‘qing

Konfiguratsiyani taxminan o‘zgartirmang. Avval xatolar logini oching:

sudo tail -n 50 /var/log/nginx/error.log

Yo‘l boshqacha bo‘lishi mumkin — konfiguratsiyadagi error_log direktivasini tekshiring. Odatiy satrlar va ularning ma’nosi:

2-qadam. Upstream jarayoni va soketini tekshiring

Ilova tirikligiga va aynan proxy_pass yoki fastcgi_passda ko‘rsatilgan manzilni tinglayotganiga ishonch hosil qiling:

systemctl status php8.2-fpm        # yoki servisingiz nomi
ss -ltnp | grep 3000               # Node.js TCP porti
ls -l /run/php/                    # PHP-FPM unix soketlari
curl -I http://127.0.0.1:3000      # Nginx’ni chetlab so‘rov

Agar to‘g‘ridan-to‘g‘ri curl javob bermasa, muammo Nginx’da emas. Ilovaning o‘z loglarini ko‘ring: journalctl -u servis-nomi.

Ko‘p uchraydigan xato — manzillar mos kelmasligi: Nginx 127.0.0.1:3000ga murojaat qiladi, ilova esa faqat IPv6 localhostni yoki boshqa portni tinglaydi. Yana biri — PHP yangilangandan keyin soket nomi o‘zgargan, konfiguratsiyada esa eskisi qolgan.

3-qadam. Soketga huquqlar

Permission denied bo‘lsa, Nginx qaysi foydalanuvchi nomidan ishlashini (nginx.confdagi user) va soket egasini solishtiring. PHP-FPM pool konfiguratsiyasida quyidagini belgilang:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

PHP-FPM’ni qayta ishga tushiring. SELinux yoqilgan bo‘lsa, rad etish undan kelishi mumkin — audit logni ko‘ring.

4-qadam. Taymautlar (504 ni davolash)

Avval so‘rov nega uzoq davom etishini aniqlang: sekin SQL, tashqi API, og‘ir hisobot. Taymautni faqat haqiqatan uzoq amallar uchun, yaxshisi alohida location uchun oshiring:

location /reports/ {
    proxy_connect_timeout 10s;
    proxy_read_timeout    120s;
    proxy_send_timeout    120s;
    proxy_pass http://127.0.0.1:3000;
}

PHP-FPM uchun muqobili — fastcgi_read_timeout. Yodda tuting: PHP’ning o‘zida max_execution_time, pool’da esa request_terminate_timeout bor. Agar ular Nginx taymautidan kichik bo‘lsa, jarayon oldinroq o‘ldiriladi va siz 504 o‘rniga 502 olasiz.

Uzoq vazifalarni (import, fayl generatsiyasi) fon navbatiga chiqarish, foydalanuvchiga esa holatni ko‘rsatish to‘g‘riroq.

5-qadam. Buferlar

upstream sent too big header xatosi odatda katta cookie yoki ko‘p sarlavhalar sababli chiqadi. Buferlarni kattalashtiring:

proxy_buffer_size        16k;
proxy_buffers            8 16k;
proxy_busy_buffers_size  32k;
# PHP-FPM uchun
fastcgi_buffer_size      32k;
fastcgi_buffers          16 16k;

Shu bilan birga ilova cookie’larni keraksiz kattalashtirmayotganini tekshiring.

6-qadam. PHP-FPM va Node.js qulashi

Agar 502 yuklama ostida paydo bo‘lib, keyin yo‘qolsa — backend ulgurmayapti:

• PHP-FPM: pool logida server reached pm.max_children settingni qidiring. Demak, barcha worker’lar band. pm.max_childrenni xotirani hisobga olib oshiring: har bir worker alohida xotira egallaydi.
• Node.js: ushlanmagan istisno butun jarayonni qulatadi. Ilovani jarayonlar menejeri (systemd, PM2, restartli Docker) ostida ishga tushiring, shunda u avtomatik qayta ko‘tariladi, sababini esa loglardan qidiring.
• OOM killer: dmesg | grep -i killni tekshiring. Agar yadro xotira yetishmasligi sababli jarayonni o‘ldirsa, optimallashtirish yoki ko‘proq RAM kerak.

Har qanday o‘zgarishdan keyin konfiguratsiyani tekshiring va serverni to‘xtatmasdan qayta yuklang:

sudo nginx -t && sudo systemctl reload nginx

Chek-list

1. error.logni o‘qib, aniq xatoni toping.
2. Upstream ishlayotgani va to‘g‘ridan-to‘g‘ri javob berishini tekshiring.
3. Manzil, port yoki soket yo‘lini solishtiring.
4. Unix soketga huquqlarni tekshiring.
5. 504 uchun — sekin joyni toping, keyin taymautni nuqtaviy oshiring.
6. «too big header» uchun — buferlarni kattalashtiring.
7. Worker limitlari va OOM killer’ni tekshiring.