Rediriger HTTP vers HTTPS avec Nginx : guide complet pour sécuriser votre site

Pour rediriger HTTP vers HTTPS avec Nginx, créez un bloc serveur qui écoute sur le port 80 et renvoie un code 301 vers https://$host$request_uri. Cette redirection permanente conserve le domaine, le chemin demandé et la chaîne de paramètres, à condition qu’un bloc HTTPS fonctionnel écoute déjà sur le port 443.

La redirection HTTP vers HTTPS Nginx ne consiste pas à ajouter une ligne isolée dans un fichier : le certificat TLS, le nom de domaine canonique, les défis Let’s Encrypt et les tests après rechargement comptent aussi. Ce tutoriel détaille une procédure reproductible pour modifier la configuration sans créer de boucle de redirection ni interrompre inutilement le service.

Pourquoi rediriger HTTP vers HTTPS avec Nginx ?

Rediriger HTTP vers HTTPS avec Nginx consiste à faire répondre le serveur HTTP sur le port 80 par une instruction indiquant au navigateur de demander la même ressource via HTTPS sur le port 443. HTTPS est le protocole HTTP transporté dans une connexion TLS chiffrée : il protège les données échangées contre l’interception et permet au navigateur de vérifier l’identité du site au moyen du certificat.

Le code 301 signale une redirection permanente. Il convient lorsque le passage vers HTTPS est stabilisé, car les navigateurs et les robots peuvent mémoriser ou interpréter durablement ce changement. La migration ne doit pas alterner entre HTTP et HTTPS : une seule version canonique doit servir chaque page.

Une redirection HTTPS fiable commence par une destination HTTPS réellement disponible, pas par le code 301 seul.

HTTP et HTTPS : le mécanisme utile à retenir

HTTP transmet les requêtes sans chiffrement applicatif. HTTPS ajoute TLS avant le transport de la requête HTTP, ce qui permet de chiffrer les échanges entre le navigateur et le serveur. Une configuration Nginx HTTPS comprend donc, au minimum, un bloc server sur le port 443 et les directives de certificat correspondantes.

Pourquoi le chemin et les paramètres doivent rester intacts

La variable Nginx $request_uri contient le chemin demandé et la chaîne de requête. Une URL comme http://example.com/produit?id=42 devient donc https://example.com/produit?id=42. Cette conservation évite de rediriger tous les visiteurs vers la page d’accueil et limite les ruptures de liens internes ou externes.

Prérequis avant de modifier la configuration Nginx

La configuration Nginx HTTPS dépend de l’architecture du serveur : site unique, plusieurs hôtes virtuels, proxy inverse, conteneur ou panneau d’administration. Avant toute modification, identifiez le fichier réellement chargé par Nginx et vérifiez que le domaine pointe vers le bon serveur. Une configuration présente sur le disque, mais non incluse par Nginx, ne produit aucun effet.

Un certificat TLS valide pour le nom de domaine visé est indispensable avant de forcer HTTPS. Les chemins des certificats varient selon l’autorité de certification et la méthode de déploiement. Ne mettez pas en production une redirection globale vers HTTPS tant que la version HTTPS du domaine ne répond pas correctement.

• Accès administrateur au serveur ou aux fichiers de configuration Nginx.
• Nom de domaine déjà dirigé vers l’adresse IP ou le proxy approprié.
• Bloc HTTPS sur le port 443 avec certificat TLS et clé privée accessibles à Nginx.
• Sauvegarde du fichier de site avant modification.
• Accès à la commande sudo nginx -t et au service Nginx.

Identifier le fichier de site actif

Sur de nombreuses distributions Linux, les hôtes virtuels sont déclarés dans des fichiers inclus depuis nginx.conf. Les chemins exacts ne sont pas universels. Consultez le fichier principal, ses directives include et la sortie de nginx -T si vous devez afficher la configuration complète chargée.

Préparer une sauvegarde lisible

Copiez le fichier avant édition, avec un nom daté ou un suffixe explicite. Cette précaution permet de revenir à un état connu si le test de syntaxe échoue. Évitez de modifier simultanément la redirection, les certificats et le routage applicatif : plusieurs changements à la fois rendent le diagnostic plus difficile.

Comment configurer la redirection HTTP vers HTTPS dans Nginx ?

La méthode la plus directe consiste à séparer le trafic HTTP du trafic HTTPS : un bloc serveur écoute sur le port 80 et renvoie une redirection 301, tandis qu’un autre bloc écoute sur le port 443 avec TLS activé. Cette séparation rend le comportement lisible et évite d’essayer de servir le même site en clair et chiffré dans un unique bloc.

