Erreurs du client

Les erreurs dont le code d’état commence par 4 signifient que votre site a bien reçu la requête, mais qu’il n’a pas pu ou n’a pas souhaité y donner suite : la page n’existe pas, le visiteur n’est pas autorisé à la consulter, la requête était trop volumineuse ou trop de requêtes ont été envoyées simultanément. Contrairement aux erreurs de serveur, elles ne signifient pas que votre site est hors service, mais elles indiquent généralement un réglage ou un fichier que vous pouvez modifier. La surveillance de la disponibilité de Kinsta n’envoie pas de notifications pour les erreurs figurant sur cette page ; elle vous alerte uniquement en cas d’erreurs de serveur 500, 502 et 504, ainsi qu’en cas de boucles de redirection.

401 Non autorisé

Une erreur 401 « Non autorisé » signifie que la page nécessite un nom d’utilisateur et un mot de passe, et que le visiteur n’en a pas saisi ou a saisi des informations erronées.

• Protection par mot de passe : si la protection htpasswd est activée sur votre site ou votre environnement de test, les visiteurs voient s’afficher une invite de connexion avant le chargement du site. Saisissez le nom d’utilisateur et le mot de passe définis dans MyKinsta, ou désactivez la protection htpasswd si le site doit être public.
• Requêtes API : les outils et intégrations qui se connectent à votre site via l’API REST de WordPress reçoivent un code 401 si leurs identifiants, tels qu’un mot de passe d’application, sont manquants, erronés ou révoqués. Vérifiez les identifiants dans les paramètres de l’outil.

403 Interdit

Une erreur 403 Interdit signifie que la requête a été bloquée intentionnellement. Plusieurs niveaux peuvent bloquer une requête vers votre site, et chacun affiche une page différente ; la page qui s’affiche est donc le moyen le plus rapide d’en déterminer la cause.

Identifier ce qui a bloqué la requête

Ouvrez la page affichant l’erreur et comparez-la à la liste ci-dessous. Si un visiteur a signalé l’erreur, demandez-lui une capture d’écran.

Suivez ensuite les étapes correspondant à ce type de blocage ci-dessous.

Bloqué par une règle d’accès dans MyKinsta

Si la page n’affiche qu’un en-tête « 403 Forbidden », la requête a été bloquée par les règles d’accès de votre site avant d’atteindre celui-ci ; elle n’apparait donc pas dans les journaux de votre site.

1. Dans MyKinsta, rendez-vous dans Sites > nom-du-site > Protection contre les robots, puis consultez le rapport « Top traffic ». Sélectionnez le type de trafic qui a été bloqué pour voir les adresses IP, les chemins d’accès, les agents utilisateurs et les pays concernés.
2. Vérifiez votre niveau de protection. Les niveaux plus stricts bloquent le trafic automatisé, qui peut inclure des outils légitimes tels que les outils de surveillance de disponibilité, les webhooks de paiement et les intégrations d’extensions. Activez l’option « Autoriser les automatisations WordPress courantes » ou ajoutez une exception d’autorisation pour l’outil concerné. Pour plus d’informations, consultez la section « Protection contre les robots ».
3. Vérifiez vos exceptions de protection contre les robots pour une règle de blocage correspondant à l’adresse IP, au chemin d’accès, à l’agent utilisateur ou au pays du visiteur.
4. Vérifiez si l’adresse IP du visiteur figure dans l’outil « Bloquer une adresse IP ».

Si vous effectuez des tests avec votre propre adresse IP, désactivez d’abord tout VPN ou relais de confidentialité, tel que le relais privé iCloud. Sinon, votre site détectera l’adresse IP du relais à la place de la vôtre, et une exception pour votre adresse IP ne correspondra pas.

Bloqué par le serveur web

Si la page affiche « nginx » sous l’en-tête, cela signifie que le serveur web a refusé de servir le fichier ou le dossier demandé. Recherchez « 403 » dans le fichier access.log de votre site pour identifier l’URL, puis vérifiez :

• Un dossier sans fichier d’index : l’accès à un dossier ne contenant pas de fichier index.php ou index.html renvoie un code 403 au lieu d’afficher le contenu du dossier. Ajoutez un fichier d’index ou créez un lien vers un fichier spécifique plutôt que vers le dossier.

Bloqué par la protection contre les vulnérabilités

