Une configuration Nginx qui maintient les sites rapides

Publié le 19 septembre 2026

Un site peut sembler parfaitement sain jusqu'à ce qu'une petite erreur de configuration Nginx transforme un déploiement de routine en erreur 502, en avertissement SSL ou en boucle de redirection qui n'envoie les visiteurs nulle part d'utile. Nginx est rapide et fiable, mais il est aussi exigeant : une directive au mauvais endroit peut changer le comportement d'un site entier. La bonne nouvelle, c'est qu'une approche propre rend la configuration Nginx bien moins mystérieuse.

Ce guide se concentre sur les paramètres les plus importants lors de l'hébergement de sites web : blocs server, gestion de PHP, HTTPS, redirections, fichiers statiques, mise en cache et tests sûrs. Vous n'avez pas besoin de mémoriser chaque directive Nginx. Vous devez comprendre quelles décisions affectent votre site et comment les vérifier avant qu'elles n'affectent vos visiteurs.

Commencez avec une structure de configuration Nginx claire

La plupart des installations Linux séparent les paramètres globaux des paramètres propres à chaque site web. Le fichier de configuration principal, généralement situé dans /etc/nginx/nginx.conf, contrôle les processus worker, la journalisation, la compression et les répertoires de configuration inclus. Les sites individuels se trouvent généralement dans un répertoire tel que sites-available, sites-enabled ou conf.d.

Cette séparation est utile pour une raison pratique : les paramètres globaux doivent être modifiés avec précaution et rarement, tandis que les paramètres au niveau du site web nécessitent une attention régulière. Un nouveau domaine, un site de préproduction ou une règle de redirection appartient au bloc server de ce site, pas au fichier principal.

Avant de modifier quoi que ce soit, identifiez la configuration active et testez-la :

bash nginx -t

Si le test réussit, rechargez Nginx sans interrompre les connexions actives :

bash systemctl reload nginx

Utilisez reload pour les modifications normales de configuration. Un redémarrage complet est parfois nécessaire, mais ce n'est pas la première chose à faire lorsque vous mettez à jour un hôte virtuel. De petites habitudes comme celle-ci évitent qu'une tâche de cinq minutes ne se transforme en intervention de récupération en pleine nuit.

Créez un bloc server par site web

Un bloc server indique à Nginx quel domaine il sert, où les fichiers du site web sont stockés et comment les requêtes doivent être traitées. Considérez-le comme l'accueil d'un site web. Lorsque plusieurs domaines partagent un même serveur, c'est un bloc server bien organisé qui permet au trafic d'arriver au bon endroit.

Un site HTTP de base peut ressembler à ceci :

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Le server_name doit lister chaque nom d'hôte que vous avez l'intention de servir. Si les visiteurs peuvent accéder à la fois au domaine racine et à www, incluez les deux, puis décidez lequel doit devenir canonique via une redirection.

Le chemin root doit pointer vers le répertoire contenant les fichiers web publics, pas nécessairement vers le dossier racine du projet. Pour WordPress, il s'agit souvent du dossier où se trouvent wp-admin, wp-content et wp-includes. Pour Laravel et les frameworks similaires, il s'agit généralement du répertoire public. Pointer Nginx vers le mauvais dossier peut exposer des fichiers qui ne devraient jamais être accessibles publiquement.

La règle try_files mérite une attention particulière. Elle vérifie si un fichier ou un répertoire demandé existe avant de transmettre les requêtes non correspondantes à l'application. C'est essentiel pour les permaliens WordPress et de nombreuses applications PHP modernes. Sans cela, les pages peuvent ne fonctionner que lorsque les visiteurs utilisent l'URL complète avec index.php ajouté. Ce n'est pas idéal, et ce n'est pas un problème que vous voulez voir signalé en premier par les clients.

Évitez le piège du serveur par défaut

Nginx a besoin d'un serveur par défaut pour les requêtes qui ne correspondent à aucun nom d'hôte configuré. Si le mauvais site est défini par défaut, un domaine inconnu ou une requête directe par IP peut afficher le site web de quelqu'un d'autre. C'est au mieux déroutant et au pire risqué.

Pour les serveurs multi-sites, utilisez un serveur par défaut simple qui ne renvoie aucun contenu utile, comme une réponse 404. Conservez les vrais sites web dans des blocs server explicites avec leurs propres valeurs server\_name. C'est une petite limite qui rend un serveur partagé plus facile à gérer.

Configurez PHP sans approximations

Nginx ne traite pas PHP tout seul. Il transmet les requêtes PHP à PHP-FPM, qui exécute le code. La connexion est normalement une socket Unix ou un port TCP local.

Un bloc location PHP courant ressemble à ceci :

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

La version de PHP et le chemin de la socket varient selon le serveur. Si Nginx renvoie une erreur 502 Bad Gateway après une mise à jour de PHP, le chemin de la socket est l'un des premiers éléments à vérifier. PHP-FPM est peut-être arrêté, exécute une autre version ou écoute ailleurs que sur le chemin défini dans Nginx.

La ligne try_files $uri =404; mérite également d'être conservée. Elle empêche Nginx d'envoyer au processeur PHP des requêtes pour des fichiers PHP inexistants. Cela améliore à la fois la sécurité et la gestion des erreurs.

Pour WordPress, évitez d'ajouter de larges règles copiées depuis des messages de forum au hasard, sauf si vous savez pourquoi elles sont nécessaires. WordPress fonctionne déjà bien avec une configuration try_files propre, une gestion PHP correcte et des permissions en écriture uniquement là où WordPress en a besoin. Davantage de règles ne signifient pas automatiquement une meilleure configuration.

