Clientfouten

Fouten met een statuscode die met een 4 begint, betekenen dat je site de request wel heeft ontvangen, maar hem niet wilde of kon afhandelen: de pagina bestaat niet, de bezoeker mag hem niet zien, de request was te groot of er kwamen te veel requests tegelijk binnen. Anders dan bij serverfouten is je site dan niet offline, en meestal wijzen deze fouten naar een instelling of bestand dat je zelf kunt aanpassen. De uptimemonitoring van Kinsta stuurt voor geen van de fouten op deze pagina een melding. Je krijgt alleen een melding bij 500-, 502- en 504-serverfouten en bij redirectloops.

401 Unauthorized

Een 401 Unauthorized fout betekent dat de pagina een gebruikersnaam en wachtwoord vereist, en dat de bezoeker die niet of verkeerd heeft ingevuld.

• Wachtwoordbeveiliging: Staat htpasswd-beveiliging aan op je site of in je testomgeving, dan krijgen bezoekers een inlogvenster te zien voordat de site laadt. Vul de gebruikersnaam en het wachtwoord in die in MyKinsta zijn ingesteld, of zet de htpasswd-beveiliging uit als de site openbaar moet zijn.
• API-requests: Tools en integraties die via de WordPress REST API verbinding maken met je site, krijgen een 401 als hun inloggegevens, zoals een applicatiewachtwoord, ontbreken, onjuist zijn of zijn ingetrokken. Controleer de inloggegevens in de instellingen van de tool.

403 Forbidden

Een 403 Forbidden fout betekent dat de request bewust is geblokkeerd. Meerdere lagen kunnen een request aan je site blokkeren, en elke laag toont een andere pagina. Aan de pagina die je ziet, herken je dus het snelst de oorzaak.

Achterhalen wat de request heeft geblokkeerd

Open de pagina met de fout en vergelijk die met de lijst hieronder. Heeft een bezoeker de fout gemeld, vraag dan om een screenshot.

Volg daarna de stappen hieronder voor dat type blokkade.

Geblokkeerd door een toegangsregel in MyKinsta

Toont de pagina alleen een kop “403 Forbidden”, dan is de request door de toegangsregels van je site geblokkeerd voordat hij je site bereikte. Hij staat dus niet in de logs van je site.

1. Ga in MyKinsta naar Sites > sitenaam > Botbescherming en open het rapport Top verkeer. Selecteer het type verkeer dat is geblokkeerd om de betrokken IP-adressen, paden, user agents en landen te zien.
2. Controleer je Beschermingsniveau. Strengere niveaus blokkeren geautomatiseerd verkeer, en daar kunnen ook legitieme tools onder vallen, zoals uptimemonitors, betaalwebhooks en plugin-integraties. Schakel Sta typische WordPress automatiseringen toe in, of voeg voor de tool een uitzondering met Toestaan toe. Zie Botbescherming voor meer informatie.
3. Kijk bij de Uitzonderingen van Botbescherming of er een regel met Blokkeren is die overeenkomt met het IP-adres, het pad, de user agent of het land van de bezoeker.
4. Kijk of het IP-adres van de bezoeker in de IP Deny tool staat.

Test je met je eigen IP-adres, zet dan eerst een eventuele VPN of privacy relay uit, zoals iCloud Private Relay. Anders ziet je site het IP-adres van de relay in plaats van het jouwe, en klopt een uitzondering voor jouw IP-adres niet.

Geblokkeerd door de webserver

Staat er “nginx” onder de kop, dan heeft de webserver geweigerd het gevraagde bestand of de gevraagde map te tonen. Zoek in de access.log van je site naar 403 om de URL te vinden, en controleer daarna:

• Een map zonder indexbestand: Open je een map zonder index.php of index.html, dan krijg je een 403 in plaats van een overzicht van de inhoud van de map. Voeg een indexbestand toe, of link naar een specifiek bestand in plaats van naar de map.

Geblokkeerd door Kwetsbaarheidsbescherming

