Comment configurer un proxy inverse (pas à pas pour Nginx et Apache)

Un proxy inverse (reverse proxy) se trouve devant un serveur web et reçoit toutes les requêtes avant qu’elles n’atteignent le serveur d’origine. Il fonctionne de la même manière qu’un proxy avancé (forward proxy), sauf que dans ce cas, c’est le serveur web qui utilise le proxy plutôt que l’utilisateur ou le client. Les proxy inverses sont généralement utilisés pour améliorer les performances, la sécurité et la fiabilité du serveur web.

Par exemple, vous pouvez avoir un site non-WordPress hébergé sur le domaine exemple.com sur le serveur A et avoir son blog fonctionnant sous WordPress sur l’URL exemple.com/blog hébergé sur le serveur B. Vous pouvez y parvenir en ajoutant un proxy inverse pour le serveur qui héberge votre site principal. Vous pouvez configurer le proxy inverse pour rediriger les requêtes adressées au blog vers un autre serveur (par exemple, l’hébergement WordPress géré par Kinsta).

Dans cet article, vous apprendrez les bases des serveurs de proxy inverse, leur fonctionnement, leurs principaux avantages et comment vous pouvez les utiliser pour accélérer et sécuriser votre site WordPress.

Ça vous excite ? Commençons !

Qu’est-ce qu’un proxy inverse ?

Pour comprendre ce qu’est un serveur proxy inverse, vous devez d’abord connaître son rôle et vous familiariser avec tous les termes qui s’y rapportent.

Lorsque vous naviguez normalement sur le web en saisissant un nom de domaine ou en cliquant sur un lien, votre navigateur/appareil se connecte directement au serveur du site web et commence à télécharger ses ressources.

Si vous souhaitez anonymiser votre adresse IP depuis les sites web que vous visitez, vous pouvez utiliser un serveur proxy pour lui envoyer d’abord toutes vos requêtes. Il transmettra vos requêtes au résolveur DNS, puis téléchargera les ressources du site web à partir de son serveur d’origine.

Ensuite, il transmettra ces ressources à votre appareil. C’est ce que l’on appelle un proxy avancé.

Vous êtes complètement masqué du site web car il pense que votre requête provient du proxy avancé.

Outre l’amélioration de la protection de la vie privée des utilisateurs, un proxy avancé est principalement utilisé pour contourner les restrictions géographiques en matière de contenu. Par exemple, si vous voulez regarder une vidéo qui est bloquée dans votre région, vous pouvez utiliser un proxy avancé avec une adresse IP sur laquelle la vidéo est disponible pour être visionnée.

Un proxy avancé fonctionne presque de la même manière qu’un réseau privé virtuel (VPN), mais il s’agit de technologies distinctes avec des cas d’utilisation uniques (elles peuvent cependant parfois se chevaucher).

Serveur proxy inverse et serveur proxy avancé

Un serveur proxy inverse agit comme une façade pour le serveur d’origine afin de maintenir l’anonymat et de renforcer la sécurité, tout comme un utilisateur/client peut utiliser un proxy avancé pour obtenir la même chose. Il garantit qu’aucun utilisateur ou client ne communique directement avec le serveur d’origine.

La différence entre un proxy avancé et un proxy inverse est mineure, mais ils fonctionnent différemment.

Les deux peuvent travailler ensemble car il n’y a pas de chevauchement dans leur fonctionnement. En général, les utilisateurs/clients utilisent un proxy avancé, tandis que les serveurs d’origine utilisent un proxy inverse.

Comme l’administrateur d’un serveur peut contrôler le fonctionnement du proxy inverse, vous pouvez l’utiliser pour activer de nombreuses fonctions utiles.

Nous listerons tous ses avantages plus loin dans cet article.

Pourquoi utiliser un proxy inverse ?

De nombreuses entreprises, en particulier les grandes entreprises, utilisent des sites web sur mesure qui sont adaptés à leurs besoins particuliers et ne fonctionnent pas sous WordPress. Citons par exemple les sites web des banques et des assurances.

Dans d’autres cas, une entreprise peut héberger son site sur un service externe qui ne lui permet pas d’installer un logiciel externe (par exemple WordPress). Il s’agit généralement de petits et moyens détaillants utilisant une plateforme de commerce électronique telle que Shopify.

Comme WordPress dispose de fonctionnalités CMS robustes, de nombreuses entreprises, y compris les grandes entreprises ayant des sites web sur mesure, peuvent préférer héberger leurs blogs en utilisant WordPress.

Une façon de contourner ce problème est d’installer WordPress sur le sous-domaine du site principal et de structurer les menus de navigation de manière à ce que les utilisateurs puissent passer facilement du site principal au blog.

Comme les sous-domaines se comportent comme un domaine unique, cela peut affecter le référencement de votre site. Même si Google traite les sous-domaines et les sous-répertoires de la même manière, il faut plus d’efforts pour optimiser un site web pour le classement dans les moteurs de recherche s’il est hébergé dans un sous-domaine que s’il est hébergé dans un sous-répertoire.

