Erreurs du serveur

Dernière mise à jour 4 novembre 2026

Le service de surveillance de la disponibilité de Kinsta vérifie régulièrement votre site et vous envoie un e-mail s’il détecte une erreur 500, 502 ou 504. Les autres erreurs figurant sur cette page, telles que les erreurs 501 et 503, ne déclenchent pas de notification ; vous n’en serez donc informé que si vous-même ou vos visiteurs les constatez.

Erreur 500 du serveur interne

Une erreur 500 « Erreur interne du serveur » signifie que le code de votre site a rencontré un problème dont il n’a pas pu se remettre. Sur les sites WordPress, il s’agit généralement d’une erreur fatale PHP provenant d’une extension, d’un thème ou d’un code personnalisé, ou encore d’un processus à court de mémoire. Comme l’erreur se produit au sein même de votre site, elle est presque toujours consignée dans vos journaux.

Vérifiez votre journal d’erreurs

Notez l’heure de l’erreur et l’URL.
Dans MyKinsta, ouvrez le fichier error.log de votre site et recherchez les entrées correspondant à ce moment-là. Les erreurs fatales incluent la mention « PHP Fatal error » et indiquent généralement le nom du fichier et la ligne où le problème s’est produit.
Le chemin d’accès au fichier indique généralement la cause. Un chemin situé sous « wp-content/plugins/ » ou « wp-content/themes/ » renvoie à cette extension ou à ce thème.

Si le fichier error.log ne contient aucune entrée correspondante, vérifiez si le débogage WordPress est activé dans MyKinsta. Lorsqu’il est activé, les erreurs sont consignées dans le journal de débogage plutôt que dans le fichier error.log.

Causes courantes et solutions

Erreurs d’extension ou de thème : désactivez l’extension ou le thème mentionné dans l’erreur. Si vous ne parvenez pas à accéder au tableau de bord WordPress, renommez le dossier de l’extension via le gestionnaire de fichiers, par SFTP ou à l’aide de WP-CLI. Si l’erreur est apparue après une mise à jour, restaurez une sauvegarde ou annulez la mise à jour, puis transmettez l’erreur au développeur.
Erreurs de limite de mémoire (Allowed memory size ... exhausted) : une extension ou un processus a utilisé plus de mémoire que ce que PHP autorise, soit 256 Mo par thread PHP par défaut. Pour connaitre la fréquence de ce phénomène, consultez le graphique « PHP memory limit reached » dans MyKinsta, sous Sites > nom-du-site > Analyses > Performance. Corrigez d’abord l’extension ou le processus mentionné dans l’erreur, car un script défectueux peut consommer une quantité illimitée de mémoire. Si votre site a réellement besoin de plus de mémoire par thread, vous pouvez modifier vos réglages de performances PHP sous Sites > nom-du-site > Infos > Performances PHP. Le nombre de threads PHP et la mémoire allouée par thread sont définis conjointement ; ainsi, attribuer davantage de mémoire à chaque thread peut impliquer de réduire le nombre de threads en cours d’exécution ; consultez la section « Réduire et optimiser l’utilisation des threads PHP ».
Erreurs de limite de temps (Time Maximum execution time ... exceeded) : elles proviennent de processus qui ne passent pas par un navigateur, tels que les commandes WP-CLI ou les tâches cron, ou d’une extension qui définit sa propre limite de temps inférieure. Vérifiez quelle commande, tâche planifiée ou quelle extension était en cours d’exécution à ce moment-là.
Incompatibilité de version PHP : si les erreurs sont apparues après un changement de version de PHP, il se peut qu’une extension ou un thème ne prenne pas en charge la nouvelle version. Mettez à jour ou revenez temporairement à la version précédente.

Quand contacter le support

Si vous ne parvenez pas à identifier la cause, ou si les erreurs persistent après avoir suivi ces étapes, contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur, ainsi que toute entrée pertinente du fichier error.log.

501 Not Implemented

Une erreur 501 Not Implemented signifie que le serveur ne prend pas en charge l’opération demandée par la requête. Elle est rare sur Kinsta et n’est généralement pas causée par vos extensions ou votre thème.

Un environnement de staging arrêté : si vous constatez une erreur 501 sur un site de staging, il se peut que l’environnement de staging ait été arrêté. Dans MyKinsta, ouvrez l’environnement de staging et redémarrez-le.
Une méthode de requête inhabituelle : les outils et intégrations qui envoient des requêtes en utilisant une méthode non prise en charge par le serveur, comme certains clients de synchronisation de fichiers, peuvent générer une erreur 501. Vérifiez les réglages ou la documentation de l’outil.

Si vous constatez une erreur 501 sur votre site en production, consultez la page d’état de Kinsta, puis contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur.

Erreur 502 Bad Gateway

