Lagt ned af AI

En pludselig, stor stigning i trafik lagde et stort site ned. Jeg spurgte ChatGPT om årsagen, og den udpegede sig selv som skyldig!

I midten af november 2025 blev mit ganske velbesøgte fiske-site pludselig meget langsomt og plaget af en pludselig stigning i indkommende trafik. Antallet af forespørgsler steg med en faktor 10 natten over, og i et par uger fortsatte trafikken på det niveau. Det lagde alvorligt beslag på serverens ressourcer, og var årsag til alle mulige elendigheder.
 
Der var konstant høj CPU-belastning, serveren blev fyldt op med cache-filer, der var virkelig lange svartider, databasen var nær ved at kvæles plus mange andre irriterende effekter.
 
Målinger med stigning i trafik og belastning
 
Jeg spurgte Linode, som driver serveren, om de kunne hjælpe. De så den øgede trafik, men ikke noget mistænkeligt såsom et DDOS-angreb eller lignende. Udover det kunne de ikke hjælpe eftersom alt var indenfor rammen af det forventelige, og altså mit eget problem. Ikke urimeligt. De leverer jo bare serverkraft. Resten har jeg selv sat op.
 
Trafikken steg pludseligt
 
Så jeg vendte mig mod ChatGPT og spurgte hvordan jeg kunne diagnosticere problemet.
Den kunstige intelligens ledte mig igennem en række ret komplekse Linux-kommandoer, analyserede hver enkelt, førte mig til nye, og kunne til sidst drage en konklusion.
 
Og den konklusion var?
Bot-trafik, hovedsagligt fra ChatGPT!
 
Bot-trafik, hovedsagligt fra ChatGPT!
 
Sitet blev besøgt af de bots, der indsamler information til LLM’erne (Large Language Models), der driver forskellige AI’er, herunder ChatGPT’s egen, Anthropics (Claude), Metas (Facebook) og flere andre.
Disse bots hentede sider på sitet med en hastighed på dusinvis pr. sekund, hvilket er alt for ofte. God botadfærd er naturligvis at gå langsomt frem og ikke lægge sites ned!
 
Løsningen var at blokere dem, før de kunne få adgang til noget indhold, og det var ganske effektivt.
Jeg havde allerede blokeret dem i robots.txt‑filen på sitet, men dette er kun en anmodning om at holde sig ude – ikke en teknisk blokering. Og det var ret tydeligt at de var ligeglade med anmodningen.
Nu er de blokeret fra at komme ind, og de store AI’er træner ikke længere på sidens indhold.
 
AI er virkelig et tveægget sværd, og denne hændelse viser tydeligt problemet: På den ene side kan de løse problemer, som nogle af os mennesker kan have svært ved at håndtere.
Jeg kunne ikke have gjort det her uden en Linux‑ekspert ved min side, og ChatGPT udgjorde det for den ekspert.
På den anden side gør de netop det ved at udnytte al den viden, der allerede findes derude, og det betyder åbenlyst nogle gange overudnyttelse.
 
Men ChatGPT løste mine problemer ved at udelukke sig selv, og sitet er nu lige så hurtigt som før – og sandsynligvis endnu hurtigere – og jeg er glad.
 
Pagespeed efter reparationen
 
 

Vejen dertil <

Og til jer (få, håber jeg), der står overfor – og er nødt til at håndtere – lignende problemer, bad jeg ChatGPT om at lave et resumé af det, den fik mig til at gøre, og her er det:

  1. Identificerede unormal trafik
    • Brugte ss -tnp til at inspicere aktuelle TCP-forbindelser.
    • Fandt mange CLOSE-WAIT-sockets med lange køer, hvilket antydede, at forbindelser ikke blev lukket korrekt, og at workers blev fastholdt for længe.
  2. Analyserede trafikmængde og mønster
    • Gennemså Apache access-logs for at beregne antal forespørgsler pr. time.
    • Fandt spidsbelastninger på omkring ~100.000 forespørgsler i timen, hvilket bekræftede en betydelig trafikstigning.
  3. Fandt bot-domineret trafik som den primære årsag
    • Udtrak de mest forekommende User-Agent-strenge fra Apache-logs.
    • Fandt meget høje antal fra crawlers såsom:
      • GPTBot (OpenAI) ~866k forespørgsler
      • meta-externalagent (Meta crawler) ~103k forespørgsler
      • Baiduspider-familien ~77k forespørgsler
      • Claude-SearchBot (Anthropic), Applebot, DataForSeo, BLEXBot osv.
    • Konkluderede, at stigningen primært var forårsaget af AI-/søge-/SEO-bots, ikke almindelige besøgende.
  4. Implementerede blokering af bots
    • Opdaterede robots.txt for at udelukke kendte AI-, SEO- og aggressive internationale crawlers.
    • Tilføjede Apache .htaccess-regler med mod_rewrite for at returnere 403 Forbidden til:
      • GPTBot, Claude-SearchBot, meta-externalagent
      • Baiduspider, Bytespider, SemrushBot, DataForSeoBot, BLEXBot og andre.
    • Så en øjeblikkelig reduktion i bot-trafik.
  5. Diagnosticerede Apache worker-mætning
    • Tjekkede /var/log/apache2/error.log for MPM-fejl.
    • Fandt gentagne beskeder:
      • server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
    • Bekræftede, at Apaches mpm_prefork-worker-pool ramte sin grænse og forårsagede lange svartider.
  6. Målte Apache-processers hukommelsesforbrug og vurderede tilgængelig RAM
    • Brugte ps -ylC apache2 --sort:rss til at inspicere Apaches hukommelsesforbrug.
    • Fandt, at hver worker brugte cirka 16–18 MB RSS.
    • Verificerede med free -m at serveren havde 16 GB RAM med masser af ledig hukommelse.
  7. Tunede Apache prefork MPM-indstillinger
    • Redigerede mpm_prefork.conf for bedre at matche tilgængelige ressourcer.
    • Justerede nøgleværdier til:
      • MaxRequestWorkers 250 (op fra 150, udnytter 16 GB RAM sikkert)
      • MaxConnectionsPerChild 2000 for periodisk at genstarte workers og undgå overforbrug af hukommelse
    • Mål: tillade flere samtidige forespørgsler uden at ramme worker-loftet eller forårsage swap-thrashing.
  8. Optimerede forbindelses- og timeout-adfærd
    • Tilføjede/optimerede globale forbindelsesindstillinger i apache2.conf:
      • KeepAlive On
      • MaxKeepAliveRequests 100
      • KeepAliveTimeout 2 (reduceret fra 5 for hurtigere at frigive workers)
      • Timeout 60 (reduceret fra den meget højere standardværdi)
    • Aktiverede og konfigurerede mod_reqtimeout for at beskytte mod slowloris-lignende angreb og meget langsomme klienter:
      • RequestReadTimeout header=10-20,MinRate=500 body=10,MinRate=500
    • Mål: sikre, at workers ikke fastholdes unødigt længe af inaktive eller fejlende klienter.
  9. Verificerede overordnet ressourcehelbred og stabilitet
    • Bekræftede, at hukommelsesforbruget forblev sundt og stabilt med:
      • Tilstrækkelig tilgængelig hukommelse (~13+ GB)
      • Minimal og stabil swap-brug (~253 MB)
    • Konkluderede, at Apache – med forhøjede worker-grænser og skrappere timeouts – nu kan håndtere legitim trafik mere elegant.