Du besöker din webbplats och möts av en vit skärm med tre ord: "502 Bad Gateway." Trafiken flödar, men besökarna ser ett felmeddelande istället för innehåll. Försäljningen stannar av, SEO-rankingen sjunker och du slösar tid på att gissa.

502-felet ser skrämmande ut, men under huven är det helt enkelt ett kommunikationsfel mellan servrar. Din webbplats är inte trasig, data har inte försvunnit, och i de flesta fall tar lösningen fem till femton minuter. Nedan följer en steg-för-steg-guide som tar dig från de enklaste kontrollerna till djupare diagnostik.

💡 Snabb översikt:

• Uppdatera sidan och kontrollera om värdservern ligger nere
• Rensa webbläsarens cache och inaktivera CDN tillfälligt
• Om felet kvarstår, inaktivera tillägg via FTP och kontrollera temat
• Återställ .htaccess och kontakta ditt webbhotell när allt annat misslyckas

Vad är ett 502 Bad Gateway-fel

När du öppnar en webbplats skickar webbläsaren en HTTP-förfrågan. På serversidan tar en omvänd proxy (Nginx, Apache) emot den och fördelar förfrågningar mellan applikationsservern (PHP), databasen, den statiska webbservern och CDN. Varje nod hanterar sin del och returnerar resultatet till proxyservern. Proxyn sätter ihop svaret och levererar det till webbläsaren, och sidan laddas.

Ett 502-fel uppstår när en av servrarna i den kedjan returnerar ett ogiltigt svar till proxyservern. Proxyn kan inte sätta ihop sidan och visar "Bad Gateway". Webbläsaren rapporterar ärligt att gatewayen mellan servrarna tog emot något oväntat.

Utåt sett kan felet ta olika former: "502 Bad Gateway", "502 Service Temporarily Overloaded", "HTTP 502", "Nginx 502 Bad Gateway", "Proxy Error". Innebörden är densamma: någonstans i kedjan finns ett avbrott.

Varför 502-felet uppstår

Orsakerna är nästan alltid serversidan, men ibland utlöser dina egna åtgärder på webbplatsen det:

• Serveröverbelastning. En plötslig trafiktopp förbrukar webbhotellets resurser, och PHP-processerna hinner inte med förfrågningskön.
• Felaktigt tillägg eller tema. Kod som orsakar ett fatalt PHP-fel avbryter applikationsserverns svar, och proxyn får ingenting.
• CDN-problem. Cloudflare, KeyCDN eller en annan innehållsleveranstjänst kan inte ansluta till ursprungsservern och returnerar en 502.
• Felaktiga DNS-poster. Efter byte av webbhotell eller uppdatering av DNS-servrar har posterna ännu inte propagerats, så webbplatsen är tillfälligt oåtkomlig.
• Skadad.htaccess. Trasig syntax eller motstridiga rewrite-regler stör förfrågningshanteringen.
• PHP-minnesgränsen överskriden. Ett tungt tillägg eller skript förbrukar allt tillgängligt minne, och processen kraschar.

Låt oss nu gå igenom varje lösning steg för steg, från den snabbaste till den mer komplexa.

Steg 1. Uppdatera sidan

Först och enklast: tryck på F5 eller Ctrl+R. Om felet orsakades av en kortvarig serverstörning kommer den upprepade förfrågan att lyckas. Testa att öppna webbplatsen i en annan webbläsare eller via mobildata; detta utesluter ett problem hos dig.

Kontrollera om webbplatsen fungerar för resten av världen med hjälp av isup.me eller Down For Everyone Or Just Me. Om tjänsten visar att webbplatsen bara är nere för dig är problemet lokalt, så gå vidare. Om webbplatsen är otillgänglig för alla har värdservern troligtvis kraschat eller så har en blockering tillämpats på leverantörsnivå.

Steg 2. Rensa webbläsarens cache

Webbläsaren cachar inte bara bilder och stilmallar utan även felaktiga serversvar. En hård uppdatering (Ctrl+F5 på Windows, Cmd+Skift+R på macOS) tvingar webbläsaren att begära sidan igen, förbi den lokala cachen.

Om en hård uppdatering inte hjälpte, rensa cachen helt. I Chrome: Inställningar → Säkerhet och integritet → Rensa webbinformation → "Cachade bilder och filer". Vi har täckt detaljerade instruktioner för olika webbläsare och rensning av cache på WordPress-sidan i en separat guide.