Étape 1 : sauvegardez le fichier et ouvrez le bloc serveur HTTP

Localisez le bloc server associé au domaine sur le port 80. Copiez d’abord le fichier, puis ouvrez-le dans votre éditeur. Le nom example.com utilisé ci-dessous est un domaine de démonstration : remplacez-le par votre domaine réel et sa variante www seulement si cette variante doit être gérée par ce site.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

La directive listen 80 reçoit les requêtes HTTP. La directive return 301 demande au client de refaire sa requête en HTTPS. La variable $host reprend le nom d’hôte fourni par le client, tandis que $request_uri préserve le chemin et les paramètres.

Étape 2 : vérifiez le bloc HTTPS sur le port 443

Le bloc HTTPS doit écouter sur le port 443 avec TLS. Les emplacements des fichiers de certificat ci-dessous dépendent de votre installation ; conservez les chemins réellement fournis par votre outil de certification. Le contenu applicatif, le proxy vers une application ou la racine du site restent dans ce bloc HTTPS.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /chemin/vers/certificat.pem;
    ssl_certificate_key /chemin/vers/cle-privee.pem;

    root /var/www/site;
    index index.html;
}

La redirection HTTP vers HTTPS Nginx ne remplace pas la configuration TLS. Un navigateur peut suivre une redirection 301 parfaitement valide, puis afficher une erreur si le certificat est expiré, absent, destiné à un autre nom de domaine ou non accessible par Nginx.

Étape 3 : conservez l’accès au défi ACME si Certbot utilise le webroot

Certbot peut valider ou renouveler un certificat en demandant un fichier sous /.well-known/acme-challenge/. Si votre méthode de validation repose sur ce chemin HTTP, servez ce répertoire avant la règle de redirection. Le répertoire /var/www/letsencrypt est un exemple à adapter au webroot réellement utilisé par Certbot.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Cette exception ne doit pas être ajoutée par automatisme si votre certificat est validé autrement, par exemple via DNS. En revanche, dans un déploiement webroot, intercepter ce chemin par une redirection générale peut empêcher la validation ACME et, à terme, le renouvellement du certificat.

Étape 4 : choisissez une forme canonique pour le domaine

Le domaine principal peut être example.com ou www.example.com. Choisissez la forme qui correspond à votre politique de publication, puis faites converger les autres variantes vers elle en limitant les sauts. Une requête HTTP sur www ne devrait pas passer par plusieurs redirections successives avant d’atteindre la page HTTPS canonique.

Situation	Bloc serveur HTTP conseillé	Point de vigilance
Un seul site	server_name example.com www.example.com;	Vérifier que le certificat couvre les deux noms si les deux restent accessibles.
Plusieurs sites Nginx	Un bloc port 80 par domaine	Ne pas employer un bloc global si certains hôtes ne doivent pas passer en HTTPS.
Tous les hôtes doivent passer en HTTPS	listen 80 default_server; et server_name _;	Confirmer que chaque hôte reçu dispose bien d’une destination HTTPS valide.

Cas d’un bloc global « catch-all »

Un bloc avec server_name _; peut recevoir les noms d’hôte non associés à un autre bloc plus spécifique. Cette approche est adaptée uniquement lorsqu’un serveur entier doit rediriger vers HTTPS. Dans une machine multi-sites, un bloc explicite par domaine réduit le risque d’envoyer un hôte inattendu vers une destination qui ne possède pas de certificat approprié.

server {
    listen 80 default_server;
    server_name _;

    return 301 https://$host$request_uri;
}

Un bloc « catch-all » est une politique de serveur, pas une recette universelle pour un hébergement multi-domaines.

Comment tester la redirection HTTPS avant et après le rechargement ?

Testez d’abord la syntaxe, puis rechargez Nginx sans interrompre le processus, et enfin contrôlez les en-têtes HTTP depuis un terminal. La commande curl permet de vérifier la réponse sans dépendre du cache d’un navigateur. Testez le domaine principal, sa variante éventuelle avec www, une page interne et une URL avec paramètres.

Étape 5 : validez la syntaxe et rechargez le service

Exécutez la commande suivante après chaque modification du fichier de configuration. La première partie vérifie la syntaxe ; la seconde recharge Nginx uniquement si le test réussit. En cas d’erreur, corrigez le fichier indiqué par Nginx plutôt que de forcer le rechargement.

