HTTP-fel 509: förstå, diagnostisera och åtgärda

Procédure

Vad är fel 509?

HTTP-felkod 509 betyder att webbplatsen överskrider de resursgränser som ingår i dess hostingplan. Servern vägrar då tillfälligt att behandla en del av eller alla förfrågningar som är kopplade till hostingplanen.

Två gränser kan utlösa detta fel:

• Samtidiga anslutningar: antal öppna HTTP-anslutningar vid samma ögonblick
• Antal förfrågningar: antal förfrågningar under en tidsperiod

En begränsning, inte en blockering

Fel 509 är inte en blockering och kan därför inte hävas manuellt, varken av kunden eller av supporten. Det försvinner automatiskt så snart webbplatsens förbrukning går tillbaka under gränserna i dess plan.

Om felet återkommer regelbundet finns orsaken till överförbrukningen fortfarande kvar: den måste identifieras och åtgärdas (se följande avsnitt).

Vanliga situationer

I praktiken uppträder fel 509 oftast i något av följande fall:

• Legitim trafik som är för hög för planen : webbplatsen får fler besökare än vad dess plan kan hantera.
• SEO- och AI-robotar som är för aktiva : crawlers utforskar webbplatsen intensivt, ibland tusentals sidor per timme.
• DDoS-attack : ett stort antal skadliga förfrågningar försöker överbelasta webbplatsen.
• HTTP-resurs som är dåligt optimerad : en URL får mycket trafik (reklamkampanj, organisk viral spridning ...) men kräver stora resurser för att behandlas (ingen sidcache, dåligt optimerad SQL-fråga ...)
• Bug som genererar en loop av förfrågningar : till exempel ett AJAX-skript som anropar samma URL i en loop.
• Infekterad eller kapad webbplats : hackare använder webbplatsen för att hosta landningssidor för phishing eller bedrägliga kampanjer som lockar mycket trafik.

Diagnostisera problemets ursprung

Webbplatsens åtkomstlogg är den viktigaste källan för att förstå vilka förfrågningar som orsakar felet.

1. Hämta, via ditt cPanel-gränssnitt, åtkomstloggen som hör till den berörda webbplatsen.
2. Identifiera de mest anropade URL:erna: en och samma resurs som anropas i en loop tyder ofta på en bug eller en målsatt sida.
3. Identifiera de IP-adresser och user-agents som förekommer oftast: namn som Googlebot, Bingbot, GPTBot, ClaudeBot eller AhrefsBot signalerar robotar.
4. Jämför med ett statistikverktyg i webbläsaren (Google Analytics eller motsvarande).

Jämförelsen i steg 4 är avgörande. Ett verktyg som Google Analytics fungerar med JavaScript: det räknar bara riktiga besökare vars webbläsare kör skriptet. Om åtkomstloggen visar betydligt fler förfrågningar än besöken som mäts av Analytics, beror avvikelsen mycket sannolikt på robotar, en attack eller automatiserade anrop.

Okända eller misstänkta URL:er i loggen (sidor du inte har skapat, sökvägar till ovanliga PHP-filer) bör få dig att misstänka intrång.

De två möjliga lösningarna

För att varaktigt stoppa fel 509 finns två alternativ:

• Migrera till en VPS : lämpligt när trafiken är legitim och webbplatsen helt enkelt har överskridit kapaciteten hos ett delat webbhotell. En VPS erbjuder dedikerade resurser, utan dessa gränser för anslutningar och förfrågningar.
• Minska förbrukningen : lämpligt när överförbrukningen beror på robotar, attacker, en bug eller dåligt utnyttjad cache. Verktygen som beskrivs nedan gör det möjligt att minska antalet HTTP-förfrågningar och anslutningar.

Innan du överväger en migrering rekommenderas det att kontrollera i loggarna att trafiken verkligen är legitim: att migrera en kapad webbplats eller en webbplats som bombas av robotar löser inte orsaken.

Verktyg för att minska förbrukningen

Begränsa genomsökning med robots.txt

Filen robots.txt, som placeras i webbplatsens rotkatalog, anger för SEO- och AI-robotar vilka sidor de får genomsöka. Du kan förbjuda hela kataloger eller vissa AI-robotar som du inte behöver. Du kan också ange en minsta väntetid mellan genomsökningen av två sidor.

Exempel:

User-agent: GPTBot
Disallow: /

User-agent: Claudebot
Crawl-Delay: 60

User-agent: *
Disallow: /panier/
Disallow: /*?filtre=

Detta är särskilt användbart när din webbplats överbelastas av genomsökningsrobotar. I och med framväxten av AI-träningsrobotar utför vissa robotar nämligen maximal genomsökning, ibland i onödan. Till exempel är AI-robotar särskilt kända för att prova alla möjliga kombinationer av filter och sortering på produktsidor.

Utöver den bandbredd som slösas bort på denna typ av crawling kan SEO- och AI-robotar anse att din webbplats har alldeles för många sidor. De kan då avbryta genomsökningen innan de har hunnit gå igenom hela webbplatsen, vilket skadar din synlighet i sökresultaten. Det ligger i ditt intresse att begränsa de sidor som genomsöks så att robotarna kan fokusera på de sidor som ger mest värde för SEO- och GEO-rankning.

Respektfulla robotar följer dessa regler; skadliga robotar ignorerar dem, vilket gör följande verktyg användbara.

LWS Protect

LWS Protect samlar tre skydd som är användbara mot fel 509:

• Rate limiting för robotar : begränsar frekvensen av SEO- och AI-robotars förfrågningar utan att blockera dem helt.
• Aggressiv Anti-DDoS : utsätter webbläsare för en JavaScript-utmaning. Riktiga besökare släpps igenom, automatiserade skript stoppas.
• Blockering av IP-adresser med dåligt rykte : filtrerar adresser som är kända för spam, attacker eller scraping.

Se LWS Protect-dokumentationen för mer information.

Fastest Cache

Cachingsystemet Fastest Cache gör det möjligt att servera en redan genererad version av sidorna. Servern kör inte längre PHP / Node.js / Python eller databasfrågor för varje besök, vilket minskar resursförbrukningen och laddningstiden. Det är särskilt viktigt för en sida som riktas av en reklamkampanj.

Om den berörda sidan är dynamisk (innehåller delar som varierar beroende på inloggad besökare, anslutet land ...), kan du sätta upp partiell cache: du laddar först sidans skelett och det statiska innehållet som är identiskt för alla besökare, och därefter laddar du det dynamiska innehållet via en asynkron JavaScript-förfrågan. På så sätt kan du cacha det statiska innehållet.

För mer information om hur du använder Fastest Cache, se produktdokumentationen.

Cloudflares läge Under Attack

Om webbplatsen går via Cloudflare kräver läget « Under Attack » att besökare verifierar sig innan de får åtkomst till webbplatsen. Det är användbart under en DDoS-attack, men bör inaktiveras när attacken är över eftersom det saktar ned besökarnas första åtkomst.