Steg 3. Inaktivera CDN tillfälligt

Innehållsleveransnätverk som Cloudflare eller KeyCDN dirigerar trafik genom sina egna servrar. Om ett fel uppstår på CDN-sidan eller en felaktig brandväggsregel är konfigurerad kommer besökare att se en 502 även när ursprungsservern är fullt fungerande.

För att testa denna hypotes, pausa CDN i dess kontrollpanel. Cloudflare: gå till Overview → Pause Cloudflare. KeyCDN och liknande tjänster: hitta knappen Inaktivera eller Pausa i panelen. Efter inaktivering, uppdatera din webbplats. Om felet försvinner ligger problemet på CDN-sidan; kontakta deras support.

Medan CDN är inaktiverat arbetar webbplatsen direkt från ditt webbhotell, så hastigheten kan sjunka något, men tillgängligheten återställs. Vi jämförde populära CDN-tjänster och deras konfiguration i en artikel om gratis CDN för WordPress.

Steg 4. Kontrollera DNS-inställningar

Efter byte av webbhotell eller uppdatering av NS-poster propageras DNS-information över nätverket under en period som sträcker sig från flera timmar till 48 timmar. Under denna tid kan vissa besökare hamna på den gamla servern, som inte svarar eller svarar felaktigt.

Om du nyligen migrerade din webbplats, vänta 24 timmar; det räcker vanligtvis. Spola dessutom din lokala DNS-cache: på Windows öppna Kommandotolken och kör ipconfig /flushdns; på macOS kör sudo dscacheutil -flushcache och sudo killall -HUP mDNSResponder. Uppdatera sedan sidan.

Steg 5. Inaktivera tillägg via FTP

Den vanligaste orsaken till en 502 på WordPress är en tilläggskonflikt. Ett enda problematiskt tillägg kan orsaka ett fatalt PHP-fel som tar ner hela webbplatsen. Eftersom WordPress adminpanel är otillgänglig under en 502 måste du inaktivera tillägg via filsystemet.

Anslut till servern via FTP (använd FileZilla, WinSCP) eller öppna Filhanteraren i cPanel. Navigera till webbplatsens rotmapp (vanligtvis public_html):

Gå in i wp-content och hitta mappen plugins. Döp om den, till exempel till plugins.old. Detta inaktiverar omedelbart alla tillägg på en gång. Tilläggsdata raderas inte när du byter namn på mappen; inställningarna finns kvar i databasen:

Uppdatera webbplatsen. Om den fungerar är problemet ett av tilläggen. Döp tillbaka mappen till plugins, gå till adminpanelen och aktivera tilläggen ett och ett, kontrollera webbplatsen efter varje aktivering. När du hittar den skyldige, radera den via FTP eller ersätt den med ett alternativ.

Steg 6. Kontrollera det aktiva temat

Om inaktivering av tillägg inte hjälpte är nästa misstänkta temat. Felaktig kod i functions.php eller en konflikt med PHP-versionen kan på samma sätt orsaka ett fatalt fel och en 502.

Gå tillbaka till webbplatsens rotmapp → wp-content → themes. Hitta mappen för det aktiva temat och döp om den (lägg till exempel till .old i slutet):

WordPress kommer automatiskt att byta till standardtemat (Twenty Twenty-Four, Twenty Twenty-Five eller liknande). Uppdatera webbplatsen; om felet är borta är problemet temat. Kontakta temautvecklaren eller återställ en säkerhetskopia. Efter diagnostik, döp tillbaka mappen till sitt ursprungliga namn.

En detaljerad algoritm för att kontrollera teman och lokalisera motstridig kod beskrivs i guiden för felsökning av WordPress-temaproblem.

Steg 7. Återställ.htaccess-filen

En skadad .htaccess är en frekvent men mindre uppenbar orsak till en 502. Rewrite-regler som lagts till av ett cachingtillägg eller säkerhetstillägg kan komma i konflikt med varandra. Ett enda syntaxfel i denna fil, och servern returnerar en 502 på alla förfrågningar.

Anslut via FTP och lokalisera filen .htaccess i webbplatsens rotmapp. Ladda ner en säkerhetskopia till din dator, radera sedan filen från servern. Gå till WordPress adminpanel, navigera till Inställningar → Permalänkar och klicka på "Spara ändringar" (utan att ändra något). WordPress kommer att skapa en ny .htaccess med en ren uppsättning regler.