Toont de pagina een firewallregel-ID, dan heeft Kwetsbaarheidsbescherming de request geblokkeerd. Die kwam overeen met een regel voor een bekende kwetsbaarheid in een plugin, thema of WordPress versie die op je site is geïnstalleerd. Deze blokkades komen als 403 in de access.log van je site terecht. Daar zie je dus welke URL’s wanneer zijn geblokkeerd.

Meestal betekent dit dat een deel van je site verouderd is. Sommige kwetsbaarheden zitten in veelgebruikte features, zoals bestanden uploaden via een formulier. Een regel kan dan naast aanvallers ook gewone bezoekers blokkeren, totdat de betreffende plugin is bijgewerkt.

1. Ga in MyKinsta naar Sites > sitenaam > Plugins en thema’s en filter de lijst op Kwetsbare plugins. Een kwetsbare versie heeft een uitroepteken en een rood gemarkeerd versienummer. Zie Plugins en thema’s beheren voor meer informatie.
2. Werk eerst de kwetsbare plugins bij, en ook de plugin die de geblokkeerde pagina of feature afhandelt. Weet je niet welke plugin het is, werk dan al je plugins, thema’s en de WordPress core bij.
3. Test de geblokkeerde pagina of actie opnieuw.
4. Schakel Automatische Updates in om te voorkomen dat dit nog eens gebeurt.

Kwetsbaarheidsbescherming kun je niet uitschakelen, en uitzonderingen met Toestaan in Botbescherming gaan er niet boven. Blijft de fout optreden nadat je alles hebt bijgewerkt, neem dan contact op met support en vermeld de firewallregel-ID die op de pagina staat.

Geblokkeerd door een beveiligingsplugin of CDN

Heeft de pagina de huisstijl van een beveiligingsplugin, zoals Wordfence of Solid Security, of van een CDN of firewall van een derde partij, dan heeft die dienst de request geblokkeerd. Zoek in de instellingen of logs daarvan naar de geblokkeerde request en voeg daar een uitzondering toe. Gebruik je je eigen Cloudflare account, schakel de WAF- of botbeschermingsfeatures van Cloudflare dan niet in naast de Botbescherming van Kinsta, omdat die twee samen legitiem verkeer kunnen blokkeren.

Geblokkeerd door WordPress

WordPress toont een eigen melding als de rol van een ingelogde gebruiker een actie niet toestaat, of als een beveiligingslink is verlopen:

• “Sorry, you are not allowed to access this page”: De rol van de gebruiker heeft daar geen rechten voor. Controleer de rol van de gebruiker onder Users in WordPress, of log in als beheerder.
• “The link you followed has expired”: De pagina stond te lang open of werd uit de cache geladen. Laad de pagina opnieuw en probeer het nog eens. Zie je dit bij het uploaden, dan kan het bestand ook te groot zijn. Zie 413 Request Entity Too Large.

Wanneer neem je contact op met support?

Kun je niet achterhalen wat de request blokkeert, neem dan contact op met support en geef de URL, het tijdstip en de tijdzone van de fout door, een screenshot van de foutpagina en het IP-adres van de bezoeker als je dat weet.

404 Not Found

Een 404 Not Found fout betekent dat de gevraagde pagina of het gevraagde bestand niet op die URL bestaat. Een paar 404’s zijn normaal, bijvoorbeeld als bezoekers een URL verkeerd typen of bots bestanden opvragen die je site niet heeft. Ga het pas uitzoeken als echte pagina’s of bestanden een 404 geven, of als er 404’s ontstaan na een wijziging aan je site.

De access.log van je site registreert elke 404 met de gevraagde URL. Zoek daarin naar 404 om te zien om welke URL’s het gaat.