Une erreur 502 « Bad Gateway » signifie que le serveur web n’a pas pu obtenir de réponse valide de la part de PHP, la partie du serveur de votre site qui exécute WordPress. En général, cela signifie que PHP s’est bloqué lors du traitement d’une requête ou qu’il ne fonctionnait pas. Ces erreurs se produisent sur le serveur de votre site ; elles sont donc consignées dans les journaux de votre site.

Les erreurs survenant entre Cloudflare et votre site se présentent différemment. Les visiteurs voient s’afficher une page d’erreur portant la marque Cloudflare et comportant un identifiant « Ray ID » ; ces erreurs ne sont jamais enregistrées dans les journaux de votre site.

Vérifiez si l’erreur a atteint votre site

Notez l’heure à laquelle l’erreur s’est produite.
Si vous avez constaté l’erreur vous-même, vérifiez quelle page s’est affichée :
- Une page blanche avec le message « 502 Bad Gateway » et « nginx » en dessous provenait du serveur de votre site. Passez à l’étape suivante.
- Une page d’erreur portant la marque Cloudflare et comportant un Ray ID s’est affichée avant que la requête n’atteigne votre site. Contactez le support.
Dans MyKinsta, ouvrez le fichier access.log de votre site et recherchez le code d’erreur « 502 » à cette période.
Si vous trouvez une entrée correspondante, l’erreur provenait du serveur de votre site. Vérifiez le fichier error.log pour les entrées datant du même moment : « connect() to unix:...php-fpm.sock failed » signifie que PHP n’acceptait pas les requêtes ; une « PHP Fatal error » indique le nom du fichier à l’origine du plantage.
S’il n’y a pas d’entrée correspondante, l’erreur s’est produite avant que la requête n’atteigne votre site. Si vous utilisez un CDN tiers, consultez les informations ci-dessous ; sinon, contactez le support.

Si l’erreur provient du serveur de votre site

PHP s’est arrêté ou ne répond pas : si le fichier error.log affiche « connect() to unix:...php-fpm.sock failed », redémarrez PHP dans MyKinsta. Si le problème persiste, recherchez dans le fichier error.log les erreurs fatales survenues juste avant les codes 502.
Extensions et thèmes : une extension ou un thème peut provoquer le plantage d’un processus PHP au cours d’une requête. Si le fichier error.log indique une erreur fatale ou un plantage au moment de l’erreur 502, désactivez l’extension ou le thème concerné, ou effectuez un test en désactivant tous les extensions et en passant à un thème par défaut.

Si vous utilisez un CDN ou un proxy tiers

Si votre site utilise un CDN ou un proxy tiers en plus de l’intégration Cloudflare de Kinsta, contournez-le temporairement. Si les erreurs 502 cessent, contactez votre fournisseur de CDN pour obtenir des précisions sur ses réglages ou ses règles de pare-feu.

Quand contacter le support

Si les erreurs persistent, qu’aucune erreur 502 correspondante n’apparait dans votre fichier access.log ou qu’aucun élément de vos journaux ne permet de les expliquer, contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur, ainsi que la fréquence à laquelle elle se produit. Si les visiteurs ont vu une page d’erreur Cloudflare, veuillez inclure l’identifiant Ray qui y figure.

503 Service indisponible

Une erreur 503 « Service indisponible » signifie que votre site refuse temporairement les requêtes. Sur les sites WordPress, cela est généralement dû au fait que le site est en mode maintenance, soit intentionnellement, soit parce qu’une mise à jour n’a pas été menée à terme.

Brièvement indisponible pour cause de maintenance planifiée : WordPress affiche ce message pendant l’installation des mises à jour, puis le supprime une fois celles-ci terminées. Si une mise à jour est interrompue, le site peut rester en mode maintenance. Supprimez le fichier « .maintenance » du dossier racine de votre site via SFTP, puis vérifiez que la mise à jour de l’extension, du thème ou de WordPress s’est bien terminée et relancez-la si ce n’est pas le cas.
Une extension de mode maintenance ou « À venir » : ces extensions renvoient un code 503 afin que les moteurs de recherche sachent que le site sera de nouveau accessible. Désactivez le mode maintenance dans les réglages de l’extension, ou désactivez l’extension.
Une extension ou un thème renvoyant un code d’erreur 503 : si aucun de ces cas ne s’applique, désactivez vos extensions une par une afin d’identifier celle qui est en cause.

Si vous ne parvenez pas à identifier la cause, contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur.

Erreur 504 Timeout de la passerelle

