502 Bad Gateway: vzroki in kako ga odpraviti

Kaj napaka pomeni

502 je odgovor strežnika, ki deluje. Spletni strežnik spredaj (nginx, Apache, uravnalnik obremenitve ali CDN, kot je Cloudflare) je prejel zahtevo, jo posredoval aplikaciji za seboj (PHP-FPM, procesu Node.js ali Python, zalednemu strežniku) in ni dobil uporabnega odgovora: povezava je bila zavrnjena, prekinjena ali je vrnila nesmisel. „Gateway“ je strežnik spredaj; „bad“ je tisto, kar je prišlo od zadaj.

502 torej pove dvoje hkrati: sprednji del teče, zadnji pa ne deluje ali je pokvarjen. To iskanje precej zoži.

Pogosti vzroki

1. Proces aplikacije ne teče. PHP-FPM se je zrušil ali je bil ustavljen, proces Node.js je umrl, vsebnik se je zaključil. Sprednji del se sploh ne more povezati.
2. Aplikacija je preobremenjena. Vsi delavci PHP-FPM so zasedeni, vrsta je polna, nove povezave se zavračajo. Pogosto po konici prometa ali počasni poizvedbi v podatkovno bazo, ki blokira vse delavce.
3. Napačen vtič (socket) ali vrata v konfiguraciji. Po posodobitvi ali zamenjavi različice PHP nginx še vedno kaže na php8.2-fpm.sock, medtem ko novi pool posluša na php8.4-fpm.sock.
4. Prekratke časovne omejitve. Zaledni del odgovori, vendar pozneje, kot je sprednji pripravljen čakati. Nekatere nastavitve to prijavijo kot 502, druge kot 504 Gateway Timeout.
5. Zaledni del pošlje preveliko glavo ali neveljaven odgovor. Tipično za ogrodja, ki v piškotke vpišejo veliko; nginx nato zabeleži „upstream sent too big header“.
6. CDN ne doseže vašega strežnika. Če je spredaj Cloudflare, stran 502 z logotipom Cloudflare pomeni, da Cloudflare od vašega izvornega strežnika ni dobil ničesar: požarni zid, napačen IP po selitvi ali pa strežnik preprosto ne deluje.

Če ste obiskovalec

502 na tuji strani ne morete odpraviti. Čez minuto enkrat znova naložite; če se ponavlja, mora ukrepati lastnik spletnega mesta. Za svoje spletno mesto berite naprej.

Če je to vaše spletno mesto: najprej preverite

Ali ne deluje za vse? Zaženite preverjanje delovanja spletnega mesta. Pokaže kodo stanja od zunaj in ali je odgovoril CDN ali izvorni strežnik.

Skupno gostovanje ali graditelj spletnih mest? 502 je tam skoraj vedno težava ponudnika gostovanja (preobremenjen pool PHP na skupnem vozlišču). Preskočite na sporočilo za svojega ponudnika spodaj.

Vaš lasten strežnik: prijavite se prek SSH in vprašajte spletni strežnik, kaj je šlo narobe.

# nginx: zadnje napake, najnovejše na dnu
sudo tail -n 50 /var/log/nginx/error.log

# Apache (Debian/Ubuntu)
sudo tail -n 50 /var/log/apache2/error.log

Tipične vrstice in kaj pomenijo:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory): PHP-FPM ne teče ali pa je pot do vtiča napačna.
• connect() failed (111: Connection refused) while connecting to upstream: na vratih zalednega dela nihče ne posluša.
• upstream prematurely closed connection: proces zalednega dela se je med odgovarjanjem zrušil, pogosto zaradi usodne napake PHP ali pomanjkanja pomnilnika.
• upstream sent too big header: povečajte medpomnilnike (glejte spodaj).
• (11: Resource temporarily unavailable): vsi delavci PHP-FPM so zasedeni.

Popravki na vašem lastnem strežniku

1. Zaženite ustavljeno storitev

# poiščite različico PHP-FPM, ki jo uporabljate
systemctl list-units --type=service | grep -E 'php|fpm'

systemctl status php8.3-fpm
sudo systemctl start php8.3-fpm

# aplikacije Node.js ali Python, ki jih upravlja systemd
sudo systemctl restart myapp

Če se storitev noče zagnati, je razlog v journalctl -u php8.3-fpm -n 50. Najpogostejši je poln disk (df -h), drugi sintaksna napaka v konfiguraciji poola (sudo php-fpm8.3 -t).

2. Popravite vtič ali vrata

Primerjajte, s čim se povezuje nginx in na čem posluša PHP-FPM:

grep -r fastcgi_pass /etc/nginx/sites-enabled/
grep -r '^listen' /etc/php/*/fpm/pool.d/

Obe vrednosti se morata ujemati. Po spremembi vedno preizkusite konfiguracijo, preden znova naložite:

sudo nginx -t && sudo systemctl reload nginx

Pri Apacheju in PHP-FPM prek mod_proxy_fcgi enako preverjanje velja za vrstico SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"; preizkusite z sudo apachectl configtest.

3. Dajte PHP-FPM prostora

Če dnevnik napak pravi, da so delavci zasedeni, ali server reached pm.max_children, zvišajte omejitev v datoteki poola (/etc/php/8.3/fpm/pool.d/www.conf):

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

Vsak delavec potrebuje pomnilnik (pri WordPressu pogosto od 30 do 80 MB); preverite free -m, preden zvišate število, in poiščite počasno poizvedbo ali vtičnik, ki delavce sploh zaseda.

4. Povečajte medpomnilnike za velike glave

V bloku strežnika nginx:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffers 8 16k;
proxy_buffer_size 32k;

5. Posebnosti WordPressa

502 takoj po posodobitvi vtičnika ali teme običajno pomeni, da PHP zmanjkuje pomnilnika ali pri vsaki zahtevi naleti na usodno napako. Preimenujte mapo vtičnika prek SFTP ali SSH, da ga izklopite (wp-content/plugins/plugin-name v plugin-name.off), nato znova naložite spletno mesto. Zvišajte memory_limit v poolu ali php.ini, če journalctl kaže „Allowed memory size exhausted“. Če uporabljate WP-CLI: wp plugin deactivate plugin-name.

6. Za Cloudflarom

Preverite, ali izvorni strežnik odgovarja neposredno: curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k. Če to deluje, požarni zid na strežniku morda blokira razpone naslovov Cloudflara ali pa zapis DNS v Cloudflaru kaže na star IP.

Ko je težava pri vašem ponudniku gostovanja

Pri skupnem gostovanju PHP-FPM ne morete znova zagnati. Ponudniku pošljite to, s časom in točno napako:

Pozdravljeni, moje spletno mesto example.com od približno 14:30 UTC vrača „502 Bad Gateway“. Zunanje preverjanje to potrjuje; na moji strani ni bilo nobenih sprememb. Ali lahko, prosim, preverite procese PHP in spletni strežnik na mojem računu za gostovanje in mi sporočite, ko spet deluje?

Preprečevanje naslednjega

502 je skoraj vedno ustavljen ali preobremenjen zaledni del, oboje pa je vidno, preden obiskovalci opazijo: storitev PHP-FPM, ki se je ustavila, pomnilnik, ki zmanjkuje, disk, ki se polni. Nadzor strežnikov z agentom poroča prav to od znotraj strežnika, preverjanja spletnih mest od zunaj pa ujamejo 502 v trenutku, ko se pojavi. Na vašem lastnem strežniku lahko Quick Fix znova zažene ustavljeno storitev, ko je preizkus njene konfiguracije uspešen; če je vzrok globlji, prevzame Deep Fix, 24 ur na dan.