• Alle berichten en pagina’s geven een 404, maar de homepage werkt: De permalinkinstellingen van WordPress moeten worden vernieuwd. Ga in WordPress naar Settings > Permalinks en klik op Save Changes zonder iets te wijzigen.
• Na een migratie, domeinwijziging of push van een omgeving: Links en bestandspaden kunnen nog naar het oude domein of de oude map wijzen. Werk oude URL’s bij met de tool Zoeken en vervangen, en controleer of geüploade bestanden zijn meegekopieerd.
• Een bestaand bestand geeft een 404: De webserver heeft mogelijk geen rechten om het te lezen. In de error.log van je site staat dan open() "..." failed (13: Permission denied) met het pad van het bestand. Dit gebeurt vaak na het uploaden van bestanden via SFTP of het deployen van code. Controleer de rechten van het bestand in je SFTP client (bij de meeste zie je ze als je met de rechtermuisknop op een bestand klikt en de rechten of info opent) of via SSH met ls -l. Bestanden horen op 644 te staan en mappen op 755.
• Een pagina of bestand is verplaatst of verwijderd: Voeg een redirect toe van de oude URL naar de nieuwe, zodat bestaande links en zoekresultaten blijven werken.
• Een pagina die je net hebt gepubliceerd, geeft nog een 404: De 404 staat mogelijk in de cache. Leeg de cache van je site en een eventuele CDN cache.

405 Method Not Allowed

Een 405 Method Not Allowed fout betekent dat de URL wel bestaat, maar het type request dat is verstuurd niet accepteert. Elke request gebruikt een methode, zoals GET om een pagina te laden of POST om een formulier te versturen, en sommige URL’s accepteren alleen bepaalde methodes. Je ziet deze fout meestal bij formulieren, webhooks en integraties, en minder bij bezoekers die pagina’s laden.
Zoek in de access.log van je site naar 405 om te zien welke URL en methode zijn gebruikt.

• Een formulier of tool stuurt data naar een statisch bestand: Verstuur je een formulier (een POST request) naar een statisch bestand, zoals een .html bestand of een afbeelding, dan krijg je een 405, omdat statische bestanden alleen geladen kunnen worden. Controleer of de action van het formulier of de URL van de tool naar een WordPress pagina of endpoint wijst, en niet naar een bestand.
• Een webhook of integratie gebruikt de verkeerde methode: Betaalproviders, formulierdiensten en andere integraties hebben precies de URL en methode nodig die in hun documentatie staan. Controleer de instellingen van de integratie en kopieer de URL opnieuw uit de plugin die hem levert.
• Een redirect verandert de request: Wordt een request doorgestuurd, bijvoorbeeld van http:// naar https:// of van www. naar het domein zonder www, dan versturen veel tools hem opnieuw als GET. Een endpoint dat een POST verwacht, weigert hem dan. Gebruik in de instellingen van de tool de uiteindelijke URL, inclusief https:// en het juiste domein.

413 Request Entity Too Large

Een 413 Request Entity Too Large fout betekent dat een request, meestal een bestandsupload, te groot was om te accepteren. Je site heeft twee uploadlimieten, en welke limiet een bestand overschrijdt, bepaalt wat je te zien krijgt:

• De limiet van de webserver (128 MB): Requests groter dan 128 MB worden geweigerd voordat ze WordPress bereiken. Tools zoals curl en API clients tonen de 413, maar uploadtools in de browser, zoals de media-uploader van WordPress, tonen meestal een algemene uploadfout. In de error.log van je site staat de request dan als client intended to send too large body, gevolgd door de grootte in bytes.
• De PHP uploadlimiet van je pakket: De request bereikt WordPress wel, maar PHP weigert het bestand, dus er komt geen 413. WordPress toont in plaats daarvan een eigen melding, zoals “exceeds the maximum upload size for this site” of “The link you followed has expired”.

De PHP uploadlimiet van je pakket (upload_max_filesize en post_max_size) is:

• 128 MB: Single 125k bezoeken en lager, Single 65 GB bandbreedte en lager, WP 2, Launch, Launch Plus, Build en Expand.
• 256 MB: Single 315k bezoeken en hoger, Single 125 GB bandbreedte en hoger, WP 5 en hoger, Scale en Lead.
• Dedicated servers: De limiet kan worden verhoogd naar 500 MB. Neem contact op met support om dit aan te passen.

Moet je bestanden uploaden die groter zijn dan je limiet, gebruik dan een van de opties hieronder.