Si la page affiche un identifiant de règle de pare-feu, cela signifie que la protection contre les vulnérabilités a bloqué la requête car celle-ci correspondait à une règle relative à une vulnérabilité connue dans une extension, un thème ou une version de WordPress installée sur votre site. Ces blocages sont enregistrés sous le code d’erreur 403 dans le fichier access.log de votre site ; vous pouvez donc y effectuer une recherche pour voir quelles URL ont été bloquées et à quel moment.

Cela signifie généralement qu’une partie de votre site n’est plus à jour. Certaines vulnérabilités affectent des fonctionnalités courantes, telles que le téléchargement de fichiers via un formulaire ; une règle peut donc bloquer aussi bien les visiteurs lambda que les attaquants jusqu’à ce que l’extension concernée soit mise à jour.

1. Dans MyKinsta, rendez-vous dans Sites > nom-du-site > Extensions et thèmes, puis filtrez la liste par Extensions vulnérables. Une version vulnérable est signalée par un point d’exclamation et son numéro de version est surligné en rouge. Pour plus d’informations, consultez la section « Gérer les extensions et les thèmes ».
2. Mettez d’abord à jour les extensions vulnérables, ainsi que l’extension qui gère la page ou la fonctionnalité bloquée. Si vous ne parvenez pas à identifier l’extension concernée, mettez à jour l’ensemble de vos extensions, thèmes et le cœur de WordPress.
3. Testez à nouveau la page ou l’action bloquée.
4. Pour éviter que cela ne se reproduise, activez les mises à jour automatiques.

La protection contre les vulnérabilités ne peut pas être désactivée, et l’option Autoriser les exceptions dans la protection contre les robots ne la remplace pas. Si l’erreur persiste après avoir tout mis à jour, contactez le support et indiquez l’identifiant de la règle de pare-feu affiché sur la page.

Bloqué par un plugin de sécurité ou un CDN

Si la page est marquée par une extension de sécurité, tel que Wordfence ou Solid Security, ou par un CDN ou un pare-feu tiers, c’est ce service qui a bloqué la requête. Vérifiez ses réglages ou ses journaux pour identifier la requête bloquée, puis ajoutez-y une exception. Si vous utilisez votre propre compte Cloudflare, n’activez pas les fonctionnalités WAF ou de protection contre les robots de Cloudflare en parallèle de la protection contre les robots de Kinsta, car ces deux systèmes peuvent bloquer du trafic légitime.

Bloqué par WordPress

WordPress affiche son propre message lorsque le rôle d’un utilisateur connecté ne lui permet pas d’effectuer une action, ou lorsqu’un lien de sécurité a expiré :

• « Désolé, vous n’êtes pas autorisé(e) à accéder à cette page » : le rôle de l’utilisateur ne dispose pas des autorisations nécessaires. Vérifiez le rôle de l’utilisateur dans la section « Comptes » de WordPress, ou connectez-vous en tant qu’administrateur.
• « Le lien que vous avez suivi a expiré » : la page est restée ouverte trop longtemps ou a été chargée à partir du cache. Actualisez la page et réessayez. Si ce message s’affiche lors d’un téléversement, il se peut également que le fichier soit trop volumineux ; voir « 413 Request Entity Too Large ».

Quand contacter le support

Si vous ne parvenez pas à identifier la cause du blocage de la requête, contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur, une capture d’écran de la page d’erreur, ainsi que l’adresse IP du visiteur si vous la connaissez.

404 Not Found

Une erreur 404 Non Trouvé signifie que la page ou le fichier demandé n’existe pas à cette URL. Quelques erreurs 404 sont normales, par exemple lorsque des visiteurs saisissent mal une URL ou que des robots demandent des fichiers que votre site ne contient pas. Examinez ces cas lorsque des pages ou des fichiers réels renvoient des erreurs 404, ou lorsque des erreurs 404 apparaissent après une modification apportée à votre site.

Le fichier access.log de votre site enregistre chaque erreur 404 avec l’URL demandée ; recherchez donc « 404 » dans ce fichier pour identifier les URL concernées.

