U ziet een sobere pagina met “502 Bad Gateway”, soms met het logo van nginx of Cloudflare eronder. Uw site is niet te zien, maar het voelt anders dan een gewone storing: de foutpagina komt duidelijk niet van WordPress. Dat klopt ook. Bij een 502 is de fout ontstaan ergens tussen de bezoeker en uw site in.
Om een 502 Bad Gateway bij WordPress te begrijpen, moet u weten dat een verzoek aan uw website tegenwoordig zelden rechtstreeks bij WordPress uitkomt. Er zitten schakels tussen, en elke schakel kan de boodschapper zijn van deze fout. In dit artikel leggen we uit wat die schakels zijn, waarom de oorzaak meestal bij de hosting ligt, en in welke gevallen het toch uw eigen site is.
Wat een gateway is en waarom hij “bad” kan zijn
Als iemand uw adres intypt, komt het verzoek eerst aan bij een webserver, vaak nginx of Apache. Die webserver voert zelf geen PHP uit; hij geeft het verzoek door aan een apart programma dat dat wel doet, meestal PHP-FPM. Dat programma laadt WordPress, bouwt de pagina en stuurt het antwoord terug naar de webserver, die het aan de bezoeker levert.
Gebruikt u daarnaast een dienst als Cloudflare, dan zit er nog een schakel vóór: Cloudflare ontvangt het verzoek en stuurt het door naar uw hosting. Een “gateway” is in deze keten elke server die verzoeken doorgeeft. Een 502 betekent: de gateway stuurde het verzoek door, maar kreeg geen antwoord of een antwoord dat hij niet kon lezen.
De fout zit dus vrijwel altijd in de schakel achter degene die de foutpagina toont. Ziet u een Cloudflare-pagina, dan kon Cloudflare uw hosting niet bereiken. Ziet u een nginx-pagina, dan kon nginx PHP niet bereiken.
Vijf oorzaken van een 502 Bad Gateway bij WordPress
Oorzaak 1: PHP-FPM is vastgelopen of overbelast
De meest voorkomende oorzaak op de hosting zelf. PHP-FPM heeft een beperkt aantal “werkers” die tegelijk verzoeken kunnen afhandelen. Zijn ze allemaal bezet, bijvoorbeeld door een piek in bezoekers of een aantal trage verzoeken, dan wacht nginx even en geeft daarna op met een 502 of 504. Is PHP-FPM helemaal gecrasht, dan komt de 502 direct.
Wat u ziet: de fout komt en gaat, vooral op drukke momenten. Wat u doet: herstart PHP als het hostingpaneel dat toestaat, en kijk naar het patroon. Bij herhaling is het pakket te klein of maakt iets op uw site de verzoeken te traag.
Oorzaak 2: een verzoek dat te lang duurt
Hier komt uw eigen site in beeld. Een pagina die tientallen seconden nodig heeft, bijvoorbeeld door een trage databasequery, een import, een externe koppeling die niet reageert of een plugin die bij elk verzoek iets ophaalt bij een andere server, loopt tegen de wachttijd van de gateway aan. Strikt genomen geeft dat vaak een 504, maar veel configuraties tonen dan toch een 502.
Aanwijzing: de fout komt alleen op bepaalde pagina’s voor, of alleen in het beheer, of alleen bij een bepaalde handeling zoals opslaan of exporteren. Dan is het geen hostingprobleem maar iets in WordPress dat te lang doet over zijn werk.
Oorzaak 3: Cloudflare of een andere tussenlaag
Gebruikt u Cloudflare, dan heeft de 502 vaak een eigen foutcode erbij, zoals 502 of 520 tot en met 526. Die cijfers zeggen wat er misging: de hosting reageerde niet, gaf een leeg antwoord, had een probleem met het SSL-certificaat, of het IP-adres van de hosting klopte niet meer. Dat laatste zien we regelmatig na een verhuizing: de site is verhuisd, maar Cloudflare stuurt het verkeer nog naar de oude server. Hoe Cloudflare werkt en wat er kan misgaan, leest u in dit artikel over Cloudflare bij WordPress.
Snelle test: zet Cloudflare tijdelijk in de stand waarin het verkeer niet via hen loopt (het “grijze wolkje” bij de DNS-instelling) en kijk of de site dan wel laadt. Zo ja, dan zit het probleem in de verbinding tussen Cloudflare en uw hosting, niet in uw site.
Oorzaak 4: een verkeerde serverconfiguratie
Na een wijziging door de hosting, of na een PHP-versiewissel, kan de verbinding tussen webserver en PHP verkeerd staan. Dit is puur een hostingzaak; u ziet het aan het feit dat de site plotseling op alle pagina’s 502 geeft, zonder dat u iets heeft veranderd, en vaak ook andere sites op dezelfde server.
Oorzaak 5: de hostingpartij heeft een storing
Blijft de eenvoudigste verklaring. Kijk op de statuspagina van de hosting, of zoek op de naam van de hosting in combinatie met “storing”. Bij een grote storing bent u niet de enige en is er niets dat u aan uw kant kunt doen.
Snel bepalen: hosting of site?
- Kijk naar de foutpagina. Cloudflare-opmaak wijst naar de verbinding met de hosting; nginx- of Apache-opmaak wijst naar PHP op de server.
- Test meerdere pagina’s. Overal 502: eerder hosting of configuratie. Alleen specifieke pagina’s of handelingen: eerder uw site.
- Test het tijdstip. Alleen op drukke momenten of bij back-ups en imports: overbelasting, dus een combinatie van te weinig capaciteit en te zware taken.
- Open het foutenlog. Regels als “upstream timed out” of “connect() failed” bij nginx bevestigen dat PHP niet bereikt werd. Een fatale PHP-fout in het log wijst juist naar uw site; dat is dan eigenlijk het scenario uit het artikel over de 500-fout, met een andere boodschapper.
- Vraag de hosting. Geef tijdstip en foutcode door. Een goede hostingpartij kan in enkele minuten zien of PHP-FPM is herstart of tegen limieten liep.
Wat u aan uw kant kunt verbeteren
Ook als de hosting de boodschapper is, kunt u de kans op herhaling verkleinen. Een paginacache zorgt dat de meeste bezoekers helemaal geen PHP nodig hebben, waardoor de werkers vrij blijven. Externe koppelingen (voorraad, beoordelingen, koersen) horen op de achtergrond te draaien, niet bij elk bezoek. Zware taken als back-ups horen ‘s nachts. En een site die in het beheer traag is, verdient een aparte blik, want die traagheid is precies wat bij drukte omslaat in een 502.
Een tandartspraktijk in Almere had wekenlang 502-fouten in het beheer bij het opslaan van pagina’s. De hosting zag niets. De oorzaak: een SEO-plugin die bij elke opslag een externe dienst raadpleegde die niet meer bestond, en daar dertig seconden op wachtte. Eén instelling uitzetten en het was voorbij.
Wie het patroon niet zelf herkent, kan een specialist laten kijken. Het uitzoeken van een 502 valt onder het oplossen van WordPress-fouten, en juist bij deze code zit het werk in het zoeken: logs lezen, tijdstippen vergelijken, de hosting bevragen. WebMaintor doet dat tegen een vast starttarief en met een schriftelijke uitleg van de oorzaak, zodat u weet of het aan uw hosting lag of aan uw site. Dat onderscheid is precies wat u nodig heeft om te beslissen of u moet verhuizen of alleen iets moet aanpassen.
