429 Too Many Requests — hvorfor serveren siger stop

Kort svar: 429 Too Many Requests betyder, at en besøgende, en robot eller dit eget site sendte flere forespørgsler, end en grænse tillader inden for et tidsrum. Find først ud af, hvilket lag der svarer 429 – Cloudflare, serverens firewall, et WordPress-plugin eller en ekstern tjeneste – og hvem der rammer grænsen. Bloker robotter, ret integrationer, der spørger for ofte, og justér grænsen, hvis den rammer rigtige besøgende eller Googlebot.

Fagligt gennemgået: 2. oktober 2026

HTTP 429 Too Many Requests betyder, at nogen – en besøgende, en robot eller din egen side – sendte flere forespørgsler, end serveren accepterer inden for et tidsrum. Serveren afviser bevidst for at beskytte sig selv.

Det er altså ikke en fejl i klassisk forstand. Det er en grænse, der virker efter hensigten. Spørgsmålet er, om den rammer den rigtige.

Før du ændrer noget: Slå ikke grænsen helt fra for at få fejlen væk. Så forsvinder beskyttelsen mod brute force og scrapere samtidig. Notér først tidspunkt, URL og din egen IP-adresse, når fejlen opstår, så du kan finde de præcise linjer i loggen bagefter.

Hvem udløser den?

1. En bot eller en scraper, der henter mange sider hurtigt.
2. Et login-forsøg i serie – typisk et brute force-forsøg mod wp-login.php eller xmlrpc.php.
3. Din egen side, hvis et plugin kalder sit eget REST API i løkke, eller en app spørger for ofte.
4. En ekstern tjeneste, du bruger, som har sin egen grænse – det er tjenesten, ikke dig, der siger 429.
5. Dig selv, hvis du klikker hurtigt rundt i administrationen med et aggressivt sikkerhedsplugin slået til.

Symptom og sandsynligt lag

Symptom	Sandsynligt lag	Første kontrol
Fejlsiden har Cloudflares design og et Ray ID	Cloudflare rate limiting eller WAF	Security → Events i Cloudflare
Neutral serverside uden WordPress-design	Serverens firewall eller webserverens grænser	Adgangsloggen og hostingens firewall
Fejlen står i et WordPress-design eller som JSON	Sikkerhedsplugin eller WordPress-kode	Pluginets log eller blokeringsliste
Kun én funktion fejler, fx lager-sync eller fragt	Ekstern tjenestes API-grænse	Pluginets eller integrationens log
Kun dig i wp-admin	For stram grænse i sikkerhedsplugin	Pluginets indstillinger for rate limiting
Crawlfejl i Search Console	Grænsen rammer Googlebot	Crawlstatistik i Search Console

1. Find ud af, hvilket lag der svarer 429

Der kan sidde en grænse flere steder på samme site: i Cloudflare eller en anden proxy, i serverens firewall, i et sikkerhedsplugin og i de eksterne tjenester, sitet taler med. Headerne i svaret afslører som regel, hvem der svarede:

curl -sI https://dinside.dk/wp-login.php | grep -iE "^(HTTP|server|retry-after|cf-ray|x-)"

Står der server: cloudflare og en cf-ray, kom afvisningen fra Cloudflare, og forespørgslen nåede aldrig din server. Mangler de, er det serveren eller WordPress. Et sikkerhedsplugin sætter ofte sin egen header eller viser sin egen fejlside, så du kan genkende det.

2. Læs adgangsloggen – sådan ser en 429 ud

I adgangsloggen står hver forespørgsel med IP-adresse, tidspunkt, URL, statuskode og brugeragent. Filtrér på 429, og kig på tre ting: hvor mange forskellige IP-adresser der er, hvilke URL’er der rammes, og hvor tæt forespørgslerne ligger.