Faites de HTTPS le chemin par défaut

Chaque site web public doit servir HTTPS et rediriger le trafic HTTP vers la version sécurisée. Le modèle habituel consiste en un bloc server HTTP qui effectue uniquement la redirection, plus un bloc HTTPS séparé qui sert le site.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

Le bloc server HTTPS écoute alors sur le port 443 et inclut les chemins du certificat et de la clé privée. Les fichiers de certificat dépendent de la façon dont SSL est provisionné, mais le principe reste le même : conservez la configuration du certificat dans le site qui l'utilise.

Une redirection permanente 301 est appropriée une fois que vous êtes certain de la destination. Pendant une migration en cours ou un test de courte durée, une redirection 302 peut être plus sûre parce que les navigateurs ne la mettent pas en cache de manière aussi agressive. C'est l'un de ces cas où l'option qui semble techniquement la plus solide n'est pas toujours le bon choix opérationnel.

Choisissez également un nom d'hôte préféré. Redirigez soit www vers le domaine racine, soit le domaine racine vers www. Servir les deux sans redirection cohérente peut fragmenter les analyses, créer des pages dupliquées pour les moteurs de recherche et rendre le comportement des cookies plus difficile à diagnostiquer.

Servez les fichiers statiques efficacement et en toute sécurité

Les images, CSS, JavaScript, polices et fichiers téléchargeables ne doivent pas consommer de ressources PHP lorsque Nginx peut les livrer directement. Définissez une mise en cache du navigateur raisonnable pour les fichiers qui changent rarement :

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Trente jours constituent un bon point de départ, pas une loi. Si vos noms de fichiers incluent des numéros de version ou des noms de fichiers hachés, une mise en cache plus longue peut très bien fonctionner. Si le même nom de fichier est fréquemment remplacé, un cache long peut faire en sorte que les visiteurs voient un ancien design ou script. La mise en cache est toujours un compromis entre la vitesse et la rapidité avec laquelle les changements doivent apparaître.

N'exposez pas des fichiers cachés par accident. Une règle simple peut bloquer les requêtes visant les fichiers pointés tout en autorisant le répertoire .well-known utilisé par la validation des certificats :

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Selon votre configuration de certificat, vous pourriez avoir besoin d'une exception spécifique pour .well-known. Testez le comportement du renouvellement après avoir rendu les règles d'accès plus strictes. Les règles de sécurité doivent réduire l'exposition, pas casser discrètement les services sur lesquels vous comptez.

Utilisez les en-têtes de sécurité avec contexte

Les en-têtes de réponse peuvent améliorer la protection côté navigateur, mais ils nécessitent des tests. Parmi les exemples courants figurent X-Content-Type-Options nosniff, Referrer-Policy et Content-Security-Policy. Le dernier est puissant et facile à mal configurer. Une politique stricte peut bloquer des scripts, polices, widgets de paiement, outils d'analyse ou contenus intégrés si elle est introduite sans comprendre les dépendances du site.

Commencez par des en-têtes ayant un objectif clair et un faible risque, puis ajoutez une politique de sécurité du contenu en mode rapport uniquement si votre application le prend en charge. L'objectif n'est pas d'accumuler une impressionnante pile de directives. L'objectif est de réduire le risque réel sans casser les pages que les gens doivent utiliser.

La limitation de débit peut également aider à lutter contre le trafic abusif et les attaques de connexion, en particulier pour les points de terminaison de connexion WordPress. Mais des limites agressives peuvent bloquer des utilisateurs légitimes derrière des réseaux de bureau partagés ou des opérateurs mobiles. Examinez les journaux et ajustez en fonction des schémas de trafic réels plutôt qu'en choisissant des chiffres qui semblent simplement stricts.

Testez les modifications comme si elles comptaient

Chaque modification de Nginx doit suivre la même courte routine : sauvegardez ou copiez le fichier actuel, effectuez une seule modification ciblée, exécutez nginx -t, rechargez Nginx et testez le site web depuis un navigateur et la ligne de commande. Vérifiez le domaine prévu, le domaine non canonique, HTTP, HTTPS et une page gérée par PHP.

Lorsque quelque chose échoue, lisez les journaux d'erreurs avant de réécrire la configuration. Les journaux d'accès et d'erreurs de Nginx révèlent souvent si le problème vient d'un fichier manquant, d'une permission incorrecte, d'une connexion upstream échouée ou d'une mauvaise redirection. Faire des suppositions peut créer trois nouveaux problèmes sans en résoudre aucun.

Un panneau de contrôle peut éliminer une grande partie de ce travail manuel en créant et en organisant en un seul endroit les paramètres au niveau du site web, les certificats, les versions de PHP et les journaux. FASTPANEL est conçu pour ce juste milieu pratique : vous gardez le contrôle de votre environnement d'hébergement sans transformer chaque changement de domaine en projet d'archéologie de configuration.

Une bonne configuration Nginx ne consiste pas à construire le fichier le plus long ni à utiliser chaque directive disponible. Il s'agit de rendre chaque site prévisible : le bon domaine atteint les bons fichiers, PHP dispose d'un upstream sain, HTTPS est appliqué, le contenu statique est efficace et les modifications sont testées avant que les visiteurs n'y soient confrontés. Une fois cette base en place, la gestion d'un serveur en croissance devient bien moins dramatique - exactement comme elle devrait l'être.