Installer WordPress derrière un reverse proxy : en-têtes et URL de site

Placer un proxy inverse devant un site est devenu banal : répartition de charge, terminaison du chiffrement, réseau de diffusion de contenu, passerelle applicative dans un conteneur. Le principe est simple, le proxy reçoit la requête du visiteur et la relaie au serveur qui héberge le site. Du point de vue de l'application, cette indirection change trois informations essentielles : le protocole employé, le nom d'hôte demandé et l'adresse du visiteur. WordPress, qui déduit beaucoup de choses de ces trois valeurs, se met alors à produire des adresses en clair, à boucler sur des redirections ou à considérer tous les visiteurs comme provenant d'une même machine. Les réglages qui corrigent cela sont peu nombreux et doivent être posés dans le bon ordre.

Ce que le proxy change pour l'application

Comprendre le mécanisme évite de tâtonner. Le proxy établit deux connexions distinctes, l'une avec le visiteur et l'autre avec le serveur applicatif, et rien ne garantit qu'elles emploient le même protocole ni le même nom d'hôte. Le fonctionnement général de ce composant est décrit dans notre article sur le reverse proxy, sa définition et son fonctionnement.

Le protocole vu par l'application

Le cas le plus courant place le chiffrement au niveau du proxy, qui relaie ensuite en clair vers le serveur applicatif sur le réseau interne. L'application voit donc une requête non chiffrée et en déduit que le site tourne en clair. Elle produit alors des adresses commençant par le protocole non sécurisé, ce qui provoque des avertissements de contenu mixte et parfois des boucles de redirection. C'est le symptôme numéro un de ce type d'installation. Il se manifeste souvent de façon partielle, certaines pages fonctionnant normalement et d'autres non, selon que le lien concerné est construit dynamiquement ou enregistré en base. Cette apparente incohérence égare le diagnostic, alors que la cause est unique.

Le nom d'hôte demandé

Le proxy peut transmettre le nom d'hôte d'origine ou le remplacer par celui du serveur interne, selon sa configuration. Dans le second cas, l'application construit ses adresses à partir d'un nom interne inaccessible depuis l'extérieur. Le site fonctionne en apparence et tous les liens absolus pointent vers une machine que personne ne peut joindre. Ce défaut se voit immédiatement en survolant un lien. Il est en revanche invisible depuis le réseau interne, où le nom en question répond parfaitement, ce qui explique qu'il passe la recette et se révèle en production.

L'adresse du visiteur

Sans réglage particulier, l'application voit l'adresse du proxy et non celle du visiteur. Toutes les statistiques, toutes les limitations par adresse et tous les journaux deviennent inexploitables, chaque requête paraissant venir du même endroit. Les protections contre les tentatives de connexion cessent notamment de fonctionner, ce qui constitue un problème de sécurité réel. Une limitation configurée pour bloquer après cinq échecs par adresse bloque alors le proxy lui même, donc l'ensemble des visiteurs, dès qu'un attaquant a produit cinq erreurs. Le comportement observé est celui d'un site qui refuse toute connexion sans raison apparente.

Le port employé

Le proxy écoute sur un port standard et relaie souvent vers un port non standard. Une application qui construit ses adresses en incluant le port produit des liens comportant un numéro de port interne. Ce cas est plus rare et il se rencontre sur les installations en conteneurs. Il se corrige avec les mêmes mécanismes que les précédents. La transmission du port d'origine suit exactement la même logique que celle du protocole et du nom d'hôte.

Les en têtes de transmission

La convention établie veut que le proxy ajoute des en têtes indiquant le protocole d'origine, le nom d'hôte d'origine, l'adresse du visiteur et le port. Ces en têtes ne sont pas ajoutés automatiquement, ils doivent être configurés côté proxy. La moitié des problèmes rencontrés vient de leur absence pure et simple, l'autre moitié de leur non prise en compte côté application. Le diagnostic consiste donc toujours à vérifier d'abord ce que le proxy envoie, puis ce que l'application en fait, dans cet ordre. Inverser ces deux vérifications fait perdre du temps.

La question de la confiance

Ces en têtes sont de simples champs de requête, que n'importe qui peut envoyer. Les prendre en compte sans vérifier que la requête vient bien du proxy permet à un visiteur de se déclarer sous une adresse arbitraire. La règle est donc de ne les considérer que si la connexion provient d'une adresse de confiance connue. Ce point est régulièrement négligé et il ouvre des contournements de limitation. La plupart des exemples de configuration trouvés en ligne omettent cette vérification, ce qui explique sa rareté dans les installations réelles.

Régler la détection du protocole

C'est la première correction à apporter et elle règle à elle seule la majorité des symptômes constatés.

Configurer le proxy

