Monter un Serveur Web sous Linux : Nginx et Apache

Héberger un site ou une application web sur votre propre serveur Linux est l’un des exercices les plus formateurs de l’administration système : il mobilise la gestion des paquets, les services systemd, le réseau, les certificats TLS et la sécurité. Dans ce guide, nous allons monter un serveur web complet, de l’installation au HTTPS en passant par le reverse proxy, en couvrant les deux serveurs qui dominent le marché : Nginx et Apache. Les exemples utilisent Ubuntu/Debian ; les différences avec la famille Red Hat sont signalées quand elles existent.

1. Choisir Nginx ou Apache

Les deux serveurs sont matures, performants et parfaitement capables d’héberger n’importe quel site. Leurs architectures diffèrent cependant, et certains contextes favorisent l’un ou l’autre.

Critère	Nginx	Apache
Architecture	Événementielle, asynchrone	Processus/threads par connexion (MPM event moderne)
Contenu statique	Excellent, très faible mémoire	Bon
Connexions simultanées massives	Point fort historique	Correct avec mpm_event
Reverse proxy / load balancing	Natif et très utilisé	Possible (mod_proxy)
Fichiers .htaccess	Non supportés	Supportés (config par répertoire)
Exécution de code (PHP…)	Toujours déléguée (FastCGI/PHP-FPM)	Modules intégrés possibles (mod_php)
Syntaxe de configuration	Blocs concis	Directives XML-like, plus verbeuses
Cas d’usage typique	Reverse proxy, statique, applications modernes	Hébergement mutualisé, legacy, .htaccess requis

En 2026, le choix par défaut pour un nouveau projet est le plus souvent Nginx : reverse proxy natif, configuration compacte, consommation mémoire stable sous forte charge. Apache reste incontournable quand vos utilisateurs doivent modifier la configuration par répertoire (.htaccess) ou pour des applications historiques qui le supposent. La suite du guide privilégie Nginx et donne les équivalents Apache aux étapes clés.

2. Installation

Nginx

# Debian / Ubuntu
sudo apt update
sudo apt install nginx

# RHEL / Rocky / Alma
sudo dnf install nginx
sudo systemctl enable --now nginx

# Vérifier que le service tourne
systemctl status nginx
curl -I http://localhost

Apache

# Debian / Ubuntu (le paquet et le service s'appellent apache2)
sudo apt install apache2

# RHEL / Rocky / Alma (le paquet et le service s'appellent httpd)
sudo dnf install httpd
sudo systemctl enable --now httpd

N’oubliez pas d’ouvrir le pare-feu :

# Ubuntu avec ufw
sudo ufw allow "Nginx Full"

# RHEL avec firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

3. Arborescence de Configuration

Nginx

/etc/nginx/
├── nginx.conf              # configuration principale
├── conf.d/                 # fichiers .conf inclus automatiquement
├── sites-available/        # vos vhosts (Debian/Ubuntu)
├── sites-enabled/          # liens symboliques vers les vhosts actifs
└── snippets/               # fragments réutilisables (SSL, etc.)

Sur Debian/Ubuntu, on écrit chaque site dans sites-available/ puis on l’active par un lien symbolique dans sites-enabled/. Sur RHEL, cette convention n’existe pas : déposez vos fichiers directement dans conf.d/.

# Activer un site (Debian/Ubuntu)
sudo ln -s /etc/nginx/sites-available/monsite.conf /etc/nginx/sites-enabled/

# Désactiver un site : supprimer le lien, jamais le fichier source
sudo rm /etc/nginx/sites-enabled/monsite.conf

Apache

/etc/apache2/                     # Debian/Ubuntu (RHEL : /etc/httpd/)
├── apache2.conf                  # configuration principale
├── sites-available/              # vhosts disponibles
├── sites-enabled/                # vhosts actifs
├── mods-available/               # modules disponibles
└── mods-enabled/                 # modules actifs

Apache fournit des commandes dédiées à l’activation :

sudo a2ensite monsite.conf        # activer un vhost
sudo a2dissite monsite.conf       # désactiver
sudo a2enmod rewrite ssl headers  # activer des modules

4. Virtual Hosts et Server Blocks

Un même serveur peut héberger plusieurs sites, distingués par leur nom de domaine. Nginx parle de « server blocks », Apache de « virtual hosts ».

Server block Nginx complet

