502 Bad Gateway -virhe tarkoittaa, että yhdyskäytävänä tai välityspalvelimena toimiva palvelin sai virheellisen vastauksen takanaan olevalta palvelimelta. Kävijä tavoitti jotain, yleensä nginxin, Apachen, kuormantasaajan tai CDN:n, mutta se ei saanut sovellukseltasi kunnollista vastausta. Sovellus kaatui, käynnistyy uudelleen, kuuntelee eri osoitteessa tai katkaisi yhteyden kesken kaiken.
502-virhe kertoo siis kahdesta palvelimesta, ei yhdestä. Tämä opas näyttää, miten selvität, mikä kerros sen palautti, miten korjaat tavalliset syyt ja miten kuulet seuraavasta 502-virheestä ennen asiakkaitasi.
Mitä 502-virhe kertoo
Useimmilla verkkosivustoilla kävijän ja koodin välissä on vähintään kaksi kerrosta. Edessä on CDN tai kuormantasaaja, nginxin kaltainen verkkopalvelin päättää yhteyden, ja sovellusprosessi, kuten PHP-FPM, Node.js, Gunicorn tai Java-palvelin, muodostaa sivun. Jokainen kerros välittää pyynnön seuraavalle ja palauttaa vastauksen takaisin.
502-virhe syntyy, kun jokin näistä kerroksista välittää pyynnön eikä saa takaisin mitään käyttökelpoista. Vertaa sitä muihin yhdyskäytävävirheisiin:
502 Bad Gateway: taustapalvelin vastasi jotain virheellistä, katkaisi yhteyden tai kieltäytyi siitä.
503 Service Unavailable: palvelu on ylikuormittunut, huoltotilassa tai sillä ei ole toimivaa palvelinta, jolle pyynnön voisi lähettää.
504 Gateway Timeout: taustapalvelin ei vastannut ajoissa.
Karkeasti sanottuna 502 tarkoittaa yleensä rikki tai ei käynnissä, 504 yleensä hidas. HTTP-tilakoodien lunttilappumme listaa loput koodiperheestä, ja 503-virheiden opas käsittelee ylikuormitusta ja huoltoja.
Selvitä, mikä kerros palautti 502-virheen
Ennen kuin muutat mitään, selvitä, kuka vastasi. Virhesivu ja vastauksen otsakkeet kertovat sen yleensä suoraan:
curl -sI https://www.example.com/checkout
HTTP/2 502
server: cloudflare
cf-ray: 8d2f1c3a5b7e4a21-ARN
server: cloudflare ja Cloudflaren virhesivu, joka nimeää palvelimesi: Cloudflare tavoitti alkuperäpalvelimesi, ja alkuperäpalvelin epäonnistui.
server: nginx tai Apache ja pelkistetty virhesivu: oma verkkopalvelimesi ei tavoittanut takanaan olevaa sovellusta.
server: awselb/2.0 tai muu kuormantasaaja: kuormantasaaja ei saanut kelvollista vastausta yhdeltäkään kohteelta tai siltä, jonka se valitsi.
Vertaa sitten pyyntöön, joka ohittaa uloimman kerroksen. Lähetä se suoraan alkuperäpalvelimelle tai sovelluksen porttiin itse palvelimella:
curl -sI –resolve www.example.com:443:203.0.113.10 https://www.example.com/checkout
curl -sI http://127.0.0.1:3000/checkout
Jos sovellus vastaa paikallisesti mutta ei välityspalvelimen kautta, tutki välityspalvelimen asetuksia. Jos se ei vastaa paikallisestikaan, ongelma on sovelluksessa.
Yleiset syyt ja niiden korjaaminen
Sovellusprosessi kaatui tai käynnistyy uudelleen
Tämä on yleisin syy. Välityspalvelimen takana olevalta prosessilta loppui muisti, se kohtasi käsittelemättömän poikkeuksen tai se lopetettiin, eikä välityspalvelimella ole ketään, jonka kanssa puhua. nginx kirjaa sen selvästi:
connect() failed (111: Connection refused) while connecting to upstream,
upstream: ”http://127.0.0.1:3000/checkout”
Tarkista, onko prosessi käynnissä ja miksi se pysähtyi:
systemctl status myapp
journalctl -u myapp –since ”30 min ago”
dmesg -T | grep -i ”killed process”
Rivi ytimen OOM killeriltä tarkoittaa, että palvelimelta loppui muisti. Uudelleenkäynnistys tuo sivuston takaisin, mutta todellinen korjaus on lisää muistia, vähemmän workereita tai muistivuodon löytäminen ja korjaaminen. Varmista, että palvelu käynnistyy kaatumisen jälkeen itsestään uudelleen, esimerkiksi asetuksella Restart=on-failure sen systemd-yksikössä.
PHP-FPM ei ole käynnissä tai workerit ovat loppu
PHP-sivustoilla nginx välittää pyynnöt PHP-FPM:lle socketin tai portin kautta. Jos PHP-FPM on pysähtynyt, socketin polku on väärä tai socketin käyttöoikeudet estävät nginxin pääsyn, jokainen PHP-sivu palauttaa 502-virheen:
connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)
Tämä viesti seuraa yleensä PHP-päivitystä: nginx osoittaa yhä vanhan version sockettiin. Osoita fastcgi_pass uuteen sockettiin ja lataa nginxin asetukset uudelleen. Jos loki sen sijaan sanoo server reached pm.max_children, kaikki workerit ovat varattuina, usein hidasta tietokantaa tai ulkoista API:a odottamassa. Nosta rajaa vain, jos palvelimella on muistia vapaana; muuten selvitä, mikä pitää workerit varattuina.
Väärä taustapalvelimen osoite tai portti
Siirron, kontin uudelleenrakentamisen tai portin vaihdon jälkeen välityspalvelin voi yhä välittää pyynnöt vanhaan osoitteeseen. Virheloki näyttää osoitteen, jota se yritti. Vertaa sitä siihen, missä sovellus todella kuuntelee:
ss -ltnp | grep -E ’:(3000|8000|9000)’
Dockerissa ja Kubernetesissa syy on usein palvelun nimi, joka ei enää selviä, kontti, joka kuuntelee kontin sisällä osoitteessa 127.0.0.1 eikä 0.0.0.0, tai readiness-tarkistus, joka merkitsee jokaisen podin valmistumattomaksi.
Taustapalvelin katkaisi yhteyden liian aikaisin
upstream prematurely closed connection while reading response header tarkoittaa, että sovellus otti pyynnön vastaan ja katkaisi sitten yhteyden. Tyypillisiä syitä ovat kaatuminen kesken pyynnön, worker, joka lopetettiin oman aikarajansa ylittymisen vuoksi, kuten Gunicornin –timeout tai PHP:n max_execution_time, sekä keep-alive-yhteydet, jotka sovellus sulkee aiemmin kuin välityspalvelin odottaa. Sovita aikakatkaisut niin, että välityspalvelin odottaa hieman kauemmin kuin sovellus, ei koskaan toisin päin, ja katso, mitkä pyynnöt ovat niin hitaita, että ne osuvat rajaan.
Liian suuret vastausotsakkeet
Suuret evästeet tai monet Set-Cookie-otsakkeet voivat olla isompia kuin nginxin puskuri taustapalvelimen vastausotsakkeille. nginx kirjaa silloin upstream sent too big header while reading response header from upstream ja palauttaa 502-virheen. Nosta puskureita varovasti:
proxy_buffer_size 16k;
proxy_buffers 8 16k;
# for PHP-FPM
fastcgi_buffer_size 32k;
fastcgi_buffers 8 16k;
Selvitä sitten, miksi otsakkeet kasvoivat. Eväste, joka kasvaa jokaisella käynnillä, on korjaamisen arvoinen bugi.
CDN ei saa yhteyttä alkuperäpalvelimeesi
Kun CDN tai kuormantasaaja palauttaa 502-virheen, tarkista, mitä sen ja palvelimesi välissä on. Palomuuri, joka estää CDN:n osoitealueet, alkuperäpalvelimen varmenne, jota CDN ei hyväksy, alkuperäpalvelin, joka puhuu vain HTTP/1.0:aa tai sulkee yhteydet liian herkästi, tai DNS-tietue, joka osoittaa vanhaan palvelimeen, päättyvät kaikki samalla tavalla. Testaa alkuperäpalvelinta suoraan yllä kuvatulla tavalla ja tarkista palomuuri ja TLS-asetukset molemmin puolin.
502-virheet julkaisujen aikana
Jos 502-virheitä näkyy kymmenen tai kaksikymmentä sekuntia kerrallaan ja aina julkaisun tienoilla, julkaisu itse aiheuttaa ne. Vanha prosessi pysähtyy, uuden käynnistyminen vie muutaman sekunnin, ja jokainen pyyntö siinä välissä epäonnistuu. Korjaus on julkaisujärjestys, jossa jokin on aina valmiina vastaamaan:
Käynnistä uusi versio vanhan rinnalle.
Odota, kunnes sen terveystarkistus menee läpi. Oppaamme health check -päätepisteen rakentamisesta näyttää, mitä tarkistuksen pitäisi testata.
Ohjaa liikenne uuteen versioon.
Anna vanhan version käsitellä keskeneräiset pyyntönsä loppuun ja pysäytä se sitten.
Prosessinhallintatyökalut ja orkestroijat tukevat tätä liukuvina tai katkottomina uudelleenlatauksina. Käytä niitä pelkän uudelleenkäynnistyksen sijaan.
Miten valvonta havaitsee 502-virheet
502-virhe on usein lyhyt. Julkaisu aiheuttaa kahdenkymmenen sekunnin virheet, worker kaatuu ja käynnistyy uudelleen, välimuisti kätkee ongelman useimmilta kävijöiltä. Kun joku avaa sivuston, se toimii taas, mutta kesken ostoksen ollut asiakas näki virheen.
Käytettävyyden valvonta pyytää sivujasi aikataulun mukaan ja tallentaa jokaisen tarkistuksen tilakoodin ja vasteajan. 502-virhe on epäonnistunut tarkistus. Ratkaisevaa on, mitä sen jälkeen tapahtuu:
Varmista virhe. Yksittäinen epäonnistunut pyyntö voi olla hetkellinen häiriö. Uptimecheck tarkistaa jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista ja varmistaa jokaisen virheen toisesta sijainnista ennen kuin häiriö avataan, joten yksittäinen yhteyskatko ei herätä ketään.
Näytä todisteet. Häiriön mukana tulee epäonnistunut vastaus, joten näet tilakoodin, server-otsakkeen ja virhesivun sekä kuvakaappauksen siitä, mitä kävijät näkivät. Kun palvelin ei vastannut lainkaan, saat sen sijaan verkkoreitin.
Tavoita oikeat ihmiset. Hälytykset menevät sähköpostiin, Slackiin, Microsoft Teamsiin, PagerDutyyn, webhookeihin ja muihin tiimisi käyttämiin hälytyskanaviin.
Valvo muutakin kuin etusivua. CDN pitää etusivun usein välimuistissa, ja se toimii yhä, vaikka kassa, kirjautuminen ja API palauttavat 502-virheen. Lisää käytettävyysvalvonta sivuille, jotka tuovat rahaa, ja API-valvonta päätepisteille, joita sovelluksesi kutsuvat. Kun 502-virhe johtuu sovelluksesta, jolta loppui muisti, palvelinvalvonta näyttää muistikäyrän katkon vieressä.
502-virheen tarkistuslista
Lue server-otsake ja virhesivu nähdäksesi, mikä kerros palautti 502-virheen.
Pyydä alkuperäpalvelinta ja sovelluksen porttia suoraan rajataksesi ongelmaa.
Lue välityspalvelimen virheloki samalta ajanhetkeltä: yhteys hylätty, suljettu liian aikaisin tai liian suuri otsake.
Tarkista, että sovellusprosessi on käynnissä, ja jos ei ole, miksi se pysähtyi.
Vertaa taustapalvelimen osoitetta, sockettia ja porttia siihen, missä sovellus kuuntelee.
Sovita aikakatkaisut niin, että välityspalvelin odottaa kauemmin kuin sovellus.
Julkaise niin, että uusi versio käynnistyy ennen kuin vanha pysäytetään.
Valvo tärkeitä sivuja ja päätepisteitä minuutin välein ja varmista jokainen virhe ennen hälytystä.