sudo nginx -t && sudo systemctl reload nginx

La commande de rechargement varie selon le système d’exploitation et le gestionnaire de services. Sur un environnement sans systemd, utilisez la méthode documentée pour votre installation Nginx. Le test nginx -t est le point de contrôle qui évite de déployer une erreur de syntaxe en production.

Étape 6 : contrôlez le code 301 et l’en-tête Location

La commande suivante doit renvoyer un statut 301 et un en-tête Location commençant par https://. Remplacez le domaine de démonstration par le vôtre. Une URL incluant un chemin et un paramètre permet de contrôler que $request_uri est bien conservé.

curl -I http://example.com/produit?id=42

Pour suivre la chaîne de redirection, utilisez curl -IL. Le résultat doit atteindre une réponse HTTPS normale sans revenir vers HTTP. Testez aussi le certificat avec un navigateur ou un outil de contrôle TLS si le serveur est exposé publiquement.

1. Testez http://votre-domaine/ et vérifiez un statut 301.
2. Testez une URL profonde avec paramètres, par exemple une page produit ou une recherche interne.
3. Testez séparément la variante www si elle existe.
4. Suivez les redirections avec curl -IL pour détecter une chaîne ou une boucle.
5. Ouvrez l’URL HTTPS finale et vérifiez la validité du certificat dans le navigateur.

Erreurs fréquentes lors d’une redirection HTTP HTTPS Nginx

Les erreurs de redirection Nginx apparaissent souvent à la frontière entre le serveur web, le proxy inverse et l’application. Le symptôme ne suffit pas : une boucle, une erreur de certificat ou une ressource mixte n’ont pas la même cause. Identifiez d’abord la réponse HTTP réellement reçue, puis remontez vers le bloc serveur concerné.

• Boucle de redirection : un proxy ou une application croit recevoir du HTTP alors que le visiteur utilise HTTPS. Vérifiez les en-têtes transmis par le proxy, notamment le schéma d’origine, et évitez que deux couches imposent des redirections contradictoires.
• Certificat refusé : le bloc 443 utilise un certificat qui ne couvre pas le domaine demandé, ou le certificat n’est plus valide. Contrôlez le nom demandé, la chaîne de certificats et la date de validité avant de modifier la règle 301.
• Défi Certbot inaccessible : la redirection capture /.well-known/acme-challenge/ alors que la validation webroot en dépend. Servez ce chemin depuis le bon répertoire ou adaptez la méthode de validation.
• Nginx refuse le rechargement : une directive est mal placée, une accolade manque ou un fichier inclus contient une erreur. Lancez nginx -t et lisez le chemin et le numéro de ligne fournis.
• Contenu mixte : la page HTTPS charge encore des scripts, feuilles de style ou images en HTTP. Corrigez les URL dans l’application, le thème et les ressources externes ; la redirection serveur ne réécrit pas automatiquement toutes les adresses intégrées au HTML.

Pourquoi une boucle peut venir d’un proxy

Un CDN, un répartiteur de charge ou un proxy inverse peut terminer TLS avant Nginx et communiquer en HTTP avec le serveur d’origine. Si Nginx ou l’application redirige ensuite cette communication interne vers HTTPS sans connaître le schéma initial du visiteur, une boucle devient possible. Vérifiez l’architecture et la documentation du proxy avant d’ajouter une nouvelle règle.

Nginx, Apache ou Caddy : quelle couche doit gérer HTTPS ?

Nginx gère la redirection dans ses blocs server, ce qui convient lorsque Nginx reçoit directement le trafic web ou agit comme proxy inverse. Apache HTTP Server utilise une syntaxe différente, souvent dans un hôte virtuel ou, selon la configuration, dans un fichier .htaccess. Caddy automatise couramment la gestion HTTPS dans son propre modèle de configuration.

La règle utile est de choisir une couche qui voit la requête publique et qui possède une vision claire du protocole d’origine. Une seule couche doit porter la redirection principale afin d’éviter les chaînes inutiles et les diagnostics confus.

Solution	Emplacement habituel	Adaptée si	Limite à connaître
Nginx	Bloc server sur le port 80	Nginx reçoit le trafic public	La configuration dépend des hôtes virtuels et des proxys en amont.
Apache HTTP Server	VirtualHost ou règles Apache	Apache sert directement le site	Un fichier .htaccess n’est pas une méthode applicable à Nginx.
Caddy	Caddyfile ou configuration JSON	Vous utilisez déjà Caddy comme serveur frontal	La syntaxe et l’automatisation diffèrent de Nginx.