Une erreur 504 « Timeout de la passerelle » signifie qu’une requête adressée à votre site a mis trop de temps à aboutir. Les requêtes adressées à votre site peuvent s’étendre jusqu’à 180 secondes. Si une requête n’est pas terminée dans ce délai, le serveur web cesse d’attendre et renvoie un code 504 ; les visiteurs voient alors s’afficher une page blanche portant la mention « 504 Gateway Time-out » suivie de « nginx ». Il arrive parfois que la limite de 180 secondes propre à Cloudflare soit atteinte en premier, et les visiteurs voient alors s’afficher une page « Cloudflare 524 : un délai d’attente a expiré » à la place. Ces deux erreurs ont la même signification : la requête a pris trop de temps.

Les délais d’attente surviennent généralement parce qu’une seule requête génère une charge trop importante, ou parce que de nombreuses requêtes arrivent simultanément et que certaines doivent patienter jusqu’à ce que le délai soit écoulé.

Identifiez la requête lente

Les délais d’expiration sont consignés dans les journaux de votre site, ce qui vous permet d’identifier la requête qui a pris trop de temps :

Notez l’heure à laquelle l’erreur s’est produite.
Dans MyKinsta, ouvrez le fichier access.log de votre site et recherchez le code d’erreur « 504 » aux alentours de cette heure. Une requête ayant expiré affiche un « upstream_response_time » (la dernière valeur de chaque ligne) d’environ 180 secondes. Notez les URL.
Le fichier error.log de votre site contient une entrée correspondante pour chacune d’entre elles : « upstream timed out ... while reading response header from upstream », suivie de l’URL de la requête.
Si les visiteurs ont vu à la place une page Cloudflare 524, recherchez dans le fichier access.log les entrées présentant un code d’état « 499 » et un temps de requête d’environ 180 secondes.
S’il n’y a pas d’entrées correspondantes, le délai d’expiration s’est produit avant que la requête n’atteigne votre site. Si vous utilisez un CDN tiers, consultez les informations ci-dessous ; sinon, contactez le service de support.

Si une requête ou une action est lente

Si les entrées lentes pointent toutes vers la même URL ou la même action :

Importations, exportations et opérations groupées : exécutez-les directement sur le serveur à l’aide de WP-CLI ou d’un script. Celles-ci ne sont pas soumises à la limite de 180 secondes.
Téléversements : les téléversements aboutissent généralement à un délai d’expiration en raison du traitement qui s’effectue après l’arrivée du fichier : redimensionnement ou optimisation des images, ou encore extensions qui copient des fichiers vers un stockage cloud tel qu’Amazon S3 ou Google Cloud Storage. Vérifiez les réglages de l’extension effectuant cette tâche, ou configurez-la pour qu’il effectue le traitement en arrière-plan si cette fonctionnalité est prise en charge.
Extensions et thèmes : une extension ou un thème peut exécuter du code lent ou attendre un service externe lent. Utilisez l’outil APM de Kinsta pour identifier le processus lent, ou désactivez les extensions une par une.
Base de données : des requêtes de base de données lentes ou bloquées peuvent empêcher une requête d’aboutir.

Si de nombreuses requêtes sont lentes simultanément

Si les requêtes lentes sont réparties sur de nombreuses URL, votre site reçoit peut-être plus de requêtes que ses threads PHP ne peuvent en traiter. Les requêtes font la queue en attendant qu’un thread se libère, et toute requête qui attend plus de 180 secondes expire. Une fois ce scénario enclenché, la quasi-totalité des requêtes peut aboutir à un délai d’expiration, car PHP continue de traiter des requêtes pour lesquelles les visiteurs ont déjà reçu un message d’erreur.

Consultez le rapport « Visites » dans les Analyses pour détecter les pics de trafic, et vérifiez le fichier kinsta-cache-perf.log pour repérer un nombre élevé de requêtes non mises en cache.
Si le trafic est légitime et régulier, votre site a peut-être besoin de davantage de threads PHP. Vous pouvez augmenter le nombre de threads PHP dans les réglages de performance PHP ; toutefois, l’augmentation du nombre de threads réduit la quantité de mémoire allouée par thread si vous n’augmentez pas également le pool de mémoire PHP. Pour en savoir plus, consultez l’article « Réduire et optimiser l’utilisation des threads PHP ».
Pour les pics de trafic de courte durée auxquels vous vous attendez, tels qu’une promotion ou un lancement, un service de mise en file d’attente tel que Queue-it, Queue-Fair ou CrowdHandler peut limiter le nombre de visiteurs accédant simultanément à votre site.

Si vous utilisez un CDN ou un proxy tiers

Certains CDN ont des délais d’expiration plus courts que ceux de Kinsta. Contournez temporairement le CDN ; si les erreurs cessent, vérifiez ses réglages de délai d’expiration ou contactez votre fournisseur de CDN.

Quand contacter le support

Si les erreurs persistent et que vous ne parvenez pas à identifier la requête lente, contactez le support en indiquant l’URL, l’heure et le fuseau horaire de l’erreur, ainsi que la fréquence à laquelle elle se produit.