Comment créer une redirection NGINX temporaire ou permanente

Une redirection NGINX est une configuration qui achemine le trafic web d’une URL vers une autre, afin que les visiteurs et les moteurs de recherche puissent arriver à la bonne destination. Les redirections sont importantes pour maintenir le classement SEO, éviter les doublons de contenu et améliorer l’expérience utilisateur.

NGINX prend en charge deux types de redirections : les redirections permanentes (HTTP 301), qui indiquent des changements d’URL permanents, et les redirections temporaires (HTTP 302), qui sont utilisées pour des redirections à court terme.

Dans cet article, nous vous guiderons dans la configuration de redirections temporaires et permanentes dans NGINX. Vous apprendrez à utiliser des directives telles que return, rewrite et try_files, à explorer des cas d’utilisation courants et à mettre en œuvre les meilleures pratiques pour éviter des problèmes tels que les boucles de redirection.

À la fin, vous serez en mesure d’affiner la configuration de votre site web pour une meilleure gestion du trafic.

Conditions préalables à la création de redirections NGINX

Avant de configurer des redirections d’URL dans NGINX, assurez-vous que votre serveur répond aux exigences suivantes :

• Autorisations pour modifier les configurations du serveur : vous devez disposer de privilèges administratifs ou sudo pour accéder aux fichiers de configuration NGINX et les modifier. Si vous utilisez un plan de serveur privé virtuel (VPS) de Hostinger, ne vous inquiétez pas : nous vous accordons un accès root complet pour modifier votre serveur selon vos besoins.
• NGINX installé – vérifiez que NGINX est installé et fonctionne sur votre serveur. Utilisez la commande sudo systemctl status nginx pour confirmer son statut. Si NGINX n’est pas présent, installez-le avec :

sudo apt update
sudo apt install nginx

• Accès au fichier de configuration – localisez le fichier de configuration principal de NGINX, qui se trouve généralement dans le répertoire /etc/nginx/nginx.conf. Pour les sites individuels, vous trouverez les fichiers de configuration dans /etc/nginx/sites-available/.
• Compréhension de base de la syntaxe NGINX – familiarisez-vous avec la structure de base des directives et variables NGINX, notamment :
  • server – définit un bloc de serveur qui gère les requêtes entrantes pour un nom de domaine ou une adresse IP spécifique.
  • location – spécifie les configurations pour des URI ou des chemins d’accès à des fichiers spécifiques.
  • $request_uri – capture l’URI d’origine complet à partir de la requête du client.
  • $host – fait référence au nom d’hôte ou au nom de domaine demandé.
  • $query_string – représente tous les paramètres de requête dans l’URL.
• Configuration du nom de domaine et du DNS – assurez-vous que votre nom de domaine pointe vers l’adresse IP correcte du serveur à l’aide d’enregistrements DNS précis.
• Sauvegardes des fichiers de configuration – sauvegardez toujours vos fichiers de configuration existants afin d’éviter toute perte de données en cas d’erreur. Utilisez la commande suivante :

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

Mise en place des redirections NGINX

Pour configurer les redirections NGINX, vous utiliserez trois directives clés : return, rewrite et try_files. Chacune d’entre elles a un objectif spécifique pour une redirection URL efficace.

Utilisation de la directive return

La directive return est le moyen le plus simple et le plus efficace de créer des redirections. Elle est idéale pour des scénarios tels que la redirection d’une URL ou d’un nom de domaine entier. Cette directive traite également les redirections plus rapidement, car elle évite toute complexité inutile.

return arrête immédiatement le traitement des instructions suivantes et envoie le code d’état HTTP spécifié et l’URL de destination au client. Sa syntaxe de base est la suivante :

return [status code] [URL];

• [status code] – Spécifiez 301 pour les redirections permanentes ou 302 pour les redirections temporaires.
• [URL] – Définissez l’URL cible, y compris les variables NGINX correspondantes telles que $request_uri ou $host.

Par exemple, pour rediriger d’un ancien nom de domaine vers un nouveau :

server {
listen 80;
server_name www.old-domain.tld;
return 301 https://www.new-domain.tld$request_uri;
}