Google a réaffirmé qu’il traite les sous-domaines et les sous-répertoires de la même manière, mais certains experts en référencement ne sont pas d’accord avec cela. Et même si cela n’affecte pas le référencement du site, un site hébergé dans un sous-répertoire est tout simplement plus facile à maintenir.

C’est pourquoi vous pouvez utiliser un proxy inverse pour rediriger les requêtes vers le blog du site hébergé sur un serveur séparé. Par exemple, une banque peut héberger son site principal sur ses serveurs de manière sécurisée, mais elle peut aussi héberger son blog WordPress séparément sur un hébergeur WordPress géré comme Kinsta.

L’un des principaux avantages de l’utilisation d’un proxy inverse est de réunir deux sites différents sous un seul nom de domaine. Cela aide les marques à maintenir leurs sites organisés, professionnels et crédibles.

Avantages de l’utilisation d’un proxy inverse

Outre le cas d’utilisation susmentionné, le proxy inverse confère également de nombreux autres avantages. La section ci-dessous présente certains de leurs principaux avantages.

Équilibrage de charge

Un serveur d’origine unique ne peut pas gérer tout le trafic entrant pour un site web qui compte des millions de visiteurs uniques par jour. Dans ce cas, vous pouvez répartir le trafic de manière intelligente entre un ensemble de plusieurs serveurs. En général, tous les serveurs hébergent le même contenu afin d’éliminer un point de défaillance, ce qui rend le site web plus fiable.

Un proxy inverse est un excellent moyen configurer ceci car il peut recevoir le trafic entrant avant qu’il n’atteigne le serveur d’origine. Si le serveur d’origine est surchargé ou tombe complètement en panne, il peut distribuer le trafic à d’autres serveurs sans affecter la fonctionnalité du site.

Le proxy inverse peut également diriger les requêtes entrantes vers plusieurs serveurs, chaque serveur remplissant une fonction spécifique pour laquelle il est optimisé. Le proxy inverse peut alors recueillir les réponses de tous les serveurs et les transmettre au client.

Comme nous utilisons la plupart des proxy inversé populaires principalement pour l’équilibrage de charge, ils sont également appelés répartiteurs de charge (load balancers).

Répartiteurs de charge globale des serveurs (Global Server Load ou GSLB)

GSLB est une méthode avancée d’équilibrage de la charge pour répartir le trafic d’un site web entre de nombreux serveurs placés stratégiquement dans le monde entier. Elle est généralement réalisée par une technique de routage anycast, où le proxy inverse choisit le nœud du serveur en fonction du temps de parcours le plus rapide entre le client et le serveur.

Non seulement GSLB augmente considérablement la fiabilité et la sécurité du site, mais elle réduit également les temps de latence et de chargement, améliorant ainsi l’expérience de l’utilisateur. Vous pouvez utiliser GSLB avec d’autres techniques d’optimisation du réseau telles que le Spoon Feeding pour libérer encore plus les ressources de calcul des serveurs d’origine.

Bien que vous puissiez configurer manuellement l’équilibrage global de la charge du serveur sur votre serveur, il est généralement assuré par des CDN dédiés tels que Cloudflare et KeyCDN (qui alimente également Kinsta CDN). Kinsta dessert tous les sites webs hébergés par son intermédiaire grâce à un équilibreur de charge alimenté par la plateforme Google Cloud.

Sécurité renforcée

Le proxy inverse peuvent masquer l’adresse IP et d’autres caractéristiques des serveurs d’origine. Ainsi, le serveur d’origine de votre site web peut mieux préserver son anonymat, ce qui augmente considérablement sa sécurité.

Étant donné que le proxy inverse recevra tout le trafic avant qu’il n’atteigne le serveur principal, tout attaquant ou hacker aura plus de mal à cibler votre site web avec des menaces de sécurité telles que les attaques DDoS.

Vous pouvez utiliser un pare-feu strict pour renforcer le proxy inverse avec une sécurité renforcée contre les cyber-attaques courantes. Sans l’installation d’un proxy inverse, il est difficile de supprimer les logiciels malveillants ou de lancer des attaques.

Un proxy inverse comme HAProxy peut ajouter une authentification de base d’accès HTTP à un serveur web qui ne l’a pas activée. Vous pouvez également utiliser un proxy inverse pour ajouter une authentification centralisée pour différents types de requêtes.

Une mise en cache puissante

Vous pouvez utiliser un proxy inverse à des fins d’accélération du web en mettant en cache à la fois le contenu statique et dynamique. Cela peut réduire la charge sur le serveur d’origine, ce qui se traduit par un site web plus rapide.

