Ett 403 Forbidden-fel betyder att servern tog emot förfrågan, förstod den och vägrade att svara på den. Till skillnad från en 401 hjälper det inte nödvändigtvis att logga in: servern säger att just den här klienten, från den här adressen, med de här behörigheterna, inte får komma åt resursen. Orsaken är nästan alltid en regel, inte en krasch: filbehörigheter, en saknad indexfil, en deny-regel i serverkonfigurationen, en brandvägg eller ett bot-skydd, en blockering av IP eller land, eller ett konto utan rätt roll. Sajtägare hittar regeln i felloggen eller i brandväggens händelselogg; besökare kan i stort sett bara ändra det de skickar.
403 vs 401 vs 404
KodVad servern sägerVad som hjälper401 UnauthorizedVem är du? Skicka inloggningsuppgifter.Att logga in, eller en giltig API-nyckel eller token403 ForbiddenJag vet vad du vill ha, och du får inte det.Andra behörigheter, en annan adress eller en annan förfrågan404 Not FoundDet finns ingenting här.Rätt adress
Servrar följer inte alltid läroboken. Vissa svarar 404 i stället för 403 för att dölja att en privat sida finns, och vissa svarar 403 för filer som saknas: en privat lagringsbucket kan till exempel svara 403 för ett objekt som inte finns när klienten inte får lista bucketens innehåll. Referensen för HTTP-statuskoder har resten.
Vanliga orsaker
Behörigheter på filer och mappar. Webbserverns användare kan inte läsa filen eller öppna mappen, ofta efter en uppladdning eller en deploy som kopierade filerna som en annan användare.
Ingen indexfil. En förfrågan efter en mapp utan index.html eller index.php, på en server där kataloglistning är avstängd, svarar 403. En misslyckad deploy som lämnade mappen tom gör samma sak.
Deny-regler. En deny all i nginx, en Require all denied i Apache eller en regel i .htaccess som blockerar en sökväg, en filtyp eller en user agent.
En brandvägg eller ett bot-skydd. En WAF, ett CDN:s bot-skydd eller ett säkerhetsplugin bedömer att förfrågan ser automatiserad eller skadlig ut och blockerar den, ibland med en utmaningssida.
Blockering av IP och land. Besökarens adress, nätverk eller land står på en blockeringslista, eller så är sidan begränsad till ett kontorsnätverk eller en VPN.
Saknade rättigheter. Besökaren är inloggad, men rollen ger inte tillgång till sidan, eller så saknar en API-nyckel behörighet för endpointen.
Utgångna eller felaktiga signerade länkar. Nedladdningslänkar med en signatur eller ett utgångsdatum svarar 403 när de har gått ut.
Skydd mot hotlinking. Bilder eller filer som begärs från en annan sajt, eller utan förväntad Referer, nekas.
Vad besökare kan prova
Kontrollera adressen. En länk som slutar i en mapp i stället för en sida, eller en felskriven sökväg, kan träffa en mapp som servern inte visar.
Logga in, eller logga in med rätt konto. Vissa sajter visar 403 för besökare som inte är inloggade, eller för konton utan åtkomst.
Rensa sajtens cookies och ladda om. En gammal session eller en inaktuell utmaningscookie kan få en brandvägg att fortsätta neka dig.
Byt nätverk. Stäng av en VPN eller proxy, eller slå på en, eller prova mobildata. Delade adresser och adresser i datacenter blockeras oftare än hemanslutningar.
Stäng av tillägg för sajten. Vissa integritetstillägg ändrar headers på sätt som får en brandvägg att reagera.
Meddela sajtägaren, med tidpunkten och eventuellt referensnummer som felsidan visar. Med det numret kan de hitta exakt vilken regel det gäller.
Så hittar och åtgärdar sajtägare felet
Ta först reda på vem som svarade. Titta på felsidan och svarets headers: ett CDN eller en brandvägg brukar ge sig till känna, med en sida i egen stil, en Server-header eller ett request-ID. Om det är din webbserver anger felloggen orsaken. Om det är CDN:et eller WAF:en gör händelseloggen det.
Behörigheter och indexfiler
På Linux-servrar behöver mappar oftast 755 och filer 644, ägda av den användare som webbservern eller PHP körs som. Kontrollera innan du ändrar något, och åtgärda aldrig en 403 med 777, som låter alla användare på servern skriva till din sajt:
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx loggar ”directory index of … is forbidden” när en mapp saknar indexfil; Apache loggar att den inte hittar något index och att kataloglistning är avstängd. Kontrollera att deployen lade filerna där serverns document root pekar.
Serverregler
nginx loggar ”access forbidden by rule” för en deny, och Apache loggar ”client denied by server configuration” för en Require-regel. Sök i konfigurationen och i varje .htaccess längs sökvägen efter regeln som matchar. I WordPress skrivs kärndelen av .htaccess om när du sparar inställningarna för permalänkar, och säkerhetsplugins lägger till egna block där och i sina inställningar.
Brandväggar, CDN:er och säkerhetsplugins
Leta upp den blockerade förfrågan i händelseloggen via tid, adress eller request-ID, se vilken regel som matchade och avgör om regeln är fel eller om förfrågan verkligen var oönskad. Lägg till undantag för specifika adresser eller sökvägar i stället för att stänga av en regel för hela sajten. Testa efter en ändring i brandväggen från ett nätverk utanför kontoret, eftersom din egen adress kan stå på en tillåtelselista.
Därför får en monitor 403 när din webbläsare inte gör det
Ett vanligt fall: sajten fungerar för dig, men din upptidsövervakning rapporterar 403. Oftast är inget trasigt. Något framför sajten behandlar kontrollen som en bot, eftersom den är en:
Bot-skydd. CDN:er och WAF:er utmanar klienter som inte kör JavaScript eller ser automatiserade ut. En webbläsare klarar utmaningen; en monitor kan inte det, så den får en 403 eller en utmaningssida.
Adresser i datacenter. Monitorer kontrollerar från servrar, och vissa regler blockerar hostingnätverk som standard.
Blockering av länder. En sajt som bara tillåter sitt hemland blockerar en monitor som kontrollerar från utlandet.
Regler för antal förfrågningar. Vissa brandväggar svarar 403 i stället för 429 när en klient gör för många förfrågningar.
Lösningen är att tillåta monitorn, helst via dess IP-adresser, eftersom vem som helst kan kopiera en user agent. Lös det inte genom att godta 403 som ”uppe” för hela sajten: då går en verklig blockering av dina besökare obemärkt förbi. Måste en sida verkligen ligga bakom skyddet kan du övervaka en health check-endpoint utanför det. Guiden om att minska falsklarm tar upp andra orsaker till larm som inte är avbrott.
403-fel och Uptimecheck
En HTTP(S)-monitor i Uptimechecks upptidsövervakning räknar som standard statusar från 200 till 399 som uppe, så en 403 räknas som nere. En andra kontroll bekräftar det innan du får ett larm, och incidenten förklarar vad som svarade: när 403:an eller en utmaningssida kommer från Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence eller AWS WAF namnger den tjänsten och vad du ska tillåta där. Kontrollerna av webbplatser görs från Stockholm med en user agent som innehåller ”Uptimecheck”. Så släpper du igenom Uptimecheck i en brandvägg listar våra adresser med färdiga regler för Cloudflare, säkerhetsplugins för WordPress och nginx, och varför en monitor kan vara nere när sajten fungerar tar upp övriga orsaker.
Vill du veta om en sajt svarar över huvud taget? Den kostnadsfria Is it down?-kontrollen räknar alla svar under 500, även en 403, som uppe: servern svarade, även om den nekade.
Skilj en blockerad kontroll från ett verkligt avbrott. Prova Uptimecheck gratis i 14 dagar, inget kreditkort krävs.