Sur un site administré avec Nginx, ne copiez donc pas une règle Apache dans un fichier Nginx. De même, un réglage effectué chez un fournisseur CDN peut modifier le trafic avant son arrivée sur votre serveur. Pour comprendre les données transmises par les navigateurs, la lecture de notre dossier sur le calcul d’une position GPS rappelle utilement qu’un résultat visible dépend souvent de plusieurs couches techniques, chacune avec son propre rôle.

Quelles bonnes pratiques appliquer après avoir forcé HTTPS ?

Une fois la redirection active, mettez à jour les URL absolues présentes dans les réglages du site, les sitemaps, les balises canoniques et les liens internes. Cette mise à jour réduit les redirections inutiles et facilite l’identification de l’URL canonique par les outils d’analyse et les moteurs de recherche.

Ajouter HSTS avec prudence

HSTS, pour HTTP Strict Transport Security, est un en-tête envoyé par une réponse HTTPS qui indique au navigateur de privilégier HTTPS lors des visites suivantes. Une valeur courante de max-age=31536000 correspond à 31 536 000 secondes, soit un an. Ajoutez HSTS seulement après avoir validé les certificats, les sous-domaines concernés et les procédures de renouvellement.

add_header Strict-Transport-Security "max-age=31536000" always;

L’option always permet l’envoi de l’en-tête même sur certaines réponses d’erreur. Le préchargement HSTS est plus contraignant : il implique notamment includeSubDomains et une durée d’au moins 63072000 secondes, soit deux ans, selon les critères du programme de préchargement. N’activez pas cette variante tant que chaque sous-domaine concerné ne fonctionne pas durablement en HTTPS.

Surveiller les renouvellements et les ressources

Programmez ou contrôlez le renouvellement du certificat avec l’outil utilisé par votre infrastructure. Après une mise à jour du thème, d’un CMS ou d’un proxy, testez une page représentative afin de repérer les ressources chargées en HTTP. Pour mieux comprendre les échanges entre applications et infrastructures, un autre exemple de chaîne technique est présenté dans notre article sur la localisation GPS sur smartphone.

Sources utiles à consulter

La documentation de l’éditeur reste le repère le plus fiable lorsqu’une directive dépend de la version de Nginx ou du mode de déploiement.

• Documentation Nginx sur la directive return : syntaxe et comportement des réponses de redirection.
• Documentation Nginx sur le traitement des requêtes : sélection des blocs serveur selon le port et le nom d’hôte.
• Documentation Certbot : méthodes de validation et renouvellement des certificats.
• Référence MDN sur Strict-Transport-Security : fonctionnement de HSTS et implications de sa durée.

Questions fréquentes sur la redirection HTTP vers HTTPS avec Nginx

Le code 301 est-il nécessaire pour forcer HTTPS avec Nginx ?

Le code 301 convient à une migration permanente de HTTP vers HTTPS. Il indique que la ressource a changé d’adresse de façon durable. Utilisez-le après avoir vérifié que la destination HTTPS et son certificat sont stables.

La redirection conserve-t-elle les paramètres d’une URL ?

Oui, la construction https://$host$request_uri conserve normalement le chemin et la chaîne de requête. Une requête avec ?id=42 reste donc associée à ce paramètre après le passage vers HTTPS. Testez toutefois les URL importantes de votre application.

Pourquoi Nginx affiche-t-il une boucle de redirection ?

Une boucle provient souvent d’une règle concurrente dans l’application, un proxy ou un CDN. Le serveur peut croire que la requête arrive en HTTP alors que le visiteur utilise HTTPS. Contrôlez les en-têtes transmis entre les couches avant de modifier la redirection Nginx.

Peut-on utiliser un seul bloc HTTP pour plusieurs domaines ?

Un bloc global avec server_name _; peut capter plusieurs noms d’hôte. Cette méthode n’est appropriée que si chaque domaine reçu doit réellement être servi en HTTPS avec un certificat valide. Sur un serveur multi-sites, des blocs distincts par domaine sont souvent plus prévisibles.

Faut-il activer HSTS immédiatement après la redirection ?

Non. HSTS demande une vérification préalable des certificats, des redirections et des sous-domaines concernés. Une politique trop large peut empêcher des navigateurs d’accéder à un sous-domaine qui ne supporte pas encore HTTPS correctement.