Une connexion IA WordPress renvoie 500, 502 ou 503
WordPress, PHP ou une extension produit une erreur interne pendant le traitement de la requête.
Consignez le message exact assaini, le code HTTP et le corps de réponse sans inclure de secret.
Causes probables
- WordPress, PHP ou une extension produit une erreur interne pendant le traitement de la requête.
- Un proxy ou une passerelle n’obtient pas de réponse valide de l’origine WordPress.
- La résolution DNS, TLS, la connexion ou le traitement amont dépasse le délai du client ou du proxy.
- Un déploiement, une mise à jour, un redémarrage ou une période de maintenance retire temporairement le service.
- Les ressources de l’origine sont épuisées ou la concurrence dépasse la capacité actuelle.
- Une autre extension modifie la détection de HTTPS, l’accès REST ou la disponibilité des mots de passe d’application.
Séquence de diagnostic
- Consignez le message exact assaini, le code HTTP et le corps de réponse sans inclure de secret.
- Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.
- Examinez les journaux assainis de WordPress, PHP, l’origine et la passerelle autour d’un identifiant de requête.
- Comparez les délais du client, du proxy et de l’origine avec la durée mesurée de la requête.
- Interrogez l’index REST WordPress et confirmez la présence des espaces de noms et des métadonnées d’authentification attendus.
- Examinez l’événement exact du WAF ou de l’extension de sécurité, y compris la route, la méthode et l’identifiant de règle.
Appliquer le correctif minimal
- Corrigez l’erreur WordPress, PHP, d’extension ou d’origine révélée par les journaux assainis.
- Attendez la fin d’une maintenance documentée ou d’un incident amont transitoire, puis répétez le même test contrôlé.
- Réduisez la concurrence et la fréquence des nouvelles tentatives, puis respectez l’intervalle indiqué par le serveur.
- Ajustez seulement la règle, la route ou la méthode du faux positif confirmé au lieu de désactiver globalement la protection.
- Transmettez des preuves assainies et versionnées au soutien lorsque le comportement demeure propre à l’extension.
Vérifier le résultat
- Des contrôles répétés et limités retournent des réponses stables après la correction de l’origine ou de la passerelle.
- L’index REST répond depuis l’URL HTTPS canonique et expose les espaces de noms attendus.
- La lecture étroite approuvée réussit avec une réponse reproductible.
- Le registre final contient les versions, les preuves, le changement, la vérification et le retour arrière sans aucun secret.
Ce qu’il ne faut pas faire
- N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
- Ne désactivez pas globalement le WAF ou l’extension de sécurité pour contourner une seule requête.
- N’exposez pas publiquement les journaux de débogage ou les points de terminaison de diagnostic.
- Ne régénérez pas continuellement les identifiants et ne répétez pas la même requête sans comprendre le cycle de vie.
- Ne placez jamais un mot de passe d’application, un en-tête Authorization, un jeton ou un témoin dans une invite, un billet, un extrait de journal ou une capture.
Guides connexes
- Une connexion IA WordPress renvoie 429 Too Many Requests
- Une extension de sécurité ou un WAF bloque l’API REST WordPress
- Le point d’entrée WordPress /wp-json/ renvoie 404 : diagnostic de l’API REST
- Résoudre les problèmes d’accès de Claude Code ou Codex à WordPress
- Utiliser l’API REST WordPress avec un assistant IA
Sources et vérification
Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .
- RFC 9110: HTTP Semantics · RFC Editor
- REST API Handbook · WordPress Developer Resources
- Routes and Endpoints · WordPress Developer Resources