• Grote bestanden op een andere manier uploaden: Upload grote bestanden, zoals video’s, backups of importbestanden, via SFTP in plaats van via de browser. Media voor WordPress voeg je daarna met WP-CLI (wp media import) toe aan de Media Library.
• De bestandsgrootte verkleinen: Comprimeer afbeeldingen en video’s, of splits grote importbestanden op in kleinere.
• Grote database-imports: Gebruik WP-CLI zoals beschreven in MySQL database importeren.
• CDN van een derde partij: Gebruik je een ander CDN of een andere proxy, dan kan de limiet daar lager zijn dan bij Kinsta. Controleer de uploadlimiet daarvan.

429 Too Many Requests

Een 429 Too Many Requests fout betekent dat er in korte tijd te veel requests van dezelfde bron binnenkwamen, waardoor de webserver van je site ze tijdelijk heeft beperkt. Requests boven de limiet worden geweigerd tot het aantal daalt. Andere bezoekers merken daar niets van.

In de error.log van je site staat elke beperkte request als limiting requests, excess: ... by zone "phpzone".

• Bots en scrapers: Geautomatiseerd verkeer dat snel veel pagina’s afgaat, is de meest voorkomende oorzaak. Zoek de bron op met het rapport Top verkeer in Botbescherming, en blokkeer die daarna of verhoog je beschermingsniveau.
• Plugins en integraties: Tools die je site synchroniseren, importeren of controleren, kunnen pieken van requests sturen, bijvoorbeeld naar admin-ajax.php of de WordPress REST API. Laat ze minder vaak draaien, of stel ze zo in dat ze requests in kleinere batches versturen.
• Loadtests: Tools die zwaar verkeer vanuit één bron simuleren, lopen snel tegen de rate limit aan. Loadtests zijn niet toegestaan bij Kinsta. Zie onze Servicevoorwaarden voor meer informatie.

Wordt legitiem verkeer beperkt, neem dan contact op met support en geef het tijdstip van de fouten door en het betrokken IP-adres of de betrokken tool.

451 Unavailable For Legal Reasons

Een 451 Unavailable For Legal Reasons fout betekent dat de toegang tot de pagina is geblokkeerd om te voldoen aan een wet of een rechterlijk bevel. Deze fout komt meestal niet van je site of van Kinsta.

• Bezoekers in één land zien de fout: Hun internetprovider of overheid blokkeert je site waarschijnlijk op netwerkniveau. Je site werkt nog, bezoekers op andere locaties kunnen hem nog bereiken en je hoeft niets te wijzigen in MyKinsta of WordPress.
• Een plugin blokkeert bezoekers op basis van locatie: Sommige plugins beperken de toegang vanuit bepaalde landen om privacyredenen of om aan wetgeving te voldoen, en geven dan een 451. Controleer de instellingen van je plugins, of deactiveer ze één voor één om te achterhalen welke de oorzaak is.

Heb je zelf een land geblokkeerd met een uitzondering in Botbescherming, dan zien bezoekers uit dat land een 403 en geen 451. Zie 403 Forbidden.

499 Client Closed Request

Bezoekers zien nooit een 499. Deze code komt in de access.log van je site terecht als de browser van de bezoeker, of een andere dienst die verbinding maakt met je site, de verbinding verbreekt voordat je site klaar is met antwoorden.

• Een paar 499’s zijn normaal: Ze worden gelogd als een bezoeker een tabblad sluit, wegklikt of het laden van een pagina stopt.
• 499’s met een request time van ongeveer 180 seconden: De request bereikte de limiet van 180 seconden, Cloudflare sloot de verbinding en de bezoeker kreeg een 524 time-outfout te zien. Behandel deze als time-outs. Zie 504 Gateway Timeout.
• Veel 499’s van dezelfde tool: Een uptimemonitor, integratie of andere dienst heeft mogelijk een kortere time-out dan je site nodig heeft om te antwoorden. Controleer de time-outinstelling van de tool, of zoek met de APM tool van Kinsta uit waarom de request zo traag is.