De melding 429 too many requests verschijnt wanneer er in korte tijd meer verzoeken naar uw server gaan dan is toegestaan. De server zegt daarmee niet dat er iets stuk is, maar dat hij even niet meer meedoet. Voor uw bezoeker ziet dat er hetzelfde uit als een storing.

De reflex is te denken dat u wordt aangevallen. Dat komt voor, maar in ruim de helft van de gevallen die wij zien, komt het drukke verkeer van de site zelf of van een dienst die u zelf hebt gekoppeld. Hieronder hoe u dat onderscheidt.

Waar de limiet achter 429 too many requests vandaan komt

Er zijn drie plekken waar zo’n grens kan staan, en het maakt uit welke het is.

Bij uw hostingpartij. Op gedeelde hosting geldt vaak een maximum aantal verzoeken per minuut per account, om te voorkomen dat één klant de hele server bezet houdt. Deze limiet is meestal onzichtbaar totdat u eroverheen gaat.

Bij een beveiligingsplugin of een dienst als Cloudflare. Die tellen verzoeken per IP-adres en grijpen in bij een piek.

Bij een externe dienst die u aanroept. Uw site vraagt bijvoorbeeld voorraadgegevens op bij een leverancier, en die leverancier staat honderd verzoeken per uur toe. Gaat u eroverheen, dan krijgt uw site de 429, en die geeft hem soms door aan uw bezoeker.

Vijf oorzaken op volgorde van waarschijnlijkheid

  1. Uw eigen geplande taken die op hol zijn. WordPress voert achtergrondtaken uit bij elk bezoek. Staat er een taak vast, dan probeert hij het bij elk verzoek opnieuw, en dan telt uw site zichzelf voorbij de limiet. Dit is de meest voorkomende oorzaak en tegelijk de minst voor de hand liggende. Hoe u dat vaststelt, staat bij geplande taken die blijven hangen.
  2. Een plugin die te vaak iets ophaalt. Koppelingen met boekhouding, voorraad, verzendpartijen of een prijsvergelijker vragen soms elke minuut om gegevens, terwijl elk uur volstaat. Kijk in de instellingen naar de synchronisatiefrequentie.
  3. Een zoekmachine of scanner die te snel loopt. Legitieme robots houden zich meestal in, maar er zijn tientallen minder nette scanners die in een halfuur uw hele site doorlopen. Die kunt u in uw robots-bestand vertragen of via de firewall blokkeren.
  4. Geautomatiseerde inlogpogingen. Scripts die wachtwoorden proberen op de inlogpagina veroorzaken veel verzoeken op één adres. Dat de limiet dan afgaat, is eigenlijk goed nieuws: er wordt iets tegengehouden.
  5. Echte drukte. Een nieuwsbrief die uitgaat, een item op de radio, een actie die aanslaat. Dan is uw pakket te klein, en dat is een luxeprobleem met een dure oplossing.

Zo achterhaalt u de bron

U heeft twee dingen nodig: het tijdstip en het serverlogboek.

  1. Noteer het exacte tijdstip waarop u of uw bezoeker de melding kreeg. Zonder tijdstip is elk logboek onleesbaar.
  2. Vraag uw hostingpartij om het toegangslogboek rond dat moment, of open het zelf als u er in uw paneel bij kunt. U zoekt naar één IP-adres dat opvallend vaak terugkomt, of naar één adres op uw site dat honderden keren wordt opgevraagd.
  3. Kijk welk adres het is. Gaat het om wp-cron.php, dan zit het in uw geplande taken. Gaat het om wp-login.php, dan zijn het inlogpogingen. Gaat het om admin-ajax.php, dan is er een plugin die op de achtergrond blijft vragen. Gaat het om een gewone pagina, dan is er een robot bezig.
  4. Herhaalt het zich op vaste tijden? Elke dag om drie uur ‘s nachts wijst op een geplande synchronisatie, niet op een aanval.

Dat onderscheid is belangrijk, want de oplossingen liggen ver uit elkaar. Een aanval blokkeert u; uw eigen koppeling stelt u anders in.

Wat u eraan doet

Bij vastgelopen geplande taken: zet de ingebouwde afhandeling uit en laat de server de taken op vaste tijden aanroepen, bijvoorbeeld elke vijftien minuten. Dat haalt de druk er direct af en is bij vrijwel elke hostingpartij in te stellen.

Bij een te gretige koppeling: verlaag de frequentie in de plugininstellingen. Voorraad die één keer per uur wordt bijgewerkt in plaats van elke minuut, is voor de meeste webshops ruim voldoende.

Bij robots: voeg een vertraging toe in uw robots-bestand, of blokkeer de scanners die u toch niets opleveren. Blokkeer nooit blindelings alles wat op een robot lijkt; u gooit dan ook Google eruit.

Bij inlogpogingen: beperk het aantal pogingen en overweeg de inlogpagina te verplaatsen. De 429 is dan geen probleem maar een symptoom van een maatregel die werkt.

Bij echte drukte: zet caching goed aan, zodat pagina’s niet telkens opnieuw worden opgebouwd. Helpt dat niet, dan heeft u een zwaarder pakket nodig. Wat daarbij komt kijken, staat bij het opvangen van pieken op een webshop.

Wanneer u zich geen zorgen hoeft te maken

Een enkele 429 in uw logboek is normaal. Elke site krijgt dagelijks bezoek van scanners, en dat er af en toe iets wordt tegengehouden, is precies de bedoeling van die limieten.

Het wordt pas een probleem als echte bezoekers de melding zien. Dat merkt u aan telefoontjes, aan een daling in uw bezoekcijfers, of aan een bewakingsdienst die meldt dat de site kort onbereikbaar was. Ziet u alleen regels in een logboek en verder niets, dan hoeft u niets te doen.

Waar u wel op let: een 429 die urenlang aanhoudt, betekent dat uw site voor iedereen dicht zit. Dan telt elke minuut, want zoekmachines die tijdens zo’n periode langskomen, noteren uw site als onbereikbaar.

Komt de melding steeds terug en vindt u de bron niet, dan is meekijken in de logboeken sneller dan verder proberen. Dat is standaard onderdeel van het uitzoeken van terugkerende storingen op een site: eerst vaststellen wie er aanklopt, dan pas iets dichtzetten. Anders blokkeert u een symptoom en blijft de oorzaak draaien.