Par exemple, si votre serveur d’origine est aux États-Unis et qu’un utilisateur d’Europe visite votre site web, vous pouvez alors servir une version en cache de votre site à partir d’un serveur proxy inverse en Europe. Comme le serveur proxy inverse est plus proche de l’utilisateur que le serveur d’origine, le site web prendra moins de temps à charger, ce qui le rendra plus performant.

Varnish et Nginx FastCGI sont des exemples éminents de proxy inverse qui sont utilisés pour la mise en cache de contenu web.

Si votre site est hébergé par Kinsta, vous n’avez pas à vous soucier de la mise en cache car Kinsta se charge de toute la procédure de mise en cache pour vous (y compris en offrant des fonctionnalités avancées comme le cache edge).

Compression supérieure

Les réponses des serveurs consomment beaucoup de bande passante. Comprimer les réponses du serveur (par exemple avec gzip) avant de les envoyer au client peut réduire la quantité de bande passante nécessaire, ce qui accélère les réponses du serveur sur le réseau.

Un proxy inverse est idéal pour compresser les réponses des serveurs car il se situe entre les serveurs d’origine et le client.

Cryptage SSL optimisé

Le cryptage et le décryptage des requêtes SSL/TLS pour chaque client peuvent être très éprouvants pour le serveur d’origine. Un proxy inverse peut prendre en charge cette tâche afin de libérer les ressources du serveur d’origine pour d’autres tâches importantes, comme la diffusion de contenu.

Un autre avantage du délestage du cryptage et du décryptage SSL/TSL est de réduire la latence pour les clients qui sont géographiquement éloignés du serveur d’origine.

Vous pouvez également opter pour un proxy inverse avec un matériel d’accélération SSL/TLS spécialisé pour optimiser encore plus cette tâche. Un tel proxy inverse est appelé proxy de terminaison SSL/TLS. Certains serveurs comme Varnish ne prennent pas en charge les protocoles SSL/TSL. Un proxy inverse de terminaison SSL/TSL peut donc contribuer à sécuriser le trafic qui y transite.

Meilleur test A/B

La plupart des outils de test A/B nécessitent l’utilisation de bibliothèques JavaScript externes pour charger leurs fonctions. Cependant, le chargement de scripts tiers peut ralentir le temps de chargement de votre page et créer une expérience difficile pour les utilisateurs.

Au lieu de cela, vous pouvez utiliser un proxy inverse pour créer deux flux séparés au niveau du serveur lui-même. Par exemple, vous pouvez utiliser les méthodes split_clients ou sticky route de Nginx pour contrôler la redirection du trafic.

Vous pouvez vous référer aux tutoriels sur Nginx et freeCodeCamp pour en savoir plus sur la réalisation de tests A/B avec un proxy inverse.

Surveillance et journalisation du trafic

Un proxy inverse saisit toutes les requêtes qui passent par lui. Vous pouvez donc les utiliser comme un hub central pour surveiller et journaliser le trafic. Même si vous utilisez plusieurs serveurs web pour héberger tous les éléments de votre site, l’utilisation d’un proxy inverse facilitera la surveillance de toutes les données entrantes et sortantes de votre site.

Les services de proxy inverse les plus populaires

Selon le W3Techs, près de 83 % des sites web n’utilisent aucun service de proxy inverse qu’ils surveillent.

Sur les 17 % de sites web qui utilisent un proxy inverse (listés ci-dessus), vous remarquerez que la plupart sont des CDN. En effet, la plupart des serveurs de proxy inverse cachent leur existence par défaut par mesure de sécurité. Vous ne pouvez donc pas vous fier à des services de surveillance de sites web comme W3Techs pour savoir ce qu’est un proxy inverse les plus populaires.

D’après nos recherches et notre expérience, les serveurs de proxy inverse les plus populaires utilisés aujourd’hui sont :

Nginx

Nginx est un serveur web open source qui peut également servir de proxy inverse. Outre son utilisation pour l’hébergement de sites web, c’est aussi l’une des solutions de rproxy inverse et d’équilibrage de charge les plus utilisées. Selon Netcraft, plus de 479 millions de serveurs web utilisaient Nginx en décembre 2019, ce qui en fait le leader du marché des serveurs web.

Nginx offre tous les avantages de l’inversion de proxy inverse évoqués ci-dessus, et bien d’autres encore. Il améliore les performances, la sécurité, la fiabilité et l’évolutivité du web. Vous pouvez configurer Nginx en utilisant son fichier de configuration, qui est également rechargeable à chaud. Chez Kinsta, le proxy inverse de Nginx est l’un des nombreux modules premium que vous pouvez utiliser.

Mais vous pouvez également utiliser Nginx Plus, une offre commerciale, pour avoir accès à des options de configuration basées sur l’API et à d’autres fonctionnalités adaptées aux sites web des grandes entreprises.