# De IP-adresser, der oftest får 429
grep '" 429 ' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# De URL'er, der oftest rammes
grep '" 429 ' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Mønstrene er ofte tydelige. Tyve forespørgsler i sekundet mod wp-login.php fra én adresse er en robot, der forsøger at gætte adgangskoder. Hundrede forespørgsler i minuttet mod /wp-json/wc/store/ fra din egen servers IP er et plugin eller en app, der spørger for ofte. Mange 429’ere spredt jævnt over alle sider fra én kendt crawler er en SEO-robot, der henter for aggressivt. Og mange IP-adresser, der rammer den samme URL, ligner et koordineret forsøg.

Svaret på en 429 indeholder ofte en Retry-After-header, der fortæller, hvor mange sekunder afsenderen skal vente. Rigtige tjenester respekterer den. Robotter, der ignorerer den og bare bliver ved, kan du roligt blokere helt – de har allerede vist, at de ikke opfører sig ordentligt. Se også loglæsning for ikke-teknikere.

3. Er det et angreb: lad beskyttelsen arbejde

Så virker beskyttelsen. Overvej at lægge et lag foran, så trafikken stoppes, før den når din server – se opsætning af Cloudflare mod DDoS. Et brute force-angreb på login løses bedst med flere lag: stærke adgangskoder, totrinslogin og en grænse på selve login-adressen.

Bruger ingen på sitet XML-RPC (fx Jetpack eller den gamle WordPress-app), kan xmlrpc.php blokeres helt. Det fjerner en adresse, der ofte bruges til at gætte mange adgangskoder i én forespørgsel. Læs mere om at beskytte WordPress-login mod brute force.

4. Er det dit eget plugin eller en integration

Kommer forespørgslerne fra din egen servers IP eller fra et lager-, regnskabs- eller fragtsystem, er det en integration, der spørger for ofte. Find den ved at sammenholde URL’erne i loggen med dine plugins, eller slå plugins fra ét ad gangen på staging, mens du holder øje med loggen. Plugins, der synkroniserer lager, priser eller ordrer, er de hyppigste.

Løsningen er sjældent at hæve grænsen. Det er at få integrationen til at hente i batches, bruge webhooks i stedet for at spørge hvert minut, eller køre synkroniseringen via et planlagt job med pauser. WooCommerce’ Store API har desuden en valgfri rate limiting, der som standard er slået fra; er den slået til, skal dine egne frontend-kald kunne holde sig under den.

5. Er det en ekstern tjeneste

Får dit site 429 fra en fragt-, betalings- eller regnskabstjeneste, er det deres grænse. Læs deres dokumentation for grænsen, respektér Retry-After, og byg pauser og genforsøg med stigende ventetid ind i kaldene. Du kan ikke hæve en andens grænse, men du kan ofte få et højere loft ved at kontakte tjenesten eller skifte til et abonnement med flere kald.

Ligger mange sites bag den samme udgående IP-adresse, kan en tjeneste, der begrænser pr. IP, også give 429 under fx plugin-opdateringer. Det løser sig typisk af sig selv efter ventetiden – prøv igen senere i stedet for at klikke gentagne gange.

6. Hvornår grænsen rammer de forkerte

En grænse pr. IP-adresse er skæv i tre situationer, som er mere almindelige, end man tror. Kontorer og skoler deler ofte én offentlig IP-adresse, så tredive medarbejdere, der åbner webshoppen samtidig, ligner én meget ivrig besøgende. Mobilnet samler mange brugere bag få adresser (CGNAT), så en grænse, der er sat til en enkelt person, kan ramme mange på én gang. Og dine egne integrationer – lagersystem, regnskab, fragt – kalder alle fra samme server og kan tilsammen ramme loftet, selv om hver af dem er høflig.

Løsningen er ikke at fjerne grænsen, men at gøre den klogere: højere loft for kendte IP-adresser (dit kontor, dine integrationer), lavere loft for login og REST API end for almindelige sider, og en udfordring (challenge) i stedet for en blank afvisning, så rigtige mennesker kan komme videre. En webshop med rigtig trafik kan desuden ramme en grænse, der er sat til en lille hjemmeside – få den justeret frem for at leve med afviste kunder.

