Redirections Nginx 301 et 302 sur un VPS Linux

Les redirections préservent vos visiteurs et votre référencement quand une page change d'adresse, quand vous changez de domaine ou quand vous forcez le HTTPS. Ce guide montre comment écrire des redirections Nginx propres sur votre VPS Linux Infrawire et les tester avant qu'elles n'atteignent la production.

📋 Prérequis

Un VPS Linux (Ubuntu 24.04 / Debian 12 ou AlmaLinux 9 / Rocky 9) avec accès SSH root. L'IP et le mot de passe root se trouvent dans votre espace client.
Nginx installé et servant au moins un site (sudo apt install nginx ou sudo dnf install nginx).
Un nom de domaine (example.com) dont les enregistrements DNS A/AAAA pointent vers VPS_IP.

🧭 301 ou 302 : lequel choisir

301 (Moved Permanently) : le changement est définitif. Les navigateurs et les moteurs de recherche le mettent en cache et transfèrent le classement vers la nouvelle URL.
302 (Found) : le changement est temporaire (maintenance, test A/B). L'ancienne URL reste la référence.

En cas de doute, commencez par un 302 : un 301 erroné peut rester longtemps en cache dans les navigateurs.

⚙️ return ou rewrite

Préférez return : il est plus rapide et plus lisible, car Nginx arrête immédiatement le traitement.

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

N'utilisez rewrite que si vous devez capturer une partie de l'URL avec une expression régulière :

Nginx
rewrite ^/blog/(\d+)/(.*)$ /articles/$2 permanent;

Le drapeau permanent envoie un 301, redirect envoie un 302.

🌐 Rediriger www vers non-www

Créez un bloc server dédié qui ne fait que rediriger. Modifiez /etc/nginx/sites-available/example.com (Debian/Ubuntu) ou /etc/nginx/conf.d/example.com.conf (AlmaLinux/Rocky) :

Nginx
1server {
2    listen 80;
3    listen [::]:80;
4    server_name www.example.com;
5    return 301 $scheme://example.com$request_uri;
6}

Pour le sens inverse, échangez les deux noms d'hôte. $request_uri conserve le chemin et la query string.

🔒 Rediriger HTTP vers HTTPS

Une fois le certificat installé, envoyez tout le trafic en clair vers HTTPS :

Nginx
1server {
2    listen 80;
3    listen [::]:80;
4    server_name example.com www.example.com;
5    return 301 https://example.com$request_uri;
6}
7
8server {
9    listen 443 ssl;
10    listen [::]:443 ssl;
11    http2 on;
12    server_name www.example.com;
13    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
14    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
15    return 301 https://example.com$request_uri;
16}

Le vrai site se trouve ensuite dans un troisième bloc qui écoute sur 443 avec server_name example.com;. Notez que http2 on; demande Nginx 1.25.1 ou plus récent, ce qui est le cas sur Ubuntu 24.04.

🔗 Ancienne URL vers nouvelle URL

Pour quelques pages, utilisez des correspondances exactes (=), les plus rapides :

Nginx
location = /about-us.html { return 301 /about; }
location = /promo        { return 302 /offers/current; }

Pour un dossier entier déplacé, en conservant les sous-chemins :

Nginx
location /docs/ {
    rewrite ^/docs/(.*)$ /help/$1 permanent;
}

🏠 Rediriger un domaine entier

Quand vous abandonnez old-example.com pour example.com, conservez tous les chemins :

Nginx
1server {
2    listen 80;
3    listen [::]:80;
4    server_name old-example.com www.old-example.com;
5    return 301 https://example.com$request_uri;
6}

Si l'ancien domaine a aussi du HTTPS, ajoutez un bloc listen 443 ssl; correspondant avec son propre certificat, sinon les navigateurs affichent une erreur de certificat avant la redirection.

✅ Tester et recharger proprement

Validez toujours la syntaxe avant de recharger. Un reload conserve les connexions en cours, un restart non.

Bash
1sudo nginx -t
2sudo systemctl reload nginx

Vérifiez ensuite les en-têtes sans suivre la redirection :

Bash
1curl -I http://www.example.com/old-page

Sortie attendue (abrégée) :

HTTP/1.1 301 Moved Permanently
Server: nginx
Location: https://example.com/old-page

Pour suivre toute la chaîne et voir chaque étape, utilisez curl -IL http://www.example.com/old-page. Idéalement il n'y a qu'une seule étape : évitez les chaînes du type HTTP, puis www, puis HTTPS.

🛠️ Dépannage

Trop de redirections (boucle). Une règle correspond à sa propre destination, souvent parce qu'un proxy ou un CDN termine déjà le HTTPS. Vérifiez l'en-tête Location avec curl -I et assurez-vous que le bloc cible ne redirige pas à nouveau.

La modification n'a aucun effet. Vous avez modifié un fichier non activé. Sous Debian/Ubuntu, vérifiez le lien dans /etc/nginx/sites-enabled/, puis lancez sudo nginx -t et sudo systemctl reload nginx. Les navigateurs mettent aussi les 301 en cache : testez avec curl ou une fenêtre privée.

Query string perdue. Avec rewrite ... ? ou une cible fixe, les paramètres disparaissent. Utilisez $request_uri dans return, ou conservez $args explicitement.

Mauvais bloc qui répond. Nginx choisit le bloc selon server_name. Listez-les avec sudo nginx -T | grep server_name et cherchez les doublons.

🎉 Vos redirections sont en place : permanentes quand c'est définitif, temporaires sinon, et testées avec curl avant que vos visiteurs ne remarquent quoi que ce soit.