Kinsta alimente tous ses sites web avec Nginx. Elle s’est classée dans le Top Tier des hébergements web de Review Signal dans toutes les catégories auxquelles elle a participé. Parmi les autres grandes entreprises qui utilisent Nginx, citons MaxCDN, Cloudflare et Netflix.

La mise en place de Nginx comme proxy inverse de base est simple. Nginx vous fournit également diverses directives pour personnaliser le proxy inverse de votre serveur en fonction de vos besoins. Nous discuterons de la manière de procéder dans une section ultérieure. Si vous êtes un client de Kinsta, vous apprendrez également comment utiliser un proxy inverse pour les sites web hébergés par Kinsta dans la même section.

Varnish

Varnish est un proxy inverse HTTP open source avec un moteur de cache intégré. Il est conçu principalement pour les sites web à fort trafic qui servent du contenu dynamique. Vous pouvez également utiliser Varnish comme un équilibreur de charge, un pare-feu d’application web (Web App Firewall ou WAF) et un serveur d’authentification et d’autorisation.

Il fonctionne sur toutes les versions modernes de Linux et FreeBSD, étant principalement utilisé comme façade pour les serveurs web Nginx ou Apache. Le puissant et très flexible Varnish Configuration Language (VCL) vous permet de définir diverses fonctionnalités telles que la gestion des requêtes HTTP, la mise en cache et la connexion à un ou plusieurs serveurs web.

C’est pourquoi de nombreux CDN utilisent Varnish comme base principale pour la livraison rapide de contenu.

Varnish supporte également les Edge Side Includes (ESI), un langage qui vous aide à réutiliser des sections d’une page web dans d’autres pages web. Si votre site web utilise beaucoup de contenu répété dans différentes pages, l’ESI peut vous aider à accélérer le temps de chargement des pages de votre site en mettant en cache les sections fréquemment utilisées.

Vous pouvez étendre Varnish avec ses différents modules (VMOD). Rendez-vous sur le tutoriel officiel de Varnish pour apprendre comment configurer Varnish comme proxy inverse pour WordPress.

Apache Traffic Server

Apache Traffic Server est un serveur proxy de mise en cache open source. Il est populaire pour ses fonctionnalités rapides et évolutives. C’est un produit commercial développé par Yahoo ! il y a longtemps, mais ils l’ont rendu open source et en ont fait don à la Fondation Apache pour la maintenance.

Plusieurs grands réseaux de contenu et CDN comme Comcast, Akamai, LinkedIn, Yahoo et Apple utilisent Apache Traffic Server pour propulser leur technologie.

Vous pouvez également utiliser le serveur HTTP Apache (Apache httpd), un démon du serveur HTTP, pour mettre en place un proxy inverse sur votre serveur web. En plus d’agir comme un serveur web de base, il vous aide à servir du contenu statique et dynamique aux utilisateurs. Vous apprendrez plus loin dans cet article comment configurer Apache en tant que proxy inverse.

HAProxy

HAProxy est un proxy inverse et un équilibreur de charge open source. Il est conçu pour s’intégrer à la plupart des architectures de serveurs web existantes, y compris les distributions Linux et les platesformes de cloud. Comme Nginx, HAProxy utilise un modèle d’entrée/sortie piloté par les événements et prend en charge le fractionnement des requêtes entre plusieurs processus de travail.

Pour les requêtes HTTP, HAProxy se comporte exceptionnellement bien, même sous de lourdes charges. Certains des sites web les plus fréquentés sur Internet, tels que Airbnb, Reddit, Instagram, Stack Overflow, Tumblr, GitHub et Imgur, utilisent HAProxy pour diffuser efficacement leurs sites web.

Discuter de la façon de mettre en œuvre HAProxy dépasse le cadre de cet article, mais vous pouvez vous référer à leur documentation pour comprendre son fonctionnement.

Note : Traefik et Envoy sont deux autres alternatives open source à HAProxy. Ils sont tous deux très performants et des équilibreurs de charge avec de nombreuses fonctionnalités avancées.

Parmi les autres populaires, citons AWS Elastic Load Balancer, GLBC, DigitalOcean Load Balancer et Google Cloud Load Balancer. Pour une liste exhaustive des principaux serveurs de proxy inverse et équilibreurs de charge utilisés aujourd’hui, vous pouvez consulter le site Stackshare.io.

Proxy inverse : Cas d’utilisation pour les sites WordPress

Il existe principalement trois cas d’utilisation d’un proxy inverse pour les sites WordPress, y compris les sites hébergés chez Kinsta.

Nous n’utiliserons Nginx que pour cet exemple, car c’est le proxy inverse le plus utilisé aujourd’hui pour les sites WordPress. Mais les mêmes principes de base s’appliqueront aux autres serveurs de proxy inverse.

Les serveurs de proxy inverse sont souvent difficiles à installer, à configurer et à prendre en charge. C’est pourquoi Kinsta propose un abonnement mensuel de 50 $ pour chaque proxy inverse dont vous avez besoin d’aide pour le configurer. Vous pouvez contacter l‘équipe d’assistance de Kinsta pour plus de détails.