Om felet uppstod omedelbart efter installation av ett cachingtillägg (WP Rocket, W3 Total Cache, LiteSpeed Cache), kontrollera avsnittet med det tilläggets regler i .htaccess; det är vanligtvis omslutet av kommentarer som # BEGIN W3TC / # END W3TC. Radera det blocket, spara filen och uppdatera webbplatsen.

Steg 8. Kontakta ditt webbhotell

Om inget av de föregående stegen hjälpte ligger problemet troligtvis på serversidan. Kontakta ditt webbhotells tekniska support och ange domänen, tidpunkten då felet uppstod och vilka steg du redan har vidtagit. Ju mer detaljer du ger, desto snabbare hittar teknikerna orsaken.

Be dem kontrollera PHP- och webbserverns felloggar för perioden då 502-felet uppstod. Loggarna visar nästan alltid exakt vilket skript eller modul som orsakar felet. På billiga delade webbhotell kan orsaken helt enkelt vara resursbrist: en webbplats på servern förbrukar allt minne, och resten får en 502. I så fall är det vettigt att överväga att flytta till en VPS eller molnhosting med garanterade resurser.

Videoguide

Se en visuell genomgång av diagnostik och åtgärdande av 502-felet från första steget till det sista i denna video:

⁉️🤔 Vanliga frågor

Kan ett 502-fel lösa sig själv?

Ja, om orsaken är en kortvarig överbelastning av värdservern. Leverantörer övervakar belastning och startar automatiskt om problematiska processer inom en till fem minuter. Uppdatera sidan efter ett par minuter; i hälften av fallen försvinner felet utan någon åtgärd från din sida.

Hur skiljer jag en 502 från andra serverfel?

En 502 Bad Gateway är ett fel på proxyservernivå (Nginx/Apache), inte själva applikationen. En 500 Internal Server Error indikerar ett problem direkt i PHP-koden eller konfigurationen. En 503 Service Unavailable betyder att servern tillfälligt inte tar emot förfrågningar, vanligtvis under planerat underhåll. En 504 Gateway Timeout betyder att servern inte fick något svar från uppströmsservern inom den tilldelade tiden. För användaren handlar skillnaden om diagnostik: en 500 åtgärdas oftast genom att redigera kod, medan en 502 åtgärdas genom att återställa kommunikationen mellan servrar.

Behöver jag återställa webbplatsen från en säkerhetskopia för en 502?

En säkerhetskopia är en sista utväg, inte ett första steg. Innan du distribuerar en säkerhetskopia, följ steg 5, 6 och 7 i denna guide: inaktivera tillägg, kontrollera temat, återställ .htaccess. I de allra flesta fall löses en 502 utan att återställa en säkerhetskopia. Distribuera en säkerhetskopia endast om felet uppstod omedelbart efter uppdatering av WordPress, tillägg eller ett tema och det inte är möjligt att rulla tillbaka ändringar via FTP.

Kan jag förhindra 502-fel i framtiden?

Delvis ja. Använd kvalitetswebbhotell med tillräckligt PHP-minne (rekommenderat minimum är 256 MB). Ställ in övervakning av drifttid för din webbplats via UptimeRobot eller en liknande tjänst; du får veta om ett problem innan besökarna rapporterar det. Innan du installerar eller uppdaterar tillägg, gör en snabb säkerhetskopia. Och ha FTP-åtkomst till hands: när adminpanelen ligger nere är det det enda sättet att snabbt inaktivera problematisk kod.

Vad gör jag om inget hjälpte?

De åtta stegen ovan täcker nästan alla scenarier för en 502 Bad Gateway på WordPress. Om du har kontrollerat tillägg, tema, DNS och CDN, återställt .htaccess, och felet kvarstår, är problemet djupare, och du klarar dig inte utan webbhotellets tekniker.

Rätt sekvens sparar timmar: uteslut först lokala orsaker (cache, webbläsare, CDN), sedan serversidans orsaker (tillägg, tema, .htaccess), och eskalera först därefter till leverantören. Spara denna guide i dina bokmärken; en 502 har en vana att återkomma vid sämsta tänkbara tillfälle, och snabb åtkomst till checklistan kommer att spara dig mycket stress.