• 301 redirige de manière permanente les visiteurs de www.old-domain.tld vers https://www.new-domain.tld.
• $request_uri conserve le chemin d’accès et la chaîne de requête d’origine.

Vous pouvez également utiliser return pour rediriger une seule page comme ceci :

location /old-page {
return 301 /new-page;
}

• 301 redirige les utilisateurs accédant à /old-page vers /new-page au sein du même nom de domaine.

Utilisation de la directive rewrite

La directive rewrite vous permet d’effectuer des redirections plus complexes à l’aide d’expressions régulières (regex), qui correspondent à des modèles dans l’URL d’origine et les transforment en nouvelles URL.

Elle est particulièrement utile lorsque la directive return ne suffit pas, par exemple pour rediriger dynamiquement des URL en fonction de modèles ou de conditions spécifiques. Bien que la directive rewrite soit puissante, une utilisation inappropriée peut entraîner des problèmes tels que des boucles de redirection. Il convient donc de l’utiliser avec précaution.

Voici sa syntaxe de base :

rewrite regex replacement [flag];

• regex – définit le modèle correspondant à l’URL d’origine.
• replacement – spécifie l’URL ou le chemin cible.
• flag – facultatif ; contrôle le comportement de la réécriture. Les indicateurs courants sont les suivants :
  • last – arrête le traitement des règles de réécriture supplémentaires.
  • redirect – envoie une redirection temporaire.
  • permanent – envoie une redirection permanente.

Par exemple, pour rediriger une URL en fonction d’un modèle :

location / {
rewrite ^/old/(.*)$ /new/$1 permanent;
}

• L’expression régulière ^/old/(.*)$ correspond à toute URL commençant par /old/ et capture le reste du chemin.
• $1 fait référence au groupe capturé, ajouté à /new/.

Un autre exemple ajoute une barre oblique finale aux URL :

rewrite ^([^.]*[^/])$ $1/ permanent;

• ^([^.]*[^/])$ correspond aux URL sans barre oblique finale.
• $1/ ajoute une barre oblique à l’URL correspondante.

À l’inverse, vous pouvez rediriger les URL avec une barre oblique finale vers leurs versions sans barre oblique :

rewrite ^/(.*)/$ /$1 permanent;

• ^/(.*)/$ correspond aux URL se terminant par une barre oblique.

Utilisation de la directive try_files

Avec try_files, vous pouvez vérifier l’existence de fichiers ou de répertoires spécifiques avant de servir une réponse ou de rediriger le trafic. Cela est utile pour les sites web dynamiques, les configurations de secours ou la redirection des requêtes lorsque des fichiers sont manquants.

La directive try_files utilise la syntaxe suivante :

try_files chemin1 chemin2 ... fallback;

• chemin1 chemin2 – définit les chemins d’accès aux fichiers ou répertoires que NGINX vérifiera dans l’ordre.
• fallback – spécifie l’action ou l’URL à utiliser si aucun chemin défini n’existe.

Voici un exemple de redirection des requêtes pour des fichiers inexistants vers une page d’erreur personnalisée :

location / {
try_files $uri $uri/ /404.html;
}

• $uri vérifie si le fichier demandé existe.
• $uri/ vérifie si un répertoire portant le nom demandé existe.
• /404.html est servi si aucun des deux n’existe.

De même, pour rediriger tous les fichiers manquants vers la page d’accueil de votre Site web :

location / {
try_files $uri $uri/ /index.html;
}

• /index.html sert de solution de secours si aucun fichier ou répertoire correspondant à la requête n’existe.

Si vous souhaitez rediriger les fichiers PHP manquants vers un gestionnaire d’erreurs :

location ~ \.php$ {
try_files $uri /error-handler.php;
}

• L’expression régulière ~ \.php$ correspond à toutes les requêtes PHP.
• /error-handler.php gère les requêtes pour les fichiers PHP manquants.

Cas d’utilisation des redirections NGINX

Les redirections NGINX ont plusieurs objectifs, allant du renforcement de la sécurité à l’amélioration de l’expérience utilisateur. Voici cinq cas d’utilisation courants et des instructions pour les mettre en œuvre.

Redirection de HTTP vers HTTPS