Le proxy doit ajouter l'en tête indiquant le protocole d'origine, et écraser sa valeur plutôt que de l'ajouter à une valeur existante. Un en tête cumulant deux valeurs séparées par une virgule est une source classique de comportement erratique. La directive correspondante figure dans la configuration du site sur le serveur frontal et elle tient en une ligne. Elle doit être posée sur chaque emplacement relayé, et non seulement sur la racine, faute de quoi certaines requêtes passent sans l'en tête.

Déclarer la variable côté application

Quelques lignes placées avant le chargement du cœur, dans le fichier de configuration, lisent l'en tête et positionnent la variable interne que l'application consulte pour savoir si la connexion est chiffrée. Cette manipulation est documentée et parfaitement standard. Elle doit être placée avant l'appel qui charge les réglages, faute de quoi elle intervient trop tard. Le rôle de ce fichier est détaillé dans notre article sur le fichier wp-config de WordPress et son fonctionnement.

Vérifier la confiance

La lecture de l'en tête doit être conditionnée à la provenance de la requête. Comparer l'adresse de connexion à celle du proxy, ou à une plage réseau interne, avant de tenir compte de l'en tête, ferme le contournement décrit plus haut. Cette condition tient en une ligne supplémentaire. Son absence est la règle sur les installations trouvées en ligne. Une plage réseau privée constitue en général une condition suffisante, le proxy et l'application communiquant sur un réseau interne.

Ne pas forcer aveuglément

Positionner la variable à vrai sans condition fonctionne et supprime toute possibilité de servir le site en clair, y compris depuis le réseau interne pour un test. Cette solution expéditive convient à un serveur où le proxy est le seul point d'entrée, ce qui doit être vérifié. Dans une architecture comportant plusieurs chemins d'accès, elle produit des comportements incohérents. Elle complique aussi les diagnostics, puisqu'elle rend impossible toute reproduction d'un problème en accédant directement au serveur applicatif.

Contrôler les redirections

Une boucle de redirection survient lorsque le proxy redirige vers le protocole sécurisé et que l'application, se croyant en clair, redirige à son tour. La correction de la détection résout cette boucle. Le symptôme est reconnaissable entre tous : le navigateur signale un nombre excessif de redirections et refuse d'afficher la page, sans qu'aucune erreur n'apparaisse dans les journaux applicatifs. Il faut par ailleurs s'assurer qu'une seule couche gère la redirection, le proxy ou l'application, jamais les deux. La confier au proxy est généralement préférable, puisqu'elle intervient alors avant tout traitement applicatif. Le principe général du passage au protocole sécurisé est développé dans notre article sur l'usage du HTTPS pour la sécurité et le SEO.

Traiter les contenus mixtes résiduels

Une fois la détection corrigée, les adresses enregistrées en base peuvent encore comporter l'ancien protocole. Un remplacement en base, mené avec un outil respectant les données sérialisées, corrige ces occurrences. Une modification manuelle par requête simple casse les valeurs sérialisées, ce qui provoque des dysfonctionnements difficiles à diagnostiquer. C'est un point sur lequel l'outillage adapté est indispensable. Les outils en ligne de commande dédiés à ce type de remplacement gèrent correctement la sérialisation et permettent une simulation avant application.

Fixer les adresses du site

Les deux adresses enregistrées par WordPress, celle du site et celle de l'installation, déterminent la construction de tous les liens absolus. Derrière un proxy, il vaut mieux les figer que de les laisser se déduire de la requête.

Définir les constantes

Déclarer les deux adresses en constantes dans le fichier de configuration les rend immuables et supprime toute dépendance à ce que voit l'application. Les champs correspondants deviennent alors non modifiables depuis l'interface, ce qui est exactement l'effet recherché. C'est la mesure la plus robuste sur une installation derrière proxy. Elle présente en outre l'avantage de rendre le comportement identique quel que soit l'état de la base, ce qui simplifie les restaurations et les copies d'environnement.

Le cas des environnements multiples

Un même code déployé en développement, en recette et en production doit porter des adresses différentes. Les constantes se lisent alors depuis des variables d'environnement plutôt que d'être écrites en dur. Cette approche évite les erreurs de déploiement, où l'adresse de recette se retrouve en production. Elle est devenue la norme sur les installations conteneurisées. Le même conteneur peut alors être promu d'un environnement à l'autre sans aucune modification de son contenu.

Le nom d'hôte transmis

Lorsque le proxy remplace le nom d'hôte, il doit être configuré pour transmettre l'original dans un en tête dédié. Certaines configurations préfèrent conserver le nom d'origine dans l'en tête d'hôte standard, ce qui simplifie tout. Cette seconde approche est préférable lorsqu'elle est possible, puisqu'elle rend l'indirection transparente pour l'application. Elle suppose que le serveur applicatif accepte de répondre pour ce nom d'hôte, ce qui demande parfois d'ajuster sa configuration de site virtuel.

Les fichiers statiques

Les adresses des images, feuilles de style et scripts sont construites à partir de l'adresse d'installation. Une adresse mal fixée produit des ressources introuvables et un site sans mise en forme. Ce symptôme spectaculaire a l'avantage d'être immédiatement visible, contrairement à d'autres défauts plus discrets. Il ne faut pas confondre ce cas avec celui d'un fichier de configuration de cache mal réglé, qui produit un symptôme identique pour une cause différente.

L'interface d'administration

Une adresse incorrecte rend l'administration inaccessible, ce qui empêche de la corriger depuis l'interface. C'est la raison pour laquelle la déclaration en constantes est préférable : elle reste modifiable par accès aux fichiers, même quand plus rien ne répond. Prévoir cet accès avant d'intervenir évite une situation inconfortable. Vérifier que l'on peut effectivement éditer le fichier de configuration, par transfert ou en ligne de commande, fait partie de la préparation de l'intervention.

Le sous répertoire

Une installation servie depuis un sous chemin par le proxy demande que les deux adresses reflètent ce chemin. Le proxy doit par ailleurs être configuré pour ne pas retirer le préfixe, ou l'application pour en tenir compte. Cette configuration est nettement plus délicate que la publication à la racine d'un domaine et elle mérite d'être évitée lorsque le choix est possible. Un sous domaine dédié coûte moins cher en configuration et en diagnostics ultérieurs qu'un sous chemin, pour un résultat équivalent du point de vue de l'utilisateur.

Restaurer l'adresse du visiteur

Cette correction est distincte des précédentes et elle conditionne le bon fonctionnement de tout ce qui raisonne sur l'origine des requêtes.

Lire l'en tête approprié

Le proxy transmet l'adresse d'origine dans un en tête dédié, sous la forme d'une liste lorsque plusieurs intermédiaires se succèdent. La valeur utile est celle correspondant au premier intermédiaire de confiance en partant de la fin, et non simplement la première de la liste, qui peut être forgée. Cette subtilité est la source d'erreur la plus fréquente sur ce sujet. Un visiteur peut en effet envoyer lui même cet en tête, qui se retrouve alors en tête de liste, précédant les valeurs ajoutées par les intermédiaires réels.

Positionner la variable serveur

Quelques lignes dans le fichier de configuration remplacent la variable contenant l'adresse distante par la valeur extraite. Toutes les extensions et tout le cœur bénéficient alors de la correction sans modification. C'est l'approche la plus simple et elle doit rester conditionnée à la provenance de la requête. Elle a l'inconvénient de modifier une variable que d'autres codes pourraient vouloir lire dans son état d'origine, ce qui reste théorique dans la pratique.

Préférer un module serveur

Les serveurs web proposent des modules dédiés qui effectuent cette substitution avant même que l'application ne soit appelée, avec une gestion correcte des intermédiaires de confiance. Cette solution est plus propre que le code applicatif et elle bénéficie aussi aux journaux du serveur, qui enregistrent alors directement la bonne adresse sans configuration supplémentaire. Elle demande un accès à la configuration du serveur, ce qui n'est pas toujours possible. Sur un hébergement infogéré, la demande peut être adressée au prestataire, qui connaît généralement bien ce réglage.

Vérifier les journaux du serveur

Tant que la correction n'est pas en place, les journaux enregistrent l'adresse du proxy pour chaque requête, ce qui les rend inutilisables pour toute analyse. La configuration du format de journalisation peut être adaptée pour enregistrer l'en tête plutôt que l'adresse de connexion. C'est un réglage distinct de celui de l'application et il est souvent oublié. Le corriger rétablit la valeur des journaux pour toutes les analyses ultérieures, y compris celles portant sur l'exploration par les moteurs.

Contrôler les limitations

Toute limitation par adresse, connexion, commentaires, formulaires, doit être retestée après correction. Avant celle ci, ces limitations bloquaient tout le monde en même temps ou ne bloquaient personne, selon leur implantation. Ce test est rapide et il révèle des protections qui n'avaient jamais fonctionné. Il consiste simplement à provoquer volontairement le nombre d'échecs prévu et à vérifier que le blocage intervient pour le seul poste concerné. Le mener depuis deux connexions différentes, un poste fixe et un téléphone en réseau mobile, rend la démonstration parfaitement concluante.

Vérifier la cohérence des mesures

Les statistiques de fréquentation, si elles reposent sur des mesures côté serveur, doivent redevenir cohérentes après correction. Comparer le nombre de visiteurs uniques avant et après donne une mesure directe de l'ampleur du problème passé. L'écart atteint parfois un facteur important, ce qui invalide rétrospectivement toutes les analyses menées sur la période concernée. Ce contrôle permet aussi d'expliquer une rupture dans les historiques, ce qui évite des interrogations ultérieures. Noter la date exacte de la correction dans la documentation du site suffit à rendre cette rupture compréhensible pour quiconque relira les courbes plus tard. Cette note se place dans le même fichier que la configuration du proxy, seul endroit où le prochain intervenant ira nécessairement regarder.