499 är inte en statuskod – det är en dagboksanteckning
HTTP-standarden har en fast, officiellt registrerad lista över statuskoder. 499 står inte på den listan. Den är en privat konvention från nginx, använd för att notera en händelse som annars inte har någon bra beteckning: klienten gav upp och stängde anslutningen innan servern hann skicka något svar över huvud taget.
Eftersom anslutningen redan är stängd när nginx skriver raden finns det ingenting att skicka ett svar till. 499 går aldrig över nätverket. Ingen webbläsare visar den. Ingen bot tar emot den. Den enda plats där den någonsin dyker upp är i din egen access-logg – en dagboksanteckning skriven för dig själv, inte ett besked till någon annan.
Samma händelse, andra namn: Apache och IIS
Använder du inte nginx betyder det inte att problemet försvinner – det betyder bara att det är gömt någon annanstans. Apache skriver inte en egen statuskod för en avbruten klient; du hittar det som en rad utan normal byte-storlek i access.log, eller som ett ”Connection reset by peer”-meddelande i error.log. IIS gör något liknande: W3C-loggen kan visa en win32-statuskod i stället för en vanlig HTTP-kod, där ett värde som 1236 betyder att anslutningen avbröts lokalt.
| Webbserver | Vad som loggas när klienten ger upp | Var du måste leta |
|---|---|---|
| nginx | Statuskod 499 (”Client Closed Request”) i access-loggen. | access.log – filtrera på status=499. |
| Apache | Ingen egen statuskod. Raden får ofta ett streck (”-”) i stället för byte-storlek, och error.log noterar ”Connection reset by peer” eller en avbruten anslutning. | error.log – sök efter ”reset by peer” eller avbrutna anslutningar, inte access.log. |
| IIS | W3C-loggen visar ofta sc-status 0 tillsammans med en win32-status som 1236 (anslutningen avbröts lokalt) i stället för en vanlig HTTP-kod. | IIS-loggens win32-statuskolumn – inte HTTP-statuskolumnen. |
Letar du bara efter 4xx- och 5xx-koder i den vanliga statuskolumnen går du rakt förbi den här händelsen på både Apache och IIS. Den finns där – bara under ett annat namn, i ett annat fält.
Crawlerns tålamod är inte detsamma som Googlebots
Googlebot har haft mer än två decennier på sig att bygga ett adaptivt system som tål tröghet från en domän och justerar sig över tid. Många AI-crawlers är byggda för ett helt annat användningsmönster. En crawler som hämtar innehåll i bakgrunden för träning kan i praktiken ha rymligare tid till förfogande än en crawler som måste leverera ett svar till en människa som väntar i en chatt just nu – som OAI-SearchBot, ChatGPT-User eller Claude-User. De sistnämnda är byggda för låg väntetid eftersom användaren upplever varje extra tiondels sekund direkt.
Konsekvensen: en sida som svarar tillräckligt bra för att en människa inte ska märka väntetiden kan ändå vara för trög för en crawler som måste leverera ett färdigt svar innan användaren tappar tålamodet. Gränsen crawlern arbetar mot är stramare än den du testar mot i din egen webbläsare.
Var fördröjningen faktiskt uppstår: tunga SSR-sidor och kalla cache-träffar
Tiden till första byte (TTFB) är själva flaskhalsen. Två mönster står för de flesta fallen:
Tung server-side rendering utan cache. Varje förfrågan bygger sidan på nytt från grunden – hämtar data, kör komponentträdet, serialiserar HTML – innan en enda byte kan skickas. Ju tyngre den kedjan är, desto längre väntar crawlern i mörkret.
Kalla cache-träffar och kalla funktionsstarter. Första förfrågan mot en sida (eller mot en serverless-funktion som inte körts nyligen) betalar en uppstartskostnad som de följande förfrågningarna slipper. Träffar en AI-crawler just den kallstarten – något som är statistiskt mer sannolikt för mindre besökta sidor, alltså ofta precis de sidor som behöver synlighet mest – är chansen att anslutningen brister högre än i ditt eget varma utvecklingstest.
Från 499 till inaktuellt AI-svar: hela kedjan
En enstaka 499 är ingen katastrof. Ett upprepat mönster är något annat. Ser en crawler ständigt att anslutningar till din domän brister innan ett svar kommer, är ett rimligt utfall över tid att den nedprioriterar eller mer sällan återvänder till just de sidorna – inte för att innehållet är dåligt, utan för att webbplatsen framstår som opålitlig att hämta från.
Lägre hämtfrekvens betyder att det som redan ligger lagrat om dig – rätt eller föråldrat – blir stående längre utan att uppdateras. En prisändring, en ny tjänst, ett rättat fel på sidan: ingenting av det når fram till nästa AI-svar innan crawlern faktiskt lyckas hämta sidan på nytt. Det är detta som gör 499 tyst på exakt samma sätt som resten av serien: inget felmeddelande visas för någon, och symptomet du till slut lägger märke till är ett AI-svar som verkar ligga ett steg efter verkligheten.
Så räknar du 499 mot AI-crawlers i loggen
Självkoll. Hämta access-loggen för de senaste 30 dagarna och gruppera raderna på statuskod 499 (eller Apache/IIS-ekvivalenten från tabellen ovan) kombinerat med user agent. Dela resultatet i två grupper: kända AI-user agents (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended) och allt annat.
Är andelen 499 tydligt högre för AI-botten än för vanlig mänsklig trafik på samma sidor är det inte innehållet som är problemet – det är TTFB:n. Lösningen ligger då i caching, snabbare rendering eller varma funktionsstarter, inte i att skriva om texten. Är andelen ungefär lika över all trafik är det troligen en generell prestandafråga som drabbar alla besökare lika, och bör prioriteras därefter.
Vanliga frågor
Är 499 en officiell HTTP-statuskod?
Hur hittar jag samma problem om jag inte använder nginx?
Hur länge väntar en AI-crawler innan den ger upp?
Hjälper det att bara höja ett timeout-värde i konfigurationen?
Var detta till hjälp?