• Tous les articles et toutes les pages renvoient des erreurs 404, mais la page d’accueil fonctionne : les réglages de permaliens de WordPress doivent être actualisés. Dans WordPress, rendez-vous dans Réglages > Permaliens et cliquez sur Enregistrer les modifications sans rien modifier.
• Après une migration, un changement de domaine ou un déploiement en production : les liens et les chemins d’accès aux fichiers peuvent encore pointer vers l’ancien domaine ou dossier. Utilisez l’outil « Rechercher et remplacer » pour mettre à jour les anciennes URL, et vérifiez que les fichiers téléchargés ont bien été copiés.
• Un fichier existant renvoie une erreur 404 : il se peut que le serveur web ne dispose pas des droits nécessaires pour le lire. Le fichier error.log de votre site affiche le message « open() "..." failed (13: Permission denied) » accompagné du chemin d’accès du fichier. Cela se produit souvent après le téléversement de fichiers via SFTP ou le déploiement de code. Vérifiez les droits d’accès du fichier dans votre client SFTP (la plupart les affichent lorsque vous cliquez avec le bouton droit sur un fichier et que vous ouvrez ses droits d’accès ou ses informations) ou via SSH avec la commande « ls -l ». Les fichiers doivent être configurés sur 644 et les dossiers sur 755.
• Une page ou un fichier a été déplacé ou supprimé : ajoutez une redirection de l’ancienne URL vers la nouvelle, afin que les liens existants et les résultats de recherche continuent de fonctionner.
• Une page que vous venez de publier affiche toujours une erreur 404 : l’erreur 404 est peut-être mise en cache. Videz le cache de votre site ainsi que tout cache CDN.

405 Méthode non autorisée

Une erreur 405 « Méthode non autorisée » signifie que l’URL existe, mais qu’elle n’accepte pas le type de requête qui a été envoyée. Chaque requête utilise une méthode, telle que GET pour charger une page ou POST pour valider un formulaire, et certaines URL n’acceptent que certaines méthodes. Cette erreur apparait le plus souvent au niveau des formulaires, des webhooks et des intégrations, plutôt que lorsque des visiteurs chargent des pages.
Recherchez « 405 » dans le fichier access.log de votre site pour identifier l’URL et la méthode utilisées.

• Un formulaire ou un outil envoie des données vers un fichier statique : l’envoi d’un formulaire (une requête POST) vers un fichier statique, tel qu’un fichier .html ou une image, renvoie un code 405, car les fichiers statiques ne peuvent être que chargés. Vérifiez que l’action du formulaire ou l’URL de l’outil pointe vers une page ou un point de terminaison WordPress, et non vers un fichier.
• Un webhook ou une intégration utilise une méthode incorrecte : les prestataires de paiement, les services de formulaires et autres intégrations nécessitent l’URL et la méthode exactes indiquées dans leur documentation. Vérifiez les paramètres de l’intégration et recopiez l’URL à partir du plugin qui la fournit.
• Une redirection modifie la requête : lorsqu’une requête est redirigée, par exemple de http:// vers https:// ou de www. vers le domaine sans « www », de nombreux outils la renvoient sous forme de requête GET ; un point de terminaison qui attend une requête POST la rejette alors. Utilisez l’URL finale, incluant https:// et le domaine correct, dans les paramètres de l’outil.

413 Entité de requête trop volumineuse

Une erreur 413 « Entité de requête trop volumineuse » signifie qu’une requête, généralement un téléversement de fichier, était trop volumineuse pour être acceptée. Votre site dispose de deux limites de téléversement, et c’est celle que le fichier dépasse qui détermine le message affiché :

• La limite du serveur web (128 Mo) : les requêtes supérieures à 128 Mo sont rejetées avant d’atteindre WordPress. Des outils tels que curl et les clients API affichent l’erreur 413, mais les outils de téléchargement des navigateurs, comme le gestionnaire de médias de WordPress, affichent généralement une erreur de téléversement générale à la place. Le fichier error.log de votre site enregistre la requête sous la forme « client intended to send too large body » (le client a tenté d’envoyer un corps trop volumineux), suivie de sa taille en octets.
• La limite de téléchargement PHP de votre plan : la requête parvient à WordPress, mais PHP rejette le fichier ; il n’y a donc pas d’erreur 413. À la place, WordPress affiche son propre message, tel que « dépasse la taille maximale de téléchargement pour ce site » ou « Le lien que vous avez suivi a expiré ».

La limite de téléversement PHP de votre plan (upload_max_filesize et post_max_size) est la suivante :

• 128 Mo : plan « Single » (125.000 visites et moins), plan « Single » (65 Go de bande passante et moins), WP 2, Launch, Launch Plus, Build et Expand.
• 256 Mo : Single 315.000 visites et plus, Single 125 Go de bande passante et plus, WP 5 et supérieurs, Scale et Lead.
• Serveurs dédiés : la limite peut être portée à 500 Mo. Veuillez contacter le service de support pour la modifier.

Si vous devez mettre en ligne des fichiers dont la taille dépasse votre limite, utilisez l’une des options ci-dessous.