La redirection du trafic HTTP vers HTTPS améliore la sécurité de votre site web et renforce la confiance des utilisateurs. Elle garantit également que les moteurs de recherche reconnaissent votre site comme étant sécurisé, ce qui peut améliorer votre classement SEO.

L’exemple suivant montre comment configurer une redirection HTTP vers HTTPS à l’aide de la directive return :

server {
listen 80;
server_name domain.tld www.domain.tld;
return 301 https://$host$request_uri;
}

• listen 80 écoute le trafic HTTP entrant sur le port 80.
• server_name domain.tld www.domain.tld spécifie les noms de domaine gérés par ce bloc de serveur.

Redirection de non-WWW vers WWW

La redirection du trafic non-WWW vers la version WWW de votre site web permet de conserver une structure d’URL cohérente et d’éviter les problèmes de contenu dupliqué. Vous pouvez y parvenir dans NGINX en ajoutant un bloc de serveur dédié pour traiter les requêtes non-WWW. Par exemple :

server {
listen 80;
server_name domain.tld;
return 301 http://www.domain.tld$request_uri;
}

• server_name domain.tld correspond aux requêtes pour la version non WWW du nom de domaine.

Si votre site utilise HTTPS, ajoutez une configuration similaire pour rediriger le trafic non-WWW vers HTTPS :

server {
listen 443 ssl;
server_name domain.tld;
return 301 https://www.domain.tld$request_uri;
}

• listen 443 ssl écoute le trafic HTTPS.

Redirection vers une page de maintenance

La redirection du trafic vers une page de maintenance est courante lors des mises à jour du site ou des interruptions temporaires. À l’aide d’un bloc location, vous pouvez facilement configurer une redirection d’URL NGINX pour informer les visiteurs de la maintenance en cours.

Par exemple, pour rediriger tout le trafic vers une page de maintenance :

server {
listen 80;
server_name domain.tld www.domain.tld;
location / {
return 302 /maintenance.html;
}
location /maintenance.html {
root /var/www/html;
}
}

• location / correspond à toutes les requêtes entrantes et les redirige vers /maintenance.html à l’aide d’une redirection temporaire (302).
• location /maintenance.html spécifie l’emplacement du fichier de la page de maintenance. Dans ce cas, il se trouve dans le répertoire /var/www/html.

Configuration de redirections conditionnelles

Les redirections conditionnelles dans NGINX vous permettent de rediriger le trafic en fonction de conditions spécifiques, telles que les agents utilisateurs ou les adresses IP. Pour ce faire, utilisez la directive if dans un bloc server ou location.

L’exemple suivant redirige les utilisateurs mobiles vers une version mobile de votre site :

server {
listen 80;
server_name domain.tld www.domain.tld;
if ($http_user_agent ~* "Mobile") {
return 302 https://m.domain.tld$request_uri;
}
}

• $http_user_agent correspond à la chaîne de l’agent utilisateur du navigateur ou de l’appareil du visiteur.
• La condition ~* “Mobile” correspond aux agents utilisateurs contenant Mobile, sans distinction entre majuscules et minuscules.

Un autre exemple montre comment bloquer ou rediriger des adresses IP spécifiques :

server {
listen 80;
server_name domain.tld;
if ($remote_addr = 192.168.1.1) {
return 403;
}
}

• $remote_addr correspond à l’adresse IP du visiteur.
• La directive return 403 bloque l’accès en renvoyant un code de réponse Forbidden (403).

Redirection avec des paramètres de requête

En redirigeant les URL avec des paramètres de requête, vous pouvez gérer les requêtes dynamiques tout en conservant ou en modifiant des données spécifiques dans l’URL. NGINX rend cela possible à l’aide des directives if ou rewrite, combinées à des variables telles que $request_uri et $arg_.

Par exemple, pour rediriger une URL tout en conservant les paramètres de requête :

location /old-page {
return 301 /new-page?$query_string;
}

• $query_string préserve les paramètres de requête d’origine dans l’URL redirigée.
• Par exemple, /old-page?promo=true redirige vers /new-page?promo=true.

Par ailleurs, pour rediriger les visiteurs en fonction d’un paramètre de requête spécifique :

server {
listen 80;
server_name domain.tld;
if ($arg_promo = "true") {
return 301 /promo-page;
}
}

