502 Bad Gateway i WordPress: find fejlen i den rigtige rækkefølge

Kort svar: 502 Bad Gateway betyder, at en server, der står som mellemled, fik et ugyldigt svar fra det næste led i kæden. Som besøgende kan du kun genindlæse og vente. På dit eget WordPress-site skyldes fejlen oftest en PHP-proces, der stopper, bliver genstartet eller svarer for sent – men den kan også komme fra webserveren eller en proxy. Notér tidspunkt og adresse, tjek serverens logfiler, og rul den seneste ændring tilbage, før du hæver grænser eller rydder al cache.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Et kontrolleret 502-svar er efterprøvet med Hostious Article Lab 1.4.1; den konkrete årsag skal altid findes i sitets egne proxy-, webserver- og PHP-logs.

En 502-fejl fortæller ikke, at “WordPress er nede”. Den fortæller, at et led foran WordPress ikke kunne bruge svaret fra næste led. Det afgørende spørgsmål er derfor ikke, hvilken tilfældig indstilling du skal ændre, men hvilket led der returnerede 502.

Hvis fejlsiden tydeligt er brandet med Cloudflare og viser en Cloudflare-fejlkode, skal du gå til den relevante Cloudflare-guide. Denne artikel handler om den generiske 502 mellem browser, proxy, webserver og PHP/WordPress.

Før du ændrer noget: Tag en aktuel backup, og undgå at genstarte tjenester, tømme alle caches eller deaktivere alle plugins, før du har gemt tidspunkt, URL og relevante logs. De første spor forsvinder ofte efter en genstart.

Hvad betyder 502 Bad Gateway?

502 Bad Gateway er en statuskode fra en server, der står som mellemled. En hjemmeside leveres sjældent af én maskine: din browser taler med en proxy eller webserver, som sender forespørgslen videre til det program, der bygger siden. Får mellemleddet et svar, det ikke kan bruge – eller bliver forbindelsen afbrudt – svarer det 502.

Fejlen kan hedde “502 Bad Gateway”, “HTTP Error 502”, “502 Proxy Error” eller bare “Bad Gateway”. Det er samme fejl. Den bliver tit forvekslet med sine naboer:

Kode	Betyder	Typisk årsag
500 Internal Server Error	Serveren stoppede selv midt i arbejdet	En fatal fejl i koden eller en fejl i opsætningen
502 Bad Gateway	Mellemleddet fik et ugyldigt svar fra næste led	Programmet bag stoppede eller blev genstartet
503 Service Unavailable	Serveren kan ikke tage imod lige nu	Overbelastning eller vedligeholdelse
504 Gateway Timeout	Mellemleddet fik intet svar i tide	En forespørgsel, der tager for lang tid

Får du en af naboerne i stedet, har de deres egne guider: 500 Internal Server Error og 504 Gateway Timeout.

Ser du 502 Bad Gateway på en side, du ikke selv ejer?

Så ligger fejlen næsten altid hos hjemmesiden og ikke hos dig. Du kan udelukke din egen ende på to minutter:

• Genindlæs siden én gang efter et halvt minut. Mange 502-fejl varer kun, mens en tjeneste genstarter.
• Prøv et privat vindue eller en anden browser.
• Skift netværk. Prøv via mobilens net. Virker siden dér, så genstart din router.
• Vent, og prøv igen senere. Du kan ikke rette en 502 på en andens server.
• Skriv til ejeren med adresse og tidspunkt, hvis fejlen bliver ved.

Er det dit eget WordPress-site, så fortsæt herunder.

Sådan bekræfter du, at det faktisk er en 502-fejl

Åbn den fejlende URL i et privat vindue og i en almindelig fane. Notér:

• den præcise URL og klokkeslættet;
• om fejlen rammer hele siden, kun /wp-admin/ eller kun én tung handling;
• om den opstår ved et almindeligt GET-kald eller efter en gem-, import- eller uploadhandling;
• om fejlsiden nævner en bestemt proxy, webserver eller CDN;
• om et nyt forsøg straks virker.

I browserens udviklerværktøj åbner du Network, genindlæser siden og vælger den request, der fejlede. Gem statuskode, response headers og den første del af response body. Et skærmbillede af en 502-side er nyttigt, men en tidsstemplet request er langt bedre, fordi den kan matches mod serverloggene.

Symptom	Sandsynligt lag	Kontrol	Næste skridt
Hele siden giver stabilt 502	Webserver, PHP-FPM eller origin	Hostingstatus og error logs på samme tidspunkt	Gå til trin 2
Kun gemning, import eller checkout fejler	Lang eller fatal PHP-request	PHP-log og requestens varighed	Gå til trin 3
Fejlen kom lige efter plugin-/temaopdatering	PHP-kompatibilitet eller fatal fejl	Seneste deploy og fatal-loglinje	Gå til trin 4
Fejlen er kortvarig ved trafikspids	FPM-workers, CPU/RAM eller proceskø	Ressourcegraf og FPM/webserverlog	Gå til trin 5
Cloudflare-brandet 52x-side	Cloudflare til origin	Ray ID, tidspunkt og Cloudflare-fejlkode	Brug Cloudflare-fejlhubben