1. Sites principaux et sites avec proxy hébergés sur le même serveur

Si le site principal et le site avec proxy sont tous deux hébergés sur le même serveur, le site principal peut fonctionner sur une installation WordPress, tandis qu’une installation WordPress séparée alimente le site avec proxy.

Comme vous aurez accès aux deux sites et à leur serveur web partagé, vous pouvez configurer les règles de proxy inverse pour le site principal, puis configurer le site avec proxy pour qu’il se charge à partir du proxy inverse.

Si vous hébergez ces deux sites chez Kinsta, vous pouvez contacter l’équipe de soutien de Kinsta et lui demander de mettre en place le proxy inverse pour vous. Voici la procédure que vous devez suivre :

• Assurez-vous que le site principal et le site avec proxy sont hébergés chez Kinsta. Si ce n’est pas le cas, vous pouvez migrer les deux sites vers l’environnement de Kinsta, soit manuellement, soit en soumettant une demande de migration.
• Ouvrez un ticket d’assistance et fournissez à l’équipe d’assistance de Kinsta une description claire de la configuration du domaine. Il faudra environ un jour ouvrable pour mettre en place le proxy inverse.
• Kinsta mettra en place les règles de proxy inverses pertinentes sur le site principal et configurera le site avec proxy pour charger le proxy inverse.

Voici les directives standard de Nginx utilisées par Kinsta pour charger un site de sous-répertoire par le biais d’un proxy inverse :

location ^~ /subfolder/ {
proxy_pass http://subfolder.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;
}

Dans le code ci-dessus, vous devez remplacer /subfolder/ par le nom du sous-répertoire (par exemple /blog/, /shop/). De plus, le sous-domaine http://subfolder.domain.com doit correspondre à l’URL utilisée pour faire pointer le proxy inverse vers le site avec proxy.

La directive location comprend les symboles circonflexe et tilde (^~) pour indiquer à Nginx que s’il trouve la chaîne définie, il doit arrêter de chercher d’autres correspondances et utiliser les directives listées ici. Pour en savoir plus sur les directives de proxy inverse de Nginx, consultez sa documentation.

Ensuite, vous devez configurer le site proxy pour qu’il se charge par-dessus le proxy inverse. Voici les étapes standard suivies par Kinsta pour configurer le site proxy :

• Créez un sous-répertoire au niveau du chemin d’accès à partir duquel le site proxy est chargé. Tous les fichiers du site web proxy sont déplacés dans ce sous-répertoire.
• Mettez à jour les fichiers de configuration du serveur web pour définir le nouveau sous-répertoire comme répertoire racine du site proxy. En outre, vous devez ajouter une règle de réécriture pour supprimer le sous-répertoire de l’URI de la requête pour chaque requête entrante.
• Mettez à jour toutes les URLs de la base de données du site proxy pour qu’elles correspondent aux URLs du site principal (par exemple, example.com/blog).
• Modifiez le fichier wp-config.php du site proxy avec la définition $_SERVER['HTTP_HOST'], en le faisant pointer vers l’URL du site principal.
• Si vous utilisez un certificat SSL, vous devez définir des règles strictes dans le fichier wp-config.php pour éviter les boucles de redirection.

Remarque : un site proxy ne peut pas créer d’URL qui dupliquent le même sous-répertoire que celui sous lequel le site proxy se charge. Par exemple, un site proxy sur example.com/blog ne peut pas créer une page ou un répertoire sur example.com/blog/blog.

2. Uniquement le site proxy hébergé sur votre serveur

Si vous n’avez accès qu’au site proxy et à son serveur web, vous devez alors contacter l’administrateur du serveur du site principal et lui demander de mettre en place les règles de proxy inverse pour vous.

Pour ce faire, vous devez suivre les mêmes étapes que celles décrites ci-dessus, sauf que dans ce cas, vous devez configurer les règles sur deux serveurs différents.

Pour héberger votre site proxy avec Kinsta, ajoutez un domaine au site qui pointera vers le proxy inverse. Habituellement, un sous-domaine convient à cette fin (par exemple blog.exemple.com) pour charger le site proxy sur un lien de sous-répertoire (par exemple exemple.com/blog).

Après avoir configuré votre site proxy sur Kinsta, vous pouvez contacter le support de Kinsta pour configurer le site proxy afin de le charger via un proxy inverse. À ce moment, notre équipe de support aura besoin de l’adresse IP réelle de votre serveur afin de terminer le processus de configuration de manière à compter correctement les visites. Si vous ne pouvez pas fournir une IP statique en raison de restrictions d’IP dynamique de certains fournisseurs (par exemple AWS CloudFront), votre plan sera converti en un plan comparable basé sur la bande passante.

3. Uniquement le site principal hébergé sur votre serveur