# /etc/nginx/sites-available/monsite.conf
server {
    listen 80;
    listen [::]:80;

    server_name monsite.example.com;

    root /var/www/monsite;
    index index.html index.htm;

    # Journaux dédiés au site
    access_log /var/log/nginx/monsite.access.log;
    error_log  /var/log/nginx/monsite.error.log;

    location / {
        # Servir le fichier, sinon le répertoire, sinon 404
        try_files $uri $uri/ =404;
    }

    # Bloquer l'accès aux fichiers cachés (.git, .env...)
    location ~ /\. {
        deny all;
    }
}

# Créer la racine du site et une page de test
sudo mkdir -p /var/www/monsite
echo "<h1>Bienvenue sur monsite</h1>" | sudo tee /var/www/monsite/index.html
sudo chown -R www-data:www-data /var/www/monsite

# Activer et recharger
sudo ln -s /etc/nginx/sites-available/monsite.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Virtual host Apache équivalent

# /etc/apache2/sites-available/monsite.conf
<VirtualHost *:80>
    ServerName monsite.example.com
    DocumentRoot /var/www/monsite

    ErrorLog ${APACHE_LOG_DIR}/monsite.error.log
    CustomLog ${APACHE_LOG_DIR}/monsite.access.log combined

    <Directory /var/www/monsite>
        Options -Indexes
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

sudo a2ensite monsite.conf
sudo apachectl configtest && sudo systemctl reload apache2

5. HTTPS avec Let’s Encrypt

Un site sans HTTPS n’est plus acceptable : navigateurs et moteurs de recherche pénalisent le HTTP. Let’s Encrypt fournit des certificats gratuits, et certbot automatise tout, du défi de validation au renouvellement.

# Installation de certbot avec le plugin Nginx
sudo apt install certbot python3-certbot-nginx
# (Apache : python3-certbot-apache ; RHEL : via EPEL)

# Obtenir le certificat ET modifier la configuration automatiquement
sudo certbot --nginx -d monsite.example.com

# Vérifier le renouvellement automatique (timer systemd)
systemctl list-timers | grep certbot
sudo certbot renew --dry-run

Prérequis : le domaine doit pointer vers l’IP publique du serveur (enregistrement DNS A/AAAA) et le port 80 doit être joignable pour le défi HTTP-01. Certbot ajoute la redirection HTTP vers HTTPS et configure les certificats dans votre server block :

# Extrait ajouté par certbot dans le server block
listen 443 ssl;
ssl_certificate     /etc/letsencrypt/live/monsite.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monsite.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;

Les certificats Let’s Encrypt sont valides 90 jours ; le timer systemd installé par le paquet les renouvelle automatiquement à l’approche de l’échéance. Vérifiez simplement le --dry-run une fois après l’installation.

6. Reverse Proxy vers une Application

Cas extrêmement courant : votre application (Node.js, Python, Go…) écoute sur un port local, et Nginx la publie sur le port 443 en gérant TLS, la compression et les logs.

# /etc/nginx/sites-available/app.conf
# Regroupement des backends (permet le load balancing plus tard)
upstream mon_app {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://mon_app;

        # Transmettre les informations du client à l'application
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Support des WebSockets
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Délais raisonnables
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
    }
}

Les en-têtes X-Forwarded-* sont essentiels : sans eux, votre application voit toutes les requêtes venir de 127.0.0.1 et croit être en HTTP. Sur la famille Red Hat, pensez aussi au booléen SELinux qui autorise Nginx à ouvrir des connexions sortantes :

sudo setsebool -P httpd_can_network_connect on

7. En-têtes de Sécurité

Quelques en-têtes HTTP protègent vos visiteurs contre le clickjacking, le sniffing MIME et les rétrogradations vers HTTP. À placer dans le server block (ou dans un snippet inclus par tous vos sites) :

# /etc/nginx/snippets/security-headers.conf
# HSTS : force HTTPS pendant 2 ans (ne l'activez qu'une fois HTTPS stable)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Interdit l'inclusion du site dans une iframe tierce (clickjacking)
add_header X-Frame-Options "SAMEORIGIN" always;

# Interdit au navigateur de deviner les types MIME
add_header X-Content-Type-Options "nosniff" always;

# Limite les informations de provenance transmises aux sites tiers
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Dans chaque server block HTTPS
include snippets/security-headers.conf;

Ajoutez une Content-Security-Policy adaptée à votre site quand vous connaissez précisément ses sources de scripts et de styles : c’est l’en-tête le plus efficace, mais un réglage trop strict casse le site. Testez votre configuration sur securityheaders.com et la partie TLS sur ssllabs.com.

Masquez aussi la version du serveur, information inutile à offrir aux scanners :

# Dans http {} de /etc/nginx/nginx.conf
server_tokens off;

