NGINX est un serveur Web et un serveur proxy inverse hautes performances réputé pour sa capacité à gérer des charges de trafic élevées et à servir efficacement du contenu statique. L'une de ses fonctionnalités puissantes est la possibilité de rediriger les URL, une capacité cruciale pour gérer le trafic Web, améliorer le référencement et garantir une expérience utilisateur fluide. La redirection d'URL dans NGINX peut être utilisée à diverses fins, telles que la redirection HTTP vers HTTPS, la création d'alias d'URL ou la gestion des migrations de sites.
Le guide suivant montrera comment rediriger les URL dans NGINX à l'aide du terminal de ligne de commande sur les systèmes Linux ou de type Unix. En configurant les capacités de redirection robustes et flexibles de NGINX, vous pouvez gérer et contrôler efficacement le trafic Web pour répondre à vos besoins spécifiques.
Renvoyer les URL de redirection dans NGINX
NGINX fournit deux directives clés pour configurer la redirection d'URL : return et rewrite. Ces directives sont cruciales pour diriger le trafic Web d’une URL à une autre.
Redirections 301 dans NGINX
La redirection 301 est indispensable pour une redirection permanente. Il est couramment utilisé lorsqu'un site Web ou une page Web a été définitivement déplacé vers une nouvelle URL. Pour mettre en place une redirection 301 dans NGINX, vous utilisez le return directive dans votre bloc serveur, spécifiant un code d'état 301. Cela garantit que les utilisateurs et les moteurs de recherche sont dirigés vers la nouvelle URL.
Exemple de redirection 301
Considérez que vous devez rediriger le trafic depuis oldsite.com à newsite.com. La configuration NGINX ressemblerait à ceci :
server {
listen 80;
server_name oldsite.com;
location / {
return 301 $scheme://www.newsite.com$request_uri;
}
}
Cette configuration redirige efficacement toutes les requêtes entrantes de oldsite.com à www.newsite.com, en conservant l'URI de la demande d'origine. Cette méthode simple mais puissante garantit aux utilisateurs et aux moteurs de recherche de trouver votre nouvel emplacement de site Web.
Redirections 302 dans NGINX
Contrairement à la redirection permanente, une redirection 302 est utilisée pour les scénarios de redirection temporaires. Par exemple, vous pouvez rediriger temporairement les utilisateurs pendant la maintenance du site Web ou lorsqu'une page est temporairement déplacée.
Exemple de redirection 302
Pour illustrer, disons que vous souhaitez rediriger le trafic depuis temp.com à another-site.com temporairement. La configuration NGINX serait :
server {
listen 80;
server_name temp.com;
location / {
return 302 $scheme://www.another-site.com$request_uri;
}
}Dans cette configuration, tout le trafic vers temp.com est temporairement redirigé vers www.another-site.com. L'utilisation d'un code de statut 302 indique que cette redirection est temporaire, ce qui est important pour maintenir l'intégrité du référencement lors de changements à court terme.
Réécrire les URL de redirection de directive dans NGINX
Le rewrite La directive dans NGINX est un outil puissant pour gérer des scénarios de redirection d'URL complexes. Contrairement au simple return directif, rewrite exploite les expressions régulières et un plus large éventail de variables. Cette flexibilité permet un contrôle précis sur la façon dont les URL sont redirigées, en particulier dans les scénarios où une simple redirection est insuffisante.
Redirection basée sur l'extension de fichier
Redirection de types de fichiers spécifiques
Une exigence courante consiste à rediriger des types de fichiers spécifiques. Par exemple, rediriger tout .jpg requêtes d'image vers un nouveau répertoire :
server {
listen 80;
server_name www.example.com;
location ~* \.jpg$ {
rewrite ^/images/(.*)\.jpg$ /new-images/$1.jpg permanent;
}
}Dans cette configuration, toute demande à un .jpg fichier dans le /images/ le répertoire est redirigé vers /new-images/. L'expression régulière \.(jpg)$ garantit que seules les URL se terminant par .jpg sont affectés.
Redirection dynamique basée sur l'URI
Redirection avec manipulation d'URI
Un autre scénario courant implique la redirection dynamique des URL en fonction de leurs composants URI. Pensez à rediriger les utilisateurs en fonction des catégories de produits :
server {
listen 80;
server_name www.example.com;
location ~* ^/category/(.*)$ {
rewrite ^/category/(.*)$ /new-category/$1 permanent;
}
}Cette configuration capture n'importe quelle URL sous /category/ et le redirige vers une URL correspondante sous /new-category/, en conservant la dernière partie de l'URI.
Gestion des structures d'URL héritées
Redirection des anciennes URL vers un nouveau modèle
Les sites Web modifient souvent leur structure d’URL au fil du temps. Le rewrite La directive peut gérer en douceur de telles transitions :
server {
listen 80;
server_name www.example.com;
location ~* ^/old-structure/(.*)$ {
rewrite ^/old-structure/(.*)/info$ /new-structure/$1/details permanent;
}
}
Cet exemple montre comment rediriger les URL à partir d'un ancien modèle (/old-structure/[identifier]/info) à un nouveau modèle (/new-structure/[identifier]/details).
Redirection géographique
Redirection des utilisateurs par emplacement géographique
NGINX peut également gérer la redirection en fonction de l'emplacement géographique, en utilisant le $geoip_country_code variable:
server {
listen 80;
server_name www.example.com;
if ($geoip_country_code = "US") {
rewrite ^/(.*)$ /us/$1 permanent;
}
}Dans cette configuration, les visiteurs en provenance des États-Unis sont redirigés vers une section du site Web spécifique aux États-Unis. Cette approche nécessite que le module GeoIP soit activé dans NGINX.
URL de redirection d'équilibrage de charge dans NGINX
NGINX excelle dans la gestion efficace du trafic réseau grâce à ses capacités d'équilibrage de charge et de redirection. L'équilibrage de charge dans NGINX implique la répartition du trafic entrant sur plusieurs serveurs. Cette stratégie empêche la surcharge d'un serveur unique, améliorant ainsi les performances et la fiabilité globales du système.
Configuration de NGINX pour l'équilibrage de charge
Configuration de l'équilibrage de charge
Équilibrage de charge de base
Voici un exemple de configuration de NGINX pour l'équilibrage de charge :
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}Dans cette configuration, NGINX agit comme un proxy inverse et distribue uniformément les requêtes entrantes à l'un des trois serveurs backend spécifiés : backend1.example.com, backend2.example.com et backend3.example.com. Cette configuration est cruciale pour les sites Web à fort trafic, car elle garantit un traitement efficace des demandes, maintenant ainsi des temps de réponse rapides et minimisant les temps d'arrêt du serveur.
Équilibrage de charge avancé avec contrôles de santé
Pour une fiabilité améliorée, vous pouvez configurer NGINX pour effectuer des vérifications de l'état sur les serveurs backend et envoyer le trafic uniquement vers les serveurs sains :
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
# Enable health checks
health_check;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
Avec cette configuration, NGINX vérifie périodiquement la santé des serveurs backend et exclut tous les serveurs en panne du pool d'équilibrage de charge. Cela garantit que le trafic est dirigé uniquement vers des serveurs capables de traiter les demandes, améliorant ainsi la fiabilité globale.
Meilleures pratiques pour l'équilibrage de charge
Implémentation de la persistance de session (sessions collantes)
Pour les applications qui nécessitent la persistance de session, vous pouvez utiliser des sessions persistantes pour garantir qu'un utilisateur est systématiquement acheminé vers le même serveur back-end :
http {
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}Dans cette configuration, le ip_hash La directive garantit que les requêtes provenant de la même adresse IP client sont toujours acheminées vers le même serveur backend, maintenant ainsi la cohérence des sessions.
Configuration de la terminaison SSL
Pour des communications sécurisées, il est recommandé de mettre fin à SSL au niveau de l'équilibreur de charge :
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
proxy_pass http://backend;
}
}
}Dans cette configuration, NGINX gère la terminaison SSL, déchiffre les requêtes SSL entrantes et les transmet aux serveurs backend en tant que requêtes HTTP normales. Cela décharge le traitement SSL des serveurs backend, améliorant ainsi leurs performances.
Conclusion
Dans ce guide, nous avons exploré les aspects pratiques de l'utilisation de NGINX pour la redirection d'URL, l'équilibrage de charge, etc. Nous avons couvert une gamme de techniques, depuis la configuration de redirections 301 et 302 de base jusqu'à la mise en œuvre de règles de réécriture complexes et de configurations d'équilibrage de charge efficaces. La puissance de NGINX réside dans sa flexibilité et ses performances, ce qui en fait un outil précieux pour gérer n'importe quel site Web, qu'il soit à petite ou à grande échelle. Au fur et à mesure que vous appliquez ces concepts, continuez à expérimenter et à optimiser. NGINX est un outil robuste dans votre arsenal d'administration Web, alors utilisez-le pour assurer le fonctionnement fluide et efficace de votre site.