1. Kontrollér om fejlen stadig er aktiv

Test forsigtigt tre forskellige URL-typer:

1. forsiden;
2. en enkel offentlig underside;
3. den handling, der oprindeligt fejlede.

Hvis kun den tunge handling fejler, er en generel DNS- eller browserfejl usandsynlig. Hvis alle tre fejler, skal du kontrollere hostingens statusvisning og webserver/PHP-tjenester, før du ændrer WordPress.

Undgå gentagne hårde genindlæsninger eller parallelle tests på en presset server. De kan gøre en kort worker-kø værre og sløre det oprindelige mønster.

2. Match requesten med webserver- og PHP-loggene

Find loglinjer inden for samme minut som din test. Kig især efter:

• upstream– eller gatewayfejl;
• PHP fatal errors;
• en PHP-proces, der blev afsluttet eller genstartet;
• “connection reset”, “prematurely closed” eller lignende upstream-spor;
• worker-/procesgrænser, der er nået;
• en timeout knyttet til den samme sti.

Start ved den første relevante fejl, ikke ved den sidste advarsel i filen. En log kan indeholde gamle notices, bots og mislykkede loginforsøg, som intet har med din 502 at gøre.

Eksempel på den rigtige dokumentation: “14:07:32, POST til en bestemt adminhandling, 502 i browseren og en fatal fejl i plugin X på samme sekund.” Et løst screenshot af en 502-side uden tidspunkt er ikke nok til at udpege årsagen.

3. Find den konkrete handling, der presser PHP

Hvis 502 kun opstår under import, backup, billedbehandling, builder-gemning eller en anden tung handling, så test på staging med den mindste reproducerbare opgave:

1. Gentag med ét lille datasæt eller én side.
2. Notér requestens varighed og memory-/timeoutfejl i loggen.
3. Deaktivér kun den funktion, der udfører arbejdet, eller sænk batchstørrelsen.
4. Gentag testen med samme input.

At hæve memory_limit, request-timeout eller proxy-timeout kan flytte fejlen uden at løse den. En import, der låser en worker i flere minutter, er stadig et driftsproblem, selv hvis gatewayen venter længere.

Brug vores særskilte guide til Allowed memory size exhausted, hvis loggen indeholder den præcise memory-fejl. Brug guiden til kritisk fejl i WordPress, hvis loggen peger på en fatal PHP-fejl.

4. Rul den seneste kodeændring tilbage målrettet

Kom fejlen umiddelbart efter en opdatering eller kodeændring, så begynd med den ene ændring:

• rul plugin eller tema tilbage til den kendt fungerende version;
• gendan den ændrede fil fra backup;
• fjern den senest tilføjede snippet via det værktøj, der oprettede den;
• brug WordPress Recovery Mode, hvis den udpeger en komponent.

Deaktivér ikke alt på live som første forsøg. Hvis du ikke kender komponenten, skal isoleringen ske i staging eller med en sessionbaseret konfliktmetode. Den fulde metode findes i guiden til plugin- og temakonflikter.

5. Undersøg proceskø og ressourcer

En 502 under belastning kan opstå, når webserveren ikke kan få et brugbart svar fra PHP-poolen. Sammenhold:

• antal samtidige PHP-processer;
• CPU- og RAM-forbrug;
• genstarter eller worker-terminationer;
• langsomme requests og databasekald;
• tidspunktet for cron, backups, scans eller imports.

Det er mønstret, der er beviset. En høj CPU-graf alene viser ikke, hvilket plugin der er skyld i problemet. Et tilbagevendende requestspor til samme handling gør.

Hvis ressourcerne er pressede, så fjern eller planlæg den dokumenterede belastning, reducer batchstørrelsen eller få hosting til at kontrollere PHP-poolen. Opgrader ikke en hostingpakke på baggrund af én 502 uden logmæssig sammenhæng.

6. Kontroller cache og proxy uden at gøre problemet værre

En gammel fejlrespons kan i sjældne tilfælde ligge i et cachelag, men en almindelig browsercache er sjældent årsagen til, at origin returnerer 502. Kontrollér i denne rækkefølge:

1. Se response headers for tegn på cache HIT/MISS og request-id.
2. Bypass cachen for én testrequest, hvis platformen understøtter det.
3. Purge kun den berørte URL, hvis testen viser en cachet fejl.
4. Undgå fuld preload, mens origin stadig er ustabil.

En fuld purge efterfulgt af preload kan sende mange uncached requests til en presset PHP-pool. Vent med den samlede cacheopvarmning, til origin svarer stabilt.

Som negativ kontrol bør du samtidig hente en enkel statisk fil og en let WordPress-side. Hvis begge svarer hurtigt, mens kun importrequesten giver 502, har du afgrænset problemet til den tunge PHP-sti. Hvis også den statiske fil fejler, skal undersøgelsen flyttes ud foran WordPress til webserver, proxy eller netværk.

Gentag kontrollen i samme tidsvindue som den fejlende handling, og notér begge svartider.

Sådan verificerer du rettelsen