Skal du selv sætte grænser, så start konservativt og mål. Et udgangspunkt kan være omkring 60 forespørgsler i minuttet pr. IP-adresse til almindelige sider, omkring 10 login-forsøg i minuttet og noget midt imellem til REST API’et. Kig i loggen efter en uge, og justér efter, hvem der faktisk ramte loftet. Tallene er et startpunkt, ikke en norm: et site med tung JavaScript og mange API-kald pr. sidevisning kan have brug for mere.

7. Sørg for, at Googlebot aldrig rammer grænsen

Får Googlebot en 429, sænker Google sin crawlhastighed og prøver igen senere – fornuftigt, men varer det i dagevis, kan sider begynde at falde ud af indekset. Det ser du i Search Console under Indstillinger → Crawlstatistik, hvor svarene er fordelt på statuskoder.

Undtag de rigtige søgemaskinerobotter fra grænsen, men stol ikke på brugeragenten alene – den kan forfalskes. Google og Bing offentliggør deres IP-serier, og du kan bekræfte en Googlebot med et omvendt DNS-opslag, der skal ende på googlebot.com eller google.com:

host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
# skal pege tilbage på samme IP-adresse

Cloudflare har en indbygget kategori for verificerede robotter, og mange serverfirewalls kan undtage dem. Tjek din egen opsætning i stedet for at gå ud fra, at det er på plads.

Verificér, at problemet er løst

• Gentag den handling, der gav 429, fra samme netværk.
• Filtrér adgangsloggen på 429 over det næste døgn, og se, om de rigtige IP-adresser er væk.
• Kontrollér integrationernes log for fejlede kald.
• Følg Crawlstatistik i Search Console i et par uger efter ændringen.
• Bekræft, at login stadig blokerer gentagne forkerte forsøg – grænsen skal virke, bare ikke mod de forkerte.

Hvornår skal hosting hjælpe?

Kommer 429 fra serverens firewall, og kan du ikke selv se eller justere reglerne, skal hostingens support hjælpe. Send tidspunkt, URL, din IP-adresse og et udsnit af adgangsloggen med. Hos Hostious kan du få fat i dansk support døgnet rundt.

Læs også

• Hub: WordPress fejl og fejlfinding
• Rigtige besøgende møder captcha eller challenge
• Bot Fight Mode blokerer betalings-callbacks og overvågning
• 403 Forbidden i WordPress
• WooCommerce hosting hos Hostious – LiteSpeed, NVMe og dansk support 24/7

Ofte stillede spørgsmål om 429 Too Many Requests

Skader det min SEO, hvis Googlebot får 429?

Enkelte 429-svar gør ingen skade, men får Googlebot dem over flere dage, sænker Google crawlhastigheden, og sider kan falde ud af indekset. Undtag verificerede søgemaskinerobotter fra grænsen, og hold øje med Crawlstatistik i Search Console.

Kan jeg bare slå grænsen fra?

Du kan, men så er der ingen beskyttelse mod brute force og scrapere. Hæv den hellere til et niveau, der passer til trafikken, og giv kendte IP-adresser et højere loft.

Hvad er en fornuftig grænse pr. IP-adresse?

Et udgangspunkt er omkring 60 sidevisninger i minuttet til almindelige sider, omkring 10 login-forsøg i minuttet og noget midt imellem til REST API’et. Husk, at kontorer og mobilnet deler IP-adresser, så sæt hellere en udfordring end en blank afvisning, og justér efter loggen.

Hvordan ser jeg, om det er Cloudflare eller min server, der svarer 429?

Se på headerne i svaret. Står der server: cloudflare og et cf-ray, kom afvisningen fra Cloudflare, og du finder årsagen under Security → Events. Ellers kommer den fra serverens firewall eller et WordPress-plugin.