8. Logs et Rotation

Lire les journaux

# Suivre le trafic en temps réel
sudo tail -f /var/log/nginx/access.log

# Suivre les erreurs
sudo tail -f /var/log/nginx/error.log

# Top 10 des IP les plus actives
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Compter les codes de réponse
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Rotation avec logrotate

Les paquets Nginx et Apache installent déjà une configuration logrotate ; vérifiez-la et adaptez la rétention à vos besoins :

# /etc/logrotate.d/nginx (fourni par le paquet, extrait)
/var/log/nginx/*.log {
    daily              # rotation quotidienne
    rotate 14          # conserver 14 archives
    compress           # compresser les archives
    delaycompress      # sauf la plus récente
    notifempty
    sharedscripts
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

# Tester sans attendre la nuit
sudo logrotate -d /etc/logrotate.d/nginx

Si vous créez des journaux par site comme dans nos exemples, le motif *.log les couvre automatiquement.

9. Tester et Recharger sans Coupure

Réflexe à ancrer définitivement : ne redémarrez jamais un serveur web sans avoir validé la configuration, et préférez toujours le rechargement au redémarrage.

# 1. Valider la syntaxe et la cohérence de la configuration
sudo nginx -t
# Apache : sudo apachectl configtest

# 2. Recharger : les workers finissent leurs requêtes en cours,
#    de nouveaux workers démarrent avec la nouvelle configuration.
#    Aucune connexion n'est coupée.
sudo systemctl reload nginx

# En une ligne, le rechargement conditionné au test
sudo nginx -t && sudo systemctl reload nginx

systemctl restart coupe brutalement les connexions en cours ; réservez-le aux cas où le rechargement ne suffit pas (changement de ports d’écoute, mise à jour du binaire).

10. Optimisations de Base

Compression gzip

# Dans http {} de /etc/nginx/nginx.conf
gzip on;
gzip_comp_level 5;              # bon compromis CPU / taille
gzip_min_length 256;            # inutile sous 256 octets
gzip_types text/plain text/css application/json application/javascript
           application/xml image/svg+xml;
# Les images JPEG/PNG/WebP sont déjà compressées : ne pas les lister

Cache des fichiers statiques

Demandez aux navigateurs de conserver longtemps les ressources qui ne changent pas :

# Dans le server block
location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;             # allège aussi les journaux
}

Cette stratégie suppose que vos fichiers changent de nom à chaque version (hachage dans le nom, ce que font tous les bundlers modernes). Sinon, réduisez la durée.

Processus workers

# Dans /etc/nginx/nginx.conf
worker_processes auto;          # un worker par cœur CPU : le bon réglage

events {
    worker_connections 1024;    # connexions simultanées par worker
}

auto est la valeur par défaut des paquets récents et convient à la quasi-totalité des cas. N’augmentez worker_connections que si vos journaux montrent la limite atteinte, et pensez alors à la limite de descripteurs de fichiers (worker_rlimit_nofile).

Bonnes Pratiques

• Un fichier de configuration par site, activé par lien symbolique ; ne touchez pas aux fichiers fournis par le paquet.
• Validez avec nginx -t ou apachectl configtest avant chaque rechargement, idéalement dans la même ligne de commande.
• Préférez reload à restart : zéro coupure pour vos visiteurs.
• HTTPS partout, redirection HTTP vers HTTPS, et un certbot renew --dry-run après l’installation pour valider le renouvellement automatique.
• Ajoutez les en-têtes de sécurité dans un snippet partagé et testez le résultat sur securityheaders.com.
• Journaux dédiés par site, rotation vérifiée, et un œil régulier sur error.log.
• Derrière un reverse proxy, transmettez toujours Host, X-Forwarded-For et X-Forwarded-Proto à l’application.
• Sauvegardez /etc/nginx (ou /etc/apache2) et /etc/letsencrypt : la configuration d’un serveur web se reconstruit en minutes quand elle est versionnée.

Conclusion

Vous disposez maintenant d’un serveur web complet : sites multiples en virtual hosts, HTTPS automatique avec Let’s Encrypt, reverse proxy vers vos applications, en-têtes de sécurité, journaux maîtrisés et optimisations de base. Nginx et Apache sont des logiciels d’une fiabilité remarquable : bien configurés, ils tournent des années sans intervention. Les étapes suivantes de votre progression : le load balancing entre plusieurs backends, la mise en cache avec proxy_cache, la limitation de débit (limit_req) contre les abus, et l’automatisation de toute cette configuration avec Ansible ou Terraform pour reconstruire votre serveur en une commande.