Vous ouvrez l’administration, lancez une mise à jour ou appelez la REST API, et la réponse tombe avec un mystérieux 407 Proxy Authentication Required. Pour corriger une WordPress erreur 407, identifiez d’abord le proxy situé entre votre client et le site, puis fournissez ses identifiants avec la configuration adaptée. Vérifiez ensuite que le serveur d’origine répond bien. Le code 407 ne signifie généralement pas que le mot de passe WordPress est faux. Il indique qu’un serveur mandataire demande une authentification avant de transmettre la requête.
Le cas le plus trompeur survient quand le site fonctionne dans Chrome mais échoue avec WP-CLI, curl, une extension ou un serveur de CI. Le navigateur utilise parfois automatiquement le proxy du réseau, tandis que l’outil en ligne de commande n’en connaît pas les paramètres. Voici une méthode sûre pour localiser la couche fautive sans désactiver au hasard le pare-feu ni modifier les identifiants WordPress.
Que signifie une WordPress erreur 407 ?
Le statut HTTP 407, nommé Proxy Authentication Required, est renvoyé par un serveur mandataire qui n’a pas reçu des informations d’authentification valides. Ce proxy se trouve entre le client et le serveur qui héberge WordPress. Il peut appartenir à l’entreprise, à l’hébergeur, à un réseau scolaire, à un VPN, à un CDN ou à une passerelle de sécurité.
La réponse doit normalement contenir l’en-tête Proxy-Authenticate. Celui-ci indique le mécanisme attendu, par exemple Basic ou une méthode négociée par l’infrastructure. Le client peut alors renvoyer la requête avec Proxy-Authorization. Cette mécanique est différente de WWW-Authenticate et de Authorization, utilisés pour l’authentification auprès du serveur final.
Une différence simple aide au diagnostic. Une erreur 401 concerne l’accès à la ressource et les identifiants du serveur d’origine. Une erreur 407 concerne l’intermédiaire. Si votre WordPress répond en 407 avant d’afficher la moindre page, commencez par la route réseau et non par les utilisateurs WordPress.
Localiser le proxy qui renvoie le statut
Relevez l’URL, la méthode, l’heure, le client utilisé et le corps de la réponse. Ne transmettez pas les cookies ou les jetons dans une capture. Une page de blocage avec le nom d’une passerelle, un en-tête Via ou un serveur inhabituel est un indice précieux. Comparez un navigateur, un poste hors réseau et une commande depuis le serveur qui exécute votre automatisation.
curl -i -sS --max-time 20
https://exemple.fr/wp-json/Observez la première ligne HTTP ainsi que Server, Via, Proxy-Authenticate, Content-Type et les éventuels identifiants de requête. Un proxy peut masquer le serveur WordPress, ce qui explique l’absence de trace dans les journaux PHP. Si le test direct depuis un autre réseau répond 200, le site n’est probablement pas à l’origine du 407.
Attention aux variables d’environnement. Sur Linux et macOS, HTTP_PROXY, HTTPS_PROXY et ALL_PROXY peuvent forcer curl, WP-CLI ou une bibliothèque PHP à passer par un intermédiaire. La variable NO_PROXY peut au contraire exclure certains domaines.
env | grep -iE '^(http|https|all|no)_proxy='
curl -i -sS --noproxy '*'
https://exemple.fr/wp-json/Le second test contourne le proxy configuré pour cette commande. Utilisez-le uniquement comme test comparatif dans un environnement autorisé. Il ne corrige pas la politique réseau et ne doit pas servir à contourner un contrôle d’accès d’entreprise.
Lire Proxy-Authenticate sans exposer un secret
La présence de Proxy-Authenticate confirme que l’intermédiaire attend une négociation. Le contenu de l’en-tête peut révéler le schéma mais jamais un mot de passe. Si le proxy demande Basic, les identifiants doivent tout de même transiter dans un canal chiffré. N’utilisez pas une URL contenant directement un couple utilisateur et mot de passe dans un historique de shell ou dans une tâche CI.
curl -i -sS
-x http://proxy.exemple.net:8080
https://exemple.fr/Avec cette commande, curl utilise le proxy indiqué. Pour un test authentifié, préférez un fichier de configuration protégé ou une variable secrète injectée par le coffre de votre CI. Vérifiez les permissions du fichier et effacez les journaux qui auraient enregistré la commande.
cat > curl-proxy.conf <<'EOF'
proxy = http://proxy.exemple.net:8080
proxy-user = utilisateur:mot-de-passe
EOF
chmod 600 curl-proxy.conf
curl --config curl-proxy.conf -i https://exemple.fr/Cet exemple est volontairement générique. N’enregistrez pas un secret permanent dans le dépôt Git, dans un fichier public ou dans une capture. Une authentification d’entreprise peut nécessiter Kerberos, NTLM, OAuth ou un agent réseau. Dans ce cas, Basic ne fonctionnera pas, même si l’adresse et le port sont corrects.
Configurer curl, WP-CLI et les tâches automatisées
WP-CLI s’appuie sur PHP et sur les mécanismes réseau disponibles sur la machine. Si une commande comme wp core update échoue en 407, comparez d’abord l’accès à une URL publique avec curl depuis le même compte système. Une erreur dans WP-CLI et dans curl pointe vers le proxy ou la configuration d’environnement. Une erreur uniquement dans WP-CLI invite plutôt à examiner PHP, ses certificats et l’extension utilisée.
wp cli version
wp core check-update --debug
curl -I -sS https://api.wordpress.org/Le mode --debug peut contenir des informations d’environnement. Utilisez-le sur une machine de test et masquez les identifiants avant de partager la sortie. Pour une tâche cron, vérifiez que le compte de service reçoit bien les variables de proxy. Le shell interactif et cron n’ont pas toujours le même environnement.
Dans une chaîne CI, stockez l’URL du proxy, le nom d’utilisateur et le secret dans le gestionnaire de variables de la plateforme. Évitez de reconstruire une URL complète dans une commande affichée par le journal. Désactivez la verbosité après le diagnostic. Une authentification réussie ne garantit pas que le proxy autorise les domaines de mise à jour WordPress.
Si seul un appel sortant vers l’API WordPress échoue, demandez à l’administrateur réseau d’autoriser le domaine et le port nécessaires. Ne remplacez pas le proxy par un serveur public trouvé sur Internet. Ces relais peuvent lire les requêtes, injecter des réponses et voler des identifiants.
Quand la REST API WordPress renvoie 407
La REST API sert aux éditeurs de blocs, aux intégrations et aux outils qui lisent ou modifient le contenu. Un proxy peut intercepter la route /wp-json/ comme n’importe quelle autre URL. Commencez par un GET public minimal, puis ajoutez l’authentification WordPress seulement quand le transport fonctionne.
curl -i -sS
-x http://proxy.exemple.net:8080
-H 'Accept: application/json'
'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'Si la réponse est 407, l’en-tête Authorization de WordPress ne réglera rien tant que Proxy-Authorization manque. Si la réponse devient 401 ou 403 après le passage du proxy, le problème réseau est résolu et il faut alors diagnostiquer les droits, les cookies, le nonce ou le mot de passe d’application.
Cette séparation évite de mélanger deux secrets. Le proxy authentifie le client auprès de l’intermédiaire. WordPress authentifie ensuite le client auprès de l’application. Dans une intégration sérieuse, les deux étapes sont journalisées par leur statut uniquement, sans enregistrer les valeurs sensibles.
Pour distinguer les statuts d’authentification, consultez aussi notre guide sur l’erreur 401 de la REST API WordPress et celui consacré à l’erreur 403 de la REST API.
Vérifier Apache, Nginx, LiteSpeed et le CDN
Un reverse proxy placé devant WordPress peut lui-même demander une authentification à ses clients. Dans une architecture Nginx ou Apache, contrôlez la configuration de la zone concernée, le port de sortie et les règles qui ajoutent ou suppriment les en-têtes. Sur un hébergement mutualisé, vous n’avez souvent pas accès à la passerelle. Donnez alors à l’hébergeur une URL, une heure UTC, le statut et les en-têtes non sensibles.
Ne confondez pas un proxy sortant et un reverse proxy entrant. Le premier est utilisé par votre serveur pour joindre une ressource externe. Le second reçoit les visiteurs avant de transmettre leur requête à WordPress. Un 407 sur le site public suggère plutôt une politique du reverse proxy ou du réseau du visiteur. Un 407 pendant une mise à jour sortante suggère plutôt le proxy du serveur.
curl -sS -D /tmp/wp-headers.txt -o /tmp/wp-body
https://exemple.fr/
grep -iE 'HTTP/|server|via|proxy-authenticate|content-type' /tmp/wp-headers.txtUn CDN peut conserver une page de blocage en cache. Purgez uniquement l’URL concernée après avoir corrigé la règle, puis retestez depuis deux réseaux. Une purge globale n’est pas nécessaire pour une erreur localisée. Si le statut disparaît avec une URL de contournement réservée aux administrateurs, faites vérifier la règle et retirez ce contournement après le test.
Ne pas corriger le 407 avec les mauvais outils
Réinstaller WordPress, vider les transitoires ou augmenter la mémoire PHP ne corrige pas un proxy qui refuse la requête avant PHP. De même, changer le mot de passe d’un utilisateur WordPress ne sert à rien si la réponse contient Proxy-Authenticate. Ces actions peuvent même créer un second incident en masquant la cause réelle.
N’ajoutez pas de règle permissive dans .htaccess pour accepter n’importe quelle requête. N’autorisez pas tout le domaine dans un WAF et ne désactivez pas TLS pour faire fonctionner un test. Les identifiants de proxy doivent être limités au compte, à l’hôte et aux destinations nécessaires.
Si le proxy d’entreprise est obligatoire, demandez sa configuration officielle à l’équipe réseau. Si vous administrez la passerelle, vérifiez les journaux d’authentification, l’horloge des machines, l’expiration du compte, la liste d’autorisation et le mécanisme annoncé. Un décalage d’horloge peut casser une authentification négociée. Une adresse IP changée peut aussi faire appliquer une autre politique.
Pour comparer ce diagnostic avec une réponse produite par le serveur Web, notre article sur WordPress erreur 406 traite la négociation de contenu et les faux positifs du WAF. Si le proxy attend trop longtemps avant de répondre, voyez également WordPress erreur 504.
Checklist de résolution
Notez le client qui échoue et testez la même URL depuis un autre réseau. Lisez les en-têtes de la réponse. Cherchez Proxy-Authenticate, Via et l’identité de la passerelle. Inspectez les variables HTTP_PROXY, HTTPS_PROXY, ALL_PROXY et NO_PROXY. Comparez curl avec et sans proxy dans un cadre autorisé. Vérifiez le compte du proxy, son mécanisme et ses droits de destination. Testez ensuite une URL WordPress publique, l’API REST et l’action qui échouait.
Une correction est validée seulement quand le résultat est cohérent depuis le compte de service et depuis l’outil concerné. Contrôlez une lecture REST, une opération WP-CLI et une mise à jour non destructive. Retirez le mode debug et toute exception temporaire. Enfin, documentez la passerelle, le mécanisme d’authentification, le domaine autorisé et la date de renouvellement du secret.
Si vous devez ouvrir un ticket, fournissez le statut, l’heure UTC, l’URL sans paramètres secrets, la méthode, les en-têtes de réponse non sensibles, l’adresse IP de sortie si elle est autorisée et un identifiant de corrélation. Cette information permet à l’hébergeur ou au réseau de retrouver la décision sans recevoir vos mots de passe.
FAQ sur WordPress erreur 407
Pourquoi WordPress affiche-t-il une erreur 407 ?
Un proxy situé entre le client et WordPress demande une authentification qu’il ne reçoit pas ou qu’il juge invalide. Vérifiez la passerelle et ses en-têtes avant les identifiants WordPress.
Quelle est la différence entre 401 et 407 ?
Le 401 concerne l’authentification auprès du serveur qui héberge la ressource. Le 407 concerne l’authentification auprès du proxy intermédiaire. Les en-têtes utilisés ne sont pas les mêmes.
Comment tester une erreur 407 avec curl ?
Utilisez curl -i depuis le même environnement que l’outil en panne, inspectez Proxy-Authenticate, puis comparez avec un test hors proxy autorisé. Ne publiez jamais les secrets dans la commande.
Une erreur 407 vient-elle d’un plugin WordPress ?
Rarement. Un plugin peut déclencher un appel sortant qui rencontre un proxy, mais le statut est généralement produit par l’intermédiaire réseau avant l’exécution de WordPress.
Faut-il désactiver le proxy pour réparer WordPress ?
Non. Le proxy peut être obligatoire pour la sécurité et la conformité. Corrigez son authentification ou sa liste d’autorisation, puis conservez le contrôle réseau.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.