PAGUP Agent ControlAccès WordPress pour les assistants IA
Essayer gratuitement

WordPress ne détecte pas HTTPS derrière Cloudflare ou un proxy inverse

Le navigateur utilise HTTPS, mais WordPress ne considère pas la requête reçue à l’origine comme sécurisée.

Confirmez que l’URL exacte utilisée par l’assistant se charge avec une connexion HTTPS valide.

Causes probables

  • Le navigateur utilise HTTPS, mais WordPress ne considère pas la requête reçue à l’origine comme sécurisée.
  • Le proxy ne transmet pas l’information de schéma dont WordPress a besoin pour reconnaître HTTPS.
  • L’adresse web de WordPress et l’adresse du site utilisent des schémas, hôtes ou chemins différents.
  • Une redirection change le schéma, l’hôte ou le chemin et peut aussi supprimer les en-têtes d’authentification.
  • 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

  1. Confirmez que l’URL exacte utilisée par l’assistant se charge avec une connexion HTTPS valide.
  2. Confirmez que WordPress lui-même considère la requête comme HTTPS, et pas seulement le navigateur.
  3. Examinez les en-têtes du proxy approuvé qui transmettent à WordPress le schéma HTTPS d’origine.
  4. Comparez l’adresse web de WordPress, l’adresse du site, l’hôte canonique public et l’adresse de base REST.
  5. Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.
  6. Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.

Appliquer le correctif minimal

  1. Corrigez la gestion du proxy approuvé et de l’origine afin que WordPress reconnaisse fiablement la requête HTTPS initiale.
  2. Alignez l’adresse web de WordPress, l’adresse du site, l’hôte public, le schéma HTTPS et l’adresse de base REST.
  3. Supprimez ou corrigez la redirection qui modifie la requête authentifiée de manière inattendue.
  4. Ajustez seulement la règle, la route ou la méthode du faux positif confirmé au lieu de désactiver globalement la protection.
  5. Transmettez des preuves assainies et versionnées au soutien lorsque le comportement demeure propre à l’extension.

Vérifier le résultat

  • L’avis disparaît seulement dans la condition corrigée et ne revient pas sur des pages d’administration sans lien.
  • La requête authentifiée atteint le point de terminaison canonique sans redirection inattendue.
  • L’index REST répond depuis l’URL HTTPS canonique et expose les espaces de noms attendus.
  • La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.

Ce qu’il ne faut pas faire

  • N’ajoutez pas un contournement permanent et non vérifié du proxy avant de confirmer le chemin approuvé de la requête.
  • Ne désactivez pas globalement le WAF ou l’extension de sécurité pour contourner une seule requête.
  • Ne modifiez pas le cœur de WordPress ou les fichiers d’une extension tierce comme première étape de diagnostic.
  • N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
  • 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.

Questions fréquentes

Dois-je forcer HTTPS avec un extrait de code permanent ?

Seulement après avoir compris le contrat d’hébergement et de proxy. Un extrait générique permanent peut masquer une erreur d’origine ou faire confiance à un en-tête transmis non vérifié.

Guides connexes

Sources et vérification

Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .