Un reverse proxy (proxy inverse) peut être utilisé pour charger un site WordPress à partir d’un sous-répertoire tandis qu’un site complètement séparé se charge au niveau du domaine racine.

Un reverse proxy consiste en un ensemble de règles ajoutées à un serveur web qui lui demandent d’envoyer des requêtes pour un sous-dossier donné à un serveur séparé.

Prenons un exemple pour mieux comprendre à quoi peut servir un reverse proxy. Imaginez que vous avez un site web non-WordPress qui se charge sur exemple.com et que vous souhaitez utiliser WordPress pour alimenter un blog. Vous voulez que ce blog se charge sur exemple.com/blog et vous voulez héberger votre blog avec un hébergeur WordPress infogéré comme Kinsta. 

Pour ce faire, il faudrait configurer des règles de reverse proxy sur le serveur web hébergeant exemple.com en demandant au serveur web d’envoyer toute requête pour le sous-répertoire /blog à un autre serveur web hébergeant le site /blog alimenté par WordPress.

Option additionnelle Reverse Proxy

Kinsta permet et supporte l’utilisation de reverse proxy pour charger WordPress depuis un sous-dossier ou pour faire pointer un sous-dossier de votre site vers un serveur externe. Cependant, les reverse proxy sont souvent difficiles à configurer et à prendre en charge, et les sites qui utilisent les reverse proxy nécessitent généralement beaucoup plus de support que les installations WordPress standard.

Pour cette raison, un abonnement mensuel supplémentaire de 50 $ est appliqué pour chaque reverse proxy que Kinsta aide à mettre en place ou est appelé à supporter.

De plus, veuillez prévoir jusqu’à un jour ouvrable complet pour l’installation initiale d’une reverse proxy. Dans certains cas, du temps supplémentaire et une collaboration avec l’équipe de support de Kinsta peuvent être nécessaires pour que le reverse proxy fonctionne correctement dans les cas d’utilisation non standards.

Cas d’utilisation du reverse proxy

Il y a trois cas d’utilisation possibles pour les reverse proxy chez Kinsta. Pour comprendre ces cas d’utilisation, nous devons d’abord définir deux termes : site principal et site proxy.

  • Le site principal est le site qui se charge à la racine du domaine.
  • Les sites proxy est le site qui se charge à partir d’un sous-répertoire sur un reverse proxy.

Pour revenir à notre exemple ci-dessus, exemple.com serait le site principal tandis que exemple.com/blog serait le site proxy.

En gardant ces définitions à l’esprit, voici les trois cas d’utilisation possibles des reverse proxy chez Kinsta :

  • Sites principaux et sites proxy hébergés par Kinsta : Le site principal, exemple.com, et le site proxy, exemple.com/blog, sont tous deux hébergés chez Kinsta. Cela permettrait à une installation WordPress d’alimenter exemple.com alors qu’une installation WordPress complètement séparée serait utilisée sur exemple.com/blog.
  • Site proxy hébergé par Kinsta : Le site principal, exemple.com, n’est pas hébergé par Kinsta alors que le site proxy, exemple.com/blog est hébergé par Kinsta. Cela permettrait d’utiliser une installation WordPress hébergée chez Kinsta sur exemple.com/blog, alors que le site principal est hébergé ailleurs.
  • Site principal hébergé par Kinsta : Le site principal, exemple.com, est hébergé par Kinsta alors que le site proxy, exemple.com/blog n’est pas hébergé par Kinsta. Cela permettrait d’utiliser une installation WordPress hébergée chez Kinsta sur exemple.com, alors que le sous-répertoire blog est hébergé ailleurs.

Revoyons les implications de chaque option, en particulier, nous couvrirons les limites du support de Kinsta pour chaque scénario.

Exemple de serveur reverse proxy

Exemple de serveur reverse proxy

Sites principaux et proxy hébergés par Kinsta

Si les deux sites sont hébergés chez Kinsta, l’équipe de support de Kinsta peut mettre en place les règles de reverse proxy nécessaires sur le site principal et configurer le site proxy pour qu’il se charge sur le reverse proxy. Veuillez noter que le site principal et le site proxy doivent être situés dans le même centre de données. De plus, un court temps d’arrêt est possible lors de la configuration du reverse proxy, car Kinsta déplace les sites en place.

Dans ce scénario, les responsabilités du client comprendraient ce qui suit :

  • Migrer les deux sites vers l’environnement de Kinsta (ou soumettre des demandes de migration pour que Kinsta migre les sites).
  • Fournir à l’équipe de support de Kinsta une description claire de la configuration du domaine.
  • Prévoir environ un jour ouvrable pour chaque installation de reverse proxy.

Dans ce scénario, les responsabilités de Kinsta comprendraient ce qui suit :

  • Mettre en place les règles de reverse proxy nécessaires sur le site principal.
  • Configurer le site proxy pour qu’il se charge sur le reverse proxy.

Seul le site proxy est hébergé par Kinsta

Remarque importante : Si seul le site proxy est hébergé chez Kinsta, nous vous demandons de nous fournir les adresses IP du serveur proxy et de configurer le serveur proxy pour qu’il configure les en-têtes énumérés dans notre règle standard de reverse proxy Nginx. Ces étapes sont nécessaires pour s’assurer que notre système d’analyse fonctionne correctement et que nous ne mettons pas vos adresses IP de serveur proxy sur liste noire.

Si seul le site proxy est hébergé par Kinsta, la configuration du reverse proxy n’est pas quelque chose que Kinsta pourra faire car le reverse proxy doit être configuré sur le serveur qui héberge le site principal. Dans ce scénario, la responsabilité de Kinsta se limite à configurer le site proxy pour qu’il soit prêt à être chargé via un reverse proxy.

Dans ce scénario, les responsabilités du client comprendraient ce qui suit :

  • Migrer le site proxy vers Kinsta (ou soumettre une demande de migration pour que Kinsta migre le site).
  • Ajouter un domaine au site qui sera utilisé par le reverse proxy. Le reverse proxy doit être pointé sur un domaine afin d’accéder au site proxy. Généralement, un sous-domaine est utilisé à cette fin. Par exemple, blog.exemple.com serait typiquement utilisé pour un chargement par reverse proxy sur exemple.com/blog.
  • Fournir à l’équipe de support de Kinsta une description claire de la configuration du domaine.
  • Prévoir environ un jour ouvrable pour que le site proxy soit configuré de manière à ce qu’il puisse être chargé par l’intermédiaire d’un reverse proxy.
  • Une fois le site proxy configuré, créez le reverse proxy sur le serveur hébergeant le site principal.

Dans ce scénario, comme nous l’avons mentionné, la responsabilité de Kinsta se limite à configurer le site proxy de manière à ce qu’il soit correctement configuré pour être chargé sur un reverse proxy.

Seul le site principal est hébergé par Kinsta

Si le site principal est hébergé chez Kinsta, la responsabilité de Kinsta se limite à l’installation d’un reverse proxy pour charger le site proxy (hébergé ailleurs). Kinsta ajoutera la règle de reverse proxy standard listée dans cet article. Des personnalisations à cette règle peuvent être faites à la demande du client.

Dans ce scénario, le client conserve la responsabilité de configurer le site proxy de sorte qu’il se charge correctement sur le reverse proxy et de demander des ajustements à la règle de reverse proxy s’il ne charge pas correctement le site proxy.

Limites des sites proxy

Il y a certaines limites inhérentes à l’utilisation des reverse proxy chez Kinsta.

Tout d’abord, veuillez noter que Kinsta ne supporte pas l’utilisation du multisite sur un reverse proxy.

Vous avez des problèmes de temps d'indisponibilité et de WordPress ? Kinsta est la solution d'hébergement conçue pour vous faire gagner du temps ! Découvrez nos fonctionnalités

