Comment installer NGINX sur un serveur dédié

Installer le serveur nginx demande deux commandes. Le travail, c'est ce qui suit : un server block par site, un certificat, une règle de pare-feu et le fait de savoir quelle directive atteindre quand une requête renvoie 403.

Préparer un serveur dédié

Partez d'une installation d'OS propre, avec une adresse IP publique et un accès SSH. NGINX est léger : une machine d'entrée gère des milliers de connexions clientes avant que le matériel compte.

Notre guide comment mettre en place une machine dédiée couvre l'étape de provisionnement.

Prérequis : OS, accès et paquets

Vous avez besoin d'Ubuntu 26.04 LTS ou de Debian 13, d'un utilisateur non root avec sudo et du port 80 libre. Apache l'occupe souvent sur une machine réutilisée, donc arrêtez d'abord ce service :

sudo systemctl stop apache2
sudo apt update

Le dépôt NGINX officiel fournit des builds pour amd64, arm64 et s390x si vous avez besoin d'une version plus récente que celle de la distribution.

Installer NGINX sur Ubuntu/Debian

Deux commandes suffisent :

apt update
sudo apt install nginx

La version 26.04 a simplifié le packaging : deux paquets, sans choix entre full et core. Le service démarre tout seul.

Vérifier l'installation et la version

nginx -v
curl -I http://localhost

Attendez-vous à nginx version: nginx/1.28.3. Un 200 OK depuis localhost signifie que la page par défaut est servie.

Vue d'ensemble du fichier de configuration NGINX

Le fichier nginx conf principal est /etc/nginx/nginx.conf. Il définit le modèle de workers, puis inclut tout ce qui se trouve dans le répertoire des drop-in et dans sites-enabled. Une compilation depuis les sources le place plutôt sous usr/local/nginx.

Chaque instruction est une directive. Une directive simple se termine par un point-virgule ; une directive de bloc en enveloppe d'autres entre accolades. Les blocs http, server et location s'imbriquent dans cet ordre, et une directive fixée dans un bloc externe est héritée par les internes, sauf si une directive imbriquée la remplace. Chaque module que vous activez ajoute son propre jeu de directives.

Créer des server blocks (virtual hosts)

Un server block par site. Créez /etc/nginx/sites-available/yourdomain.com :

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    root /var/www/yourdomain.com;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

La directive root nomme le répertoire sur disque, et le location du serveur en découle. Le bloc location filtre le chemin de la requête, si bien qu'un fichier statique et une route proxifiée sont traités depuis le même bloc. Activez le site, puis appliquez-le :

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Configurer votre domaine et le DNS

Pointez un enregistrement A pour yourdomain.com sur l'adresse IP de la machine, et un second pour www.yourdomain.com. Configurez les deux avant de demander un certificat. La propagation prend généralement quelques minutes. Vérifiez avant de demander un certificat :

dig +short yourdomain.com

La directive server_name doit correspondre exactement au domaine, sinon NGINX retombe sur son bloc par défaut.

Activer le HTTPS avec un SSL gratuit (Let's Encrypt)

Certbot lit votre server block, demande le certificat et réécrit la configuration. Vous ne configurez pas le TLS à la main :

apt install certbot python3-certbot-nginx
certbot --nginx -d yourdomain.com -d www.yourdomain.com

Il ajoute une directive listen 443 ssl et une redirection HTTP. Le renouvellement s'exécute depuis une minuterie systemd, testez-le donc une fois avec certbot renew --dry-run.

Configurer le reverse proxy et la répartition de charge

En reverse proxy, le serveur proxy termine la connexion du client et transmet à une application. C'est la fonctionnalité de proxy vers laquelle la plupart des équipes se tournent. La directive proxy_pass fait le travail :

location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Pour plusieurs backends, déclarez un upstream et laissez le serveur proxy répartir les requêtes entre eux :

upstream app {
    least_conn;
    server localhost:3000;
    server localhost:3001;
}

Un site PHP utilise les directives fastcgi à la place. Le serveur fastcgi écoute sur un socket, et nginx lui envoie chaque requête :

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.5-fpm.sock;
}

Optimiser les performances : gzip, cache et buffering

gzip on;
gzip_types text/css application/javascript image/svg+xml;
location ~* \.(css|js|png|jpg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

La compression réduit la taille de transfert du texte. La directive expires empêche un navigateur de redemander un png ou une feuille de style à chaque visite, et un png servi depuis le cache n'atteint jamais la machine. Le buffering est actif par défaut ; ne le désactivez que pour des réponses en streaming.

Gérer NGINX avec systemctl

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl reload nginx
sudo systemctl enable nginx

Reload n'est pas restart. Le signal reçu par nginx indique au process master de lire la nouvelle config et de retirer les anciens workers en douceur, si bien que les connexions actives se terminent. Un restart les coupe, et le master nginx continue de tourner pendant tout ce temps.

Configuration du pare-feu : autoriser HTTP/HTTPS avec UFW

sudo ufw allow 'Nginx Full'
sudo ufw allow OpenSSH
sudo ufw enable
ufw status

Le profil nginx d'ufw couvre à la fois le 80 et le 443. Configurez l'accès SSH avant d'activer le pare-feu, sinon vous vous enfermerez dehors. Notre guide de la configuration du pare-feu va plus loin.

Erreurs courantes et dépannage (403, 404, 413)

403 Forbidden. Des permissions. L'utilisateur www-data a besoin de l'exécution sur chaque répertoire parent, et de la lecture sur les fichiers.

404 Not Found. Souvent la directive root pointe vers un endroit qui n'existe pas, ou index désigne un fichier absent.

413 Payload Too Large. Relevez la limite avec la directive clientmaxbody_size, puis appliquez-la.

Lisez d'abord /var/log/nginx/error.log. Il nomme le fichier et la raison.

NGINX vs Apache : quand choisir NGINX

NGINX utilise une event loop ; apache2 un processus ou un thread par requête. Cela le rend plus léger en concurrence et plus rapide pour servir un fichier statique.

Choisissez apache2 quand une application livre des règles .htaccess que vous ne pouvez pas déplacer dans un server block. Sinon nginx est le meilleur choix par défaut, et nombre d'installations le font tourner devant apache2 comme serveur proxy.

Check-list de pré-mise en ligne

• nginx -t passe

• HTTPS fonctionne et HTTP y redirige

• Le pare-feu autorise le 80, le 443 et le SSH

• clientmaxbody_size correspond à la taille de vos téléversements

• Les logs tournent, et vous savez où ils sont

Ensuite, gardez-le à jour. Notre guide de maintenance d'un serveur dédié couvre la routine, et le guide du serveur dédié pour un site web le dimensionnement.

Conclusion

Deux commandes l'installent. Un server block par site, un certificat, une règle de pare-feu, et nginx -t avant d'appliquer quoi que ce soit.

Les machines Kimsufi démarrent à 9,99 €/mois avec un accès root complet, et nos guides serveur de jeu et mods couvrent d'autres charges de travail sur la même machine.

FAQ