• Téléverser des fichiers volumineux d’une autre manière : téléversez les fichiers volumineux, tels que les vidéos, les sauvegardes ou les fichiers d’importation, via SFTP plutôt que par le navigateur. Pour les médias WordPress, vous pouvez ensuite les ajouter à la médiathèque à l’aide de WP-CLI (commande « wp media import »).
• Réduire la taille des fichiers : compressez les images et les vidéos, ou divisez les fichiers d’importation volumineux en fichiers plus petits.
• Importer des bases de données volumineuses : utilisez WP-CLI comme décrit dans la section « Importer une base de données MySQL ».
• CDN tiers : si vous utilisez un autre CDN ou proxy, il se peut que sa limite de taille soit inférieure à celle de Kinsta. Vérifiez sa limite de téléversement.

429 Trop de requêtes

Une erreur 429 « Trop de requêtes » signifie qu’un trop grand nombre de requêtes a été envoyé depuis la même source en peu de temps ; le serveur web de votre site les a donc temporairement limitées. Les requêtes dépassant la limite sont rejetées jusqu’à ce que le débit diminue, et les autres visiteurs ne sont pas affectés.

Le fichier error.log de votre site enregistre chaque requête limitée sous la forme « limiting requests, excess: ... by zone "phpzone" ».

• Robots et scrapers : le trafic automatisé parcourant rapidement de nombreuses pages en est la cause la plus courante. Utilisez le rapport « Top traffic » dans la section « Protection contre les robots » pour identifier la source, puis bloquez-la ou renforcez votre niveau de protection.
• Extensions et intégrations : les outils qui synchronisent, importent ou vérifient votre site peuvent envoyer des rafales de requêtes, par exemple vers admin-ajax.php ou l’API REST de WordPress. Réduisez leur fréquence d’exécution ou configurez-les pour qu’ils envoient les requêtes par lots plus petits.
• Tests de charge : les outils qui simulent un trafic intense provenant d’une seule source sont rapidement soumis à une limitation de débit. Les tests de charge ne sont pas autorisés sur Kinsta ; pour plus d’informations, consultez nos Conditions générales d’utilisation.

Si du trafic légitime est limité, contactez le service de support en indiquant l’heure à laquelle les erreurs se sont produites ainsi que l’adresse IP ou l’outil concerné.

451 Indisponible pour des raisons juridiques

Une erreur 451 « Indisponible pour des raisons juridiques » signifie que l’accès à la page a été bloqué afin de se conformer à une loi ou à une décision judiciaire. Cette erreur ne provient généralement ni de votre site ni de Kinsta.

• Les visiteurs d’un pays donné voient s’afficher cette erreur : leur fournisseur d’accès Internet ou leur gouvernement bloque très probablement votre site au niveau du réseau. Votre site fonctionne toujours, les visiteurs situés ailleurs peuvent toujours y accéder, et il n’y a rien à modifier dans MyKinsta ou WordPress.
• Une extension bloque les visiteurs en fonction de leur localisation : certaines extensions restreignent l’accès depuis certains pays pour des raisons de confidentialité ou de conformité légale et renvoient un code d’erreur 451. Vérifiez les réglages de vos extensions ou désactivez-les une par une pour identifier celle qui est en cause.

Si vous avez vous-même bloqué un pays à l’aide d’une exception de protection contre les robots, les visiteurs de ce pays verront s’afficher un code 403, et non un 451 ; voir « 403 Forbidden ».

499 Requête fermée par le client

Les visiteurs ne voient jamais de code 499. Celui-ci est enregistré dans le fichier access.log de votre site lorsque le navigateur du visiteur, ou un autre service se connectant à votre site, interrompt la connexion avant que votre site n’ait fini de répondre.

• Quelques codes 499 sont normaux : ils sont enregistrés chaque fois qu’un visiteur ferme un onglet, quitte la page ou interrompt le chargement d’une page.
• Codes 499 avec un temps de requête d’environ 180 secondes : la requête a atteint la limite de 180 secondes, Cloudflare a fermé la connexion et le visiteur a vu s’afficher une erreur 524 (délai d’attente expiré). Traitez ces cas comme des délais d’attente expirés ; voir « 504 Erreur de délai d’attente de la passerelle ».
• De nombreuses erreurs 499 provenant du même outil : un outil de surveillance de la disponibilité, une intégration ou un autre service peut avoir un délai d’expiration plus court que le temps dont votre site a besoin pour répondre. Vérifiez le réglage de délai d’expiration de l’outil ou utilisez l’outil APM de Kinsta pour déterminer pourquoi la requête est lente.