Rettelsen er først sandsynliggjort, når du kan gentage den oprindelige handling:

• fem kontrollerede forsøg giver den forventede 2xx- eller 3xx-status;
• både offentlig side og relevant adminhandling virker;
• den tidligere fejlende request har normal response body;
• der kommer ingen ny matchende error-loglinje;
• ressourcegrafen viser ikke en ny proceskø efter testen.

Test som anonym bruger og som den relevante indloggede rolle. Hvis fejlen kun opstod ved en POST-request, er det ikke nok at se, at forsiden svarer 200.

Rollback

Hvis en ændring ikke hjælper, så før den straks tilbage til den dokumenterede starttilstand:

• gendan den tidligere plugin-/temaversion eller fil;
• sæt en ændret timeout eller memorygrænse tilbage;
• genetablér den oprindelige proxy-/cacheindstilling;
• genstart kun den tjeneste, du faktisk ændrede, og gem tidspunktet.

Lav én ændring ad gangen. Ellers kan du ikke vide, hvad der fjernede fejlen, eller hvad der skabte en ny.

Hvornår skal hosting eller udvikler hjælpe?

Kontakt hosting, når loggen peger på PHP-FPM, worker-grænser, webserver, disk, netværk eller en origin-tjeneste, du ikke selv kan styre. Send URL, tidspunkt, request-id og den relevante loglinje – aldrig adgangskoder eller hele logfiler med persondata.

Kontakt plugin- eller temaudvikleren, når den samme komponent konsekvent udløser fejlen på staging og loggen peger på dens fil/funktion. Ved gentagne driftsfejl kan Hostious WordPress-support hjælpe med at samle beviserne og afgrænse laget.

Sådan dokumenterer du en 502-fejl

Dokumentér én request fra symptom til log i stedet for at samle tilfældige skærmbilleder:

1. Original browser-Network-visning af en kontrolleret 502-request med URL, status og tidspunkt; testdomæne og data anonymiseres.
2. Hostingens logvisning med den ene matchende gateway-/PHP-linje markeret.
3. Ressourcegraf i det femminutters vindue omkring requesten.
4. Før/efter-Network-visning af præcis samme test.

Gem også requestens status og headers sammen med den tidsmæssigt matchende error-loglinje. Et terminaludsnit må ikke indeholde origin-IP, brugernavn eller absolut kundesti.

Kommer 502-fejlen igen og igen? Med WordPress hosting hos Hostious svarer dansk support døgnet rundt og hjælper med at finde fejlen i serverens logfiler. Fra planen WP StartUp til 89 kr./md. ekskl. moms får du staging, så en opdatering kan prøves på en kopi, før den rammer det rigtige site – og vi flytter sitet uden beregning. Vil du blive, hvor du er, passer en WordPress serviceaftale til 99 kr./md. ekskl. moms opdateringer, backup og overvågning af oppetiden.

Ofte stillede spørgsmål om 502 Bad Gateway

Er en 502 Bad Gateway altid serverens skyld?

Nej. En WordPress 502 Bad Gateway betyder kun, at et led i kæden ikke fik et gyldigt svar. Årsagen kan ligge i en proxy som Cloudflare, i webserveren, i PHP-FPM eller i et plugin, der får PHP til at stoppe. Loggene afgør hvor.

Hvor længe varer en 502-fejl typisk?

Det afhænger af årsagen. Genstarter PHP efter en opdatering, er fejlen ofte væk på under et minut. Kommer den igen på samme URL eller tidspunkt, er der et mønster – så skal du matche requesten med error loggen i stedet for at vente.

Hjælper det at rydde cachen ved 502?

Sjældent. Cachen kan skjule eller forsinke symptomet, men den fjerner ikke årsagen. Ryd først cache, når du har gemt logs og tidspunkter – ellers mister du de spor, der viser, hvilket led der fejlede.

Hvad er forskellen på 502 Bad Gateway og 504 Gateway Timeout?

Ved 502 fik mellemleddet et svar, det ikke kunne bruge, eller forbindelsen blev afbrudt. Ved 504 kom der slet ikke noget svar inden for tidsgrænsen. 502 peger derfor oftest på et program, der stopper, mens 504 peger på noget, der er for langsomt.

Kan jeg selv fjerne en 502 Bad Gateway som besøgende?

Som regel ikke. Fejlen opstår mellem hjemmesidens egne servere. Du kan genindlæse siden, prøve et andet netværk og vente lidt – men bliver fejlen ved, er det ejeren af siden, der skal rette den.

Skader 502 Bad Gateway min placering i Google?

Ikke, hvis fejlen er kortvarig. Søgemaskinen prøver igen senere. Får dens robot 502 gennem længere tid, besøger den siden sjældnere, og sider kan ende med at falde ud af søgeresultaterne. Tilbagevendende 502-fejl skal derfor findes og rettes, ikke bare ventes ud.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress
• Allowed memory size exhausted
• Find en plugin- eller temakonflikt
• 504 Gateway Timeout i WordPress
• 500 Internal Server Error i WordPress
• WordPress hosting hos Hostious – managed WordPress med daglig backup og staging fra WP StartUp