En outre, la restauration de sauvegardes ou la mise en place de sites de sauvegarde en direct sur des sites qui se chargent par l’intermédiaire d’un reverse proxy peut entraîner l’arrêt du chargement correct du site proxy. Lorsque vous travaillez avec un site proxy, il est toujours conseillé de programmer de tels changements pour les périodes de faible trafic et de consulter l’équipe de support Kinsta avant de prendre des mesures.

Chez Kinsta, lorsqu’il s’agit de sites proxy, la meilleure utilisation du staging est celle d’un environnement de test. Après les tests de développement, le workflow le plus simple consiste à dupliquer ces changements sur le site en production plutôt que de pousser le développement vers la production. En outre, la restauration des sauvegardes des sites proxy ne devrait être effectuée qu’en cas d’urgence, lorsqu’il n’est pas possible d’annuler manuellement les modifications.

En raison de ces limitations, nous ne recommandons pas l’utilisation de sites proxy si vous prévoyez de restaurer des sauvegardes ou de pousser des sites de développement en production sur une base régulière.

Une alternative aux sites proxy qui vaut la peine d’être envisagée est l’utilisation d’un sous-répertoire WordPress d’une installation multisite.

Configuration du serveur reverse proxy du site principal

Il y a deux implications majeures pour le site principal lorsque vous chargez des sous-répertoires sur des reverse proxy.

  • Des règles de reverse proxy doivent être ajoutées pour chaque sous-répertoire proxy.
  • Le site principal ne pourra pas utiliser les sous-répertoires proxy pour quelque raison que ce soit puisque toutes les demandes pour ce sous-répertoire seront transmises au site proxy.

C’est la règle de reverse proxy standard de Nginx utilisée par Kinsta pour charger un site sur un reverse proxy :

location ^~ /subdirectory/ {
  proxy_pass http://subdirectory.domain.com;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

Le sous-dossier réel serait substitué à /sous-dossier/. En outre, http://sous-dossier.domaine.com serait modifié pour correspondre au domaine utilisé pour pointer le reverse proxy sur le site proxy.

Configuration du site proxy

Afin de charger un site sur un serveur reverse proxy, les modifications suivantes doivent être effectuées :

  • Un sous-répertoire doit être ajouté au chemin du répertoire sur le serveur, correspondant au sous-répertoire utilisé pour charger le site et tous les fichiers du site Web déplacés vers ce sous-répertoire.
  • Les mises à jour de la configuration du serveur Web doivent être effectuées pour mettre à jour la racine du site Web afin d’inclure le nouveau sous-répertoire. En outre, une réécriture doit être ajoutée à la configuration de serveur pour supprimer le sous-répertoire de l’URI de la requête pour chaque requête entrante.
  • Toutes les URLs de la base de données du site proxy doivent être mises à jour pour correspondre aux URLs du site en production (par exemple, exemple.com/blog).
  • Le fichier wp-config.php du site doit être mis à jour avec une définition $_SERVER['HTTP_HOST']pointant vers l’URL du site principal (exemple.com dans l’exemple que nous avons considéré).
  • Si le site est forcé de charger via HTTPS, des définitions supplémentaires doivent être ajoutées au wp-config.php pour éviter les boucles de redirection.

Notez qu’en raison des règles de réécriture nécessaires, un site proxy doit éviter de créer des URLs qui dupliquent le même sous-répertoire sous lequel le site proxy se charge. Par exemple, un site proxy à exemple.com/blog devrait éviter de créer une page ou un répertoire tel que exemple.com/blog/blog.

Résumé

L’utilisation de reverse proxy chez Kinsta est possible et nous avons un certain nombre de clients qui ont choisi d’utiliser notre infrastructure de cette manière. Cependant, il est important de comprendre la complexité technique supplémentaire que cet arrangement introduit, ainsi que les implications pour l’utilisation des systèmes de développement et de sauvegarde de Kinsta.

Si vous pensez qu’un reverse proxy est la meilleure solution à votre besoin actuel, n’hésitez pas à contacter l’équipe de support de Kinsta via le chat dans MyKinsta pour lancer le processus !

9
Partages