• $arg_promo correspond à la chaîne de requête promo dans l’URL.
• Si la chaîne de requête est égale à true, les visiteurs sont redirigés vers /promo-page.

Bonnes pratiques pour les redirections NGINX

Suivez ces bonnes pratiques lors de la configuration des redirections NGINX afin d’obtenir des performances optimales, d’éviter les erreurs et de garantir une expérience utilisateur fluide :

Évitez les boucles de redirection

Les boucles de redirection se produisent lorsqu’une règle redirige involontairement le trafic vers elle-même ou chevauche d’autres règles. Ces boucles peuvent ralentir votre serveur et frustrer les utilisateurs. Évitez les boucles de redirection en utilisant des conditions précises dans vos blocs serveur ou emplacement afin d’éviter les conflits.

Cet exemple n’est pas sûr car il redirige le trafic vers lui-même :

server {
listen 80;
server_name domain.tld;
return 301 http://domain.tld$request_uri;
}

À l’inverse, voici un exemple de redirection sécurisée :

server {
listen 80;
server_name www.domain.tld;
return 301 https://domain.tld$request_uri;
}

N’utilisez les caractères génériques ou les expressions régulières qu’en cas de nécessité

Bien que les caractères génériques et les expressions régulières offrent une grande flexibilité, ils peuvent compliquer les configurations et nuire aux performances. Utilisez-les uniquement lorsque des options plus simples, telles que la directive return, ne permettent pas de répondre à vos besoins.

Par exemple, évitez les modèles trop généraux comme celui-ci :

location ~ .* {
return 301 /new-page;
}

Utilisez plutôt des modèles ou des conditions spécifiques, comme indiqué ci-dessous :

location ~ ^/old-page[0-9]+$ {
return 301 /new-page;
}

Combinez les règles de redirection lorsque cela est possible

Le regroupement de redirections similaires en un seul bloc minimise les directives et améliore la clarté. Par exemple :

location ~ ^/(old-page1|old-page2|old-page3)$ {
return 301 /new-page;
}

Réduisez au minimum les redirections en chaîne

Le chaînage de plusieurs redirections ralentit le chargement des pages et a un impact négatif sur le référencement. Redirigez toujours le trafic directement vers sa destination finale. Par exemple, au lieu de chaîner :

/page1 -> /page2 -> /page3

Utilisez une redirection directe comme ceci :

/page1 -> /page3

Testez les règles de redirection avant et après le déploiement

Validez toujours vos redirections afin qu’elles se comportent comme prévu. Utilisez ces commandes pour vérifier les erreurs de syntaxe avant de recharger votre configuration :

sudo nginx -t
sudo systemctl reload nginx

Les clients VPS Hostinger peuvent également utiliser Kodee pour identifier les erreurs de syntaxe dans leur configuration NGINX. Il suffit de demander « Pouvez-vous vérifier si ma configuration NGINX actuelle comporte des erreurs ? » et l’outil répondra comme suit :

Sinon, des outils tels que curl peuvent vérifier les codes d’état HTTP et les URL redirigées :

curl -I http://domain.tld/old-page

Après le déploiement, utilisez des outils de référencement tels que Google Search Console ou Screaming Frog pour vous assurer qu’il n’y a pas de liens rompus ou de boucles de redirection.

Conclusion

Dans cet article, nous avons expliqué comment configurer diverses redirections NGINX, notamment les redirections de HTTP vers HTTPS et de non-WWW vers WWW. Vous avez également découvert les meilleures pratiques, telles que la manière d’éviter les boucles de redirection, d’utiliser judicieusement les expressions régulières et de tester minutieusement vos redirections.

De plus, nous avons abordé la configuration des redirections avec des paramètres de requête et la maintenance de blocs de serveurs propres. Grâce à ces connaissances, vous pouvez gérer efficacement le trafic et optimiser les configurations de votre serveur pour améliorer les performances et le référencement.

Si vous avez encore des questions sur les redirections côté serveur NGINX, n’hésitez pas à utiliser la zone de commentaires ci-dessous.

Redirection NGINX – FAQ

Tout le contenu des tutoriels de ce site est soumis aux normes éditoriales et aux valeurs rigoureuses de Hostinger.