502 Bad Gateway: ko tas patiesībā nozīmē un kā to novērst

Jūs atverat savu vietni, un satura vietā redzat tukšu lapu ar uzrakstu 502 Bad Gateway. Tas izskatās biedējoši, taču vairumā gadījumu risinājums ir vienkāršs. Apskatīsim, kas notiek un kā atjaunot jūsu vietnes darbību.
Ko patiesībā nozīmē 502?
Kad apmeklētājs pieprasa lapu, pieprasījums parasti iziet caur diviem slāņiem: frontend tīmekļa serveri (parasti Nginx) un backend lietojumprogrammu serveri (PHP-FPM, Apache, Node.js vai ko citu). Nginx saņem pieprasījumu, pārsūta to uz backend un gaida atbildi.
502 Bad Gateway nozīmē, ka Nginx mēģināja saņemt atbildi no backend, bet saņēma kaut ko nederīgu vai nesaņēma atbildi vispār. Backend vai nu avarēja, atteica savienojumu vai atgrieza kaut ko tādu, ko Nginx nevarēja interpretēt.
Izplatīts maldīgs priekšstats: 502 nenozīmē, ka jūsu serveris nedarbojas. Pats serveris ir kārtībā — problēmas ir lietojumprogrammai aiz Nginx.
Visbiežākie cēloņi
Backend serviss ir apstājies. Tas ir galvenais iemesls. PHP-FPM avarēja, Apache uzkārās vai Node.js process klusi beidzās. Nginx nav ar ko sazināties.
Serverim pietrūkst RAM. Kad atmiņas kļūst maz, Linux var automātiski apturēt resursietilpīgus procesus. Šo mehānismu sauc par OOM killer, un PHP-FPM vai MySQL parasti ir tā pirmie upuri. Ja tas notiek regulāri, apsveriet iespēju pievienot swap failu kā drošības rezervi.
PHP-FPM darba procesu pūls ir izsmelts. Ja jūsu vietne saņem vairāk vienlaicīgu pieprasījumu, nekā PHP-FPM spēj apstrādāt, jaunie pieprasījumi tiek ievietoti rindā un galu galā pārsniedz gaidīšanas laiku. Tas bieži notiek, kad meklētājprogrammu roboti pārmeklē jūsu vietni pārāk agresīvi — par to, kā ar to tikt galā, mēs rakstījām mūsu robotu bloķēšanas ceļvedī.
Nepareizi konfigurēts ligzdas fails vai ports. Nginx sagaida atrast PHP-FPM noteiktā Unix ligzdā vai TCP portā. Ja ceļš Nginx konfigurācijā neatbilst PHP-FPM konfigurācijai, jūs redzēsiet 502 kļūdas uzreiz pēc jebkurām izmaiņām.
Kā to diagnosticēt
Lai veiktu tālāk norādītās darbības, pieslēdzieties savam serverim, izmantojot SSH. Kā to izdarīt, varat uzzināt mūsu SSH rakstā.
1. solis. Pārbaudiet, vai backend darbojas
Pārbaudiet sava backend servisa statusu:
sudo systemctl status php8.2-fpm
Aizstājiet php8.2-fpm ar savu faktisko PHP versiju vai backend servisa nosaukumu. Ja izvadē ir norādīts inactive (dead) vai failed, tā ir jūsu problēma. Restartējiet to:
sudo systemctl restart php8.2-fpm
Pēc tam vēlreiz pārbaudiet statusu, lai pārliecinātos, ka tas ir veiksmīgi palaists.
2. solis. Pārbaudiet Nginx kļūdu žurnālu
Kļūdu žurnāls gandrīz vienmēr precīzi pasaka, kas nogāja greizi:
sudo tail -30 /var/log/nginx/error.log
Ja izmantojat FASTPANEL®, žurnālus varat skatīt arī tieši tīmekļa saskarnē: atveriet vietnes kartīti, dodieties uz sadaļu "Logs" un pārbaudiet cilni "Frontend Error Log".
Tālāk ir norādīti visbiežāk sastopamie kļūdu ziņojumi un to nozīme:
connect() failed - Connection refused - backend serviss nedarbojas. Restartējiet to, kā parādīts 1. solī.
connect() failed - No such file or directory - Nginx mēģina sasniegt Unix ligzdu, kas neeksistē. Pārbaudiet, vai ligzdas ceļš jūsu Nginx konfigurācijā atbilst tam, ko PHP-FPM patiesībā izveido.
upstream sent too big header - backend atgrieza HTTP galvenes, kas ir pārāk lielas noklusējuma buferim. Pievienojiet šīs rindas savas Nginx vietnes konfigurācijai server blokā:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
Pēc rediģēšanas pārbaudiet konfigurāciju un pārlādējiet Nginx:
sudo nginx -t && sudo systemctl reload nginx
3. solis. Pārbaudiet servera resursus
free -h
Ja kolonnā available ir redzams mazāk nekā 100-200 MB brīvās atmiņas, visticamāk, jūsu serverim pietrūkst RAM. Pārbaudiet, kas to patērē:
ps aux --sort=-%mem | head -10
Ja galvenais cēlonis ir atmiņas trūkums, ātrākais pagaidu risinājums ir pievienot swap failu. Tomēr swap diskā ir daudz lēnāks nekā RAM, un to nevajadzētu uzskatīt par pastāvīgu risinājumu. Ja jūsu serverim regulāri pietrūkst atmiņas, ir pienācis laiks vai nu optimizēt savas lietojumprogrammas, vai pāriet uz plānu ar vairāk RAM.
Secinājums
502 Bad Gateway gandrīz vienmēr ir backend problēma — avarējis serviss, izsmelti darba procesi vai nepietiek atmiņas. Pārbaudiet backend statusu, izlasiet Nginx kļūdu žurnālu un apskatiet resursu izmantojumu. Lielākajā daļā gadījumu atbildi atradīsiet dažu minūšu laikā.
Ja nevēlaties ar to tikt galā vienatnē, kodu.cloud nodrošinām bezmaksas tehnisko atbalstu 24/7 ar katru VPS un dedicated server. Visi mūsu klienti bez papildu maksas saņem arī FASTPANEL® Extended, kas ievērojami atvieglo žurnālu analīzi un servisu pārvaldību, izmantojot tīmekļa saskarni.