Si vous n’avez accès qu’au site principal et à son serveur web, vous devez alors configurer le proxy inverse et ses règles pour charger le site proxy à partir d’un hôte externe. L’installation et la configuration du site proxy pour le charger par le biais du proxy inverse est la responsabilité de l’administrateur du serveur secondaire.

Le fait que votre site principal soit hébergé chez Kinsta vous donnera accès à l‘équipe de soutien de Kinsta. Vous pouvez leur demander d’ajouter les règles standard de proxy inverse énumérées plus haut dans cet article. Vous pouvez également faire ajouter toute personnalisation supplémentaire à ces règles si nécessaire.

Dans ce scénario, vous êtes entièrement responsable de la configuration du site proxy pour le charger correctement via le proxy inverse.

Comment configurer Nginx en tant que proxy inverse ?

Si Kinsta n’héberge pas votre site web et que vous gérez vos serveurs, vous devez alors configurer vous-même le proxy inverse et le faire pointer vers le site proxy.

Selon le système d’exploitation de votre serveur web, vous pouvez installer Nginx différemment. Pour les distributions Linux, vous pouvez utiliser différents paquets Nginx en fonction de la version de votre distribution Linux.

Dans l’exemple ci-dessous, nous avons installé le site principal au nom de domaine exaple.com, tandis que le site WordPress proxy est installé sur le sous-domaine blog.domain.com. Ils sont tous deux propulsés par Apache sur un serveur web fonctionnant sous Ubuntu 18.04. Nous allons installer et configurer Nginx comme proxy inverse sur le serveur principal.

1. Installer Nginx

Pour commencer, accédez au terminal de votre serveur via SSH. Ensuite, utilisez la commande apt-get pour mettre à jour la liste des paquets de votre distribution et installer Nginx sur votre serveur web.

sudo apt update
sudo apt install nginx

2. Configurer Nginx pour qu’il transmette les requêtes par proxy

Ensuite, vous devez configurer Nginx pour les requêtes de proxy pour les domaines hébergés sur Apache. Pour ce faire, créez un nouveau fichier d’hôte virtuel. Ici, j’utilise l’éditeur nano pour ajouter le code, mais vous pouvez utiliser n’importe quel éditeur de code de votre choix.

sudo nano /etc/nginx/sites-available/example.com.conf

Ensuite, définissez les directives Nginx pour transmettre les requêtes à Apache en ajoutant les blocs server {...} et location suivants :

server {
listen      80;
server_name example.com www.example.com;
index       index.php;
root        /var/www/example.com/public    # fallback for index.php
location / {
try_files $uri $uri/ /index.php?$query_string;
}location /blog {
proxy_pass http://blog.domain.com;proxy_http_version                 1.1;
proxy_cache_bypass                 $http_upgrade;

# Proxy headers
proxy_set_header Upgrade           $http_upgrade;
proxy_set_header Connection        "upgrade";
proxy_set_header Host              $host;
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;
proxy_set_header X-Forwarded-Host  $host;
proxy_set_header X-Forwarded-Port  $server_port;

# Proxy timeouts
proxy_connect_timeout              60s;
proxy_send_timeout                 60s;
proxy_read_timeout                 60s;
}

Dans le code ci-dessus, je définis un lien du sous-répertoire example.com/blog qui sera servi par le serveur Apache. Assurez-vous d’utiliser l’adresse IP (ou URL) publique de votre site web proxy dans la directive proxy_pass. Dans mon cas, mon site web proxy est hébergé dans le sous-domaine blog.domain.com.

Note : Assurez-vous que le site web proxy est installé et prêt à être servi avant de faire des changements.

Vous pouvez en savoir plus sur toutes les directives de proxy inverse utilisées ici dans l’index détaillé des directives de Nginx.

3. Enregistrer le fichier de l’hébergeur virtuel créé

Activez ensuite le nouvel hôte virtuel en créant un lien symbolique pour les fichiers nommés example.com.conf dans les répertoires /etc/nginx/sites-available et /etc/nginx/sites-enabled.

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf

4. Tester les erreurs de Nginx

Ensuite, testez Nginx pour détecter toute erreur de configuration.

sudo nginx -t

S’il n’y a pas d’erreurs, rechargez Nginx pour appliquer les changements.

sudo systemctl reload nginx

Vous avez réussi à faire fonctionner Nginx en tant que proxy inverse. Pour le confirmer, vous pouvez utiliser la fonction phpinfo() pour vérifier les variables PHP chargées lorsque vous visitez votre site proxy.

Sous les variables PHP SERVER_SOFTWARE et DOCUMENT_ROOT, vous verrez qu’Apache sert ce domaine en arrière-plan. Mais les variables PHP HTTP_X_REAL_IP et HTTP_X_FORWARDED_FOR confirment que Nginx a été utilisé comme proxy inverse pour transmettre les requêtes.

Vous pouvez accélérer le service de votre site WordPress sur Nginx en utilisant les modules fastcgi_cache et ngx_cache_purge. Alors que le premier module met votre site en cache, le second module purge automatiquement le cache en fonction d’événements spécifiques (par exemple, la publication ou la modification d’un article/page WordPress).

Vous pouvez utiliser l’extension WordPress Nginx Cache Controller pour contrôler le cache du serveur proxy de Nginx directement depuis votre tableau de bord d’administration WordPress. Si vous utilisez une installation WordPress multisite, vous pouvez utiliser l’extension Nginx Helper pour faire la même chose.

Consultez la documentation principale de Nginx et le guide de configuration de Nginx WordPress pour un aperçu détaillé de la façon de travailler avec Nginx et WordPress.

Comment configurer Apache en tant que proxy inverse ?

Avant de commencer, assurez-vous que vous avez deux sites web en fonctionnement, à savoir example.com et blog.domain.com. Le premier site web peut être ou non un site WordPress, mais le second doit être un site WordPress car il sert principalement à charger le blog du domaine racine à l’adresse example.com/blog, lien du sous-répertoire.

1. Commencer à configurer Apache

Vous pouvez le faire en ouvrant le terminal de votre serveur via SSH et en activant le module proxy d’Apache.

sudo a2enmod proxy proxy_http ssl

L’exécution de la commande ci-dessus relancera très probablement Apache pour recharger les directives nouvellement définies.

2. Créer un proxy inverse

Ensuite, modifiez le fichier des hôtes virtuels de votre serveur principal pour créer un proxy inverse. Voici le code que vous devez ajouter :

<VirtualHost *>
DocumentRoot /var/www/app/public
SSLProxyEngine On    ProxyRequests off
ProxyPass /blog http://blog.domain.com
ProxyPassReverse /blog  http://blog.domain.com
</VirtualHost>

La directive ProxyPass créera un proxy inverse pour les chemins spécifiés, tandis que la directive ProxyPassReverse interceptera les en-têtes de réponse HTTP envoyés par ce proxy inverse et les réécrira pour qu’ils correspondent au serveur Apache.

3. Modifier votre fichier wp-config.php

Après avoir enregistré le fichier, vous devez modifier votre fichier wp-config.php en ajoutant le code suivant juste avant la ligne qui vous demande d’arrêter les modifications.

# ProxyPass Settings
# overrides the variables below to ensure that any
# request to /blog/* subdirectory is taken care of properly
$_SERVER['REQUEST_URI'] = '/blog' . $_SERVER['REQUEST_URI'];
$_SERVER['SCRIPT_NAME'] = '/blog' . $_SERVER['SCRIPT_NAME'];
$_SERVER['PHP_SELF'] = '/blog' . $_SERVER['PHP_SELF'];

4. Mettre à jour la base de données de votre site WordPress

Enfin, vous devez mettre à jour la base de données de votre site WordPress pour ajouter les valeurs de configuration du lien du sous-répertoire /blog. Vous pouvez le faire en exécutant la requête SQL suivante :

UPDATE wp_options SET option_value = 'https://www.example.com/blog' WHERE option_name IN( 'siteurl', 'home' );

Vous devriez maintenant pouvoir visiter l’URL https://www.example.com/blog et faire héberger votre site WordPress à l’adresse http://blog.domain.com chargement du sous-domaine sans changer son URL. Vous pouvez continuer à utiliser WordPress comme d’habitude pour naviguer, écrire, modifier et gérer votre site.

Quelles sont les limites d’un proxy inverse ?

• Un proxy inverse pose un risque de sécurité important car il peut lire et modifier tout le trafic qui le traverse. Si vous faites passer du trafic HTTPS par le serveur proxy inverse, celui-ci doit décrypter et re-crypter les données qui passent. Cela signifie qu’il doit posséder les clés privées du certificat SSL/TLS. Ainsi, si une partie malveillante peut compromettre votre proxy inverse, elle peut enregistrer des mots de passe et injecter des logiciels malveillants dans vos sites web.
• Si vous ou vos utilisateurs ne pouvez pas accéder directement à votre serveur principal, l’utilisation d’un proxy inverse peut conduire à un point de défaillance. Par exemple, si vous utilisez un proxy inverse comme façade pour desservir plusieurs domaines, sa panne peut entraîner la mise hors ligne simultanée de tous les domaines.
• Si vous faites appel à un mandataire tiers (par exemple Cloudflare), vous lui transmettez les informations sensibles de votre site. Bien qu’on leur fasse confiance, vous ne pouvez pas prévoir ce qui peut en résulter.
• La restauration des sauvegardes ou le fait de pousser les sites de staging en production sur les sites web qui se chargent par un proxy inverse peut entraîner l’arrêt du chargement correct du site proxy.

Choisir entre un CDN et un proxy inverse

Les CDN sont une forme avancée de proxy inverse, la plupart des configurations et de la maintenance étant prises en charge par un tiers. Ils peuvent fournir des performances étonnantes à votre site WordPress avec un effort mineur de votre part.

Non seulement les CDN mettent le contenu en cache et le diffusent rapidement aux utilisateurs, mais ils réduisent également la charge sur vos serveurs d’origine, diminuent les coûts de la bande passante, fournissent une couche de sécurité supplémentaire, renforcent le référencement de votre site et vous aident à mieux dimensionner votre site web.

Vous remarquerez que la plupart des prestations fournies par les CDN sont les mêmes que celles fournies par les serveurs de proxy inverse. Alors, faut-il choisir un CDN plutôt qu’un proxy inverse, ou vice versa ?

Il n’y a pas de raison de devoir vous contenter d’un seul. Si vous avez déjà installé un proxy inverse, vous constaterez tout de même des gains de vitesse et de performance grâce à l’utilisation d’un CDN. Les deux caches se superposent bien, et si vous avez des besoins particuliers en matière de traitement des requêtes (par exemple, contenu dynamique, commerce électronique), vous pouvez facilement le configurer avec des en-têtes personnalisés transmis par le CDN ou le proxy inverse.

Proxy inverse -FAQ

Voici quelques questions supplémentaires fréquemment posées qui peuvent vous aider à comprendre tout ce qui concerne un proxy inverse.

Quel est l’objectif d’un proxy inverse ?

Masquer l’emplacement d’un site externe, pour donner l’impression qu’il fait partie du domaine principal. Par exemple, une université peut avoir une section de connexion pour les étudiants afin qu’ils puissent vérifier leurs notes. Au lieu d’héberger cette section dans WordPress, elle dispose probablement d’un serveur situé sur son campus, qui utilise un logiciel de notation. Au lieu de dire aux étudiants d’aller sur https://123.123.123.123/~students/gradeing_software/some/long/url/, ils peuvent simplement utiliser un proxy inverse pour que les étudiants puissent aller sur https://university.edu/grades et qu’il semble faire partie du site principal quand en fait il est hébergé sur une autre plateforme.

Le CDN est-il un proxy inverse ?

Non, un CDN est un réseau de diffusion de contenu qui permet d’accélérer la diffusion des parties du site web depuis un endroit plus proche de l’endroit où se trouve le visiteur.

Un équilibreur de charge est-il un proxy inverse ?

Non, un équilibreur de charge permet de répartir le trafic. Par exemple, un site très fréquenté peut disposer d’un équilibreur de charge qui répartit le trafic sur plusieurs serveurs web. Les serveurs web disposent tous d’un miroir des mêmes fichiers de site, mais cela permet au site de gérer plus de trafic que d’habitude, car l’équilibreur de charge répartit le trafic entrant sur chaque serveur web, de sorte qu’aucun serveur web n’ait à gérer TOUT le trafic entrant à la fois. Ainsi, si un serveur web est configuré pour gérer 10.000 visites par minute et que vous disposez de deux serveurs web derrière un équilibreur de charge, le site devrait théoriquement pouvoir gérer 20.000 visites par minute.

Une passerelle API est-elle un proxy inverse ?

Non, une API permet simplement à quelqu’un d’utiliser des commandes sur une plateforme sans avoir besoin de se connecter à une interface utilisateur pour gérer un site. Avec l’API, un client pourrait publier un nouvel article de blog sur son site WordPress sans avoir à se connecter au tableau de bord de WordPress.

Ai-je besoin d’un proxy inverse ?

C’est une question qui se pose au cas par cas. Tout le monde n’a pas besoin d’un proxy inverse, mais dans le cas de l’université mentionnée ci-dessus, cela se justifie. Il peut également y avoir d’autres raisons, comme Ford/Chevy/etc. Ils peuvent avoir une section « Construisez votre voiture » sur leur site, qui ne fait pas partie du site principal, mais une plateforme de construction/personnalisation de voitures qu’ils veulent avoir comme partie du site principal, comme https://ford.com/buildmycar au lieu de https://carbuildingplatform.com/ford/build/customcar/.

Résumé

WordPress est très flexible. Vous pouvez l’utiliser comme un blog, un site de commerce électronique ou même un système de gestion l’apprentissage. Dans la plupart des cas, vous pouvez personnaliser WordPress pour l’adapter à vos besoins particuliers.

Cependant, il arrive que vous deviez utiliser un domaine distinct ou un serveur secondaire pour héberger un site supplémentaire. Comme nous l’avons vu précédemment, cela peut être dû à l’utilisation de différentes piles technologiques pour un site de grande entreprise ou au lancement d’un blog WordPress pour un site préexistant non-WordPress.

Un proxy inverse peut vous aider dans ces deux cas, en vous permettant de tirer le meilleur parti de WordPress sans devoir abandonner le site principal et recommencer à zéro.