Nginx et Apache : fonctionnement et implications réseau

Nginx et Apache HTTP Server sont les deux serveurs web libres les plus répandus. On les présente souvent comme des logiciels d'hébergement de sites, mais pour un administrateur réseau, ils sont aussi des terminaisons TCP et TLS, des proxys inverses et des répartiteurs de charge. Leur configuration influence directement les flux, les journaux, la sécurité et les performances.

Objectif : comprendre l'architecture des deux serveurs, la mise en place d'un proxy inverse et ses conséquences sur l'adressage, les délais et le diagnostic.

Deux architectures différentes

Apache HTTP Server

Apache traite les connexions au moyen de modules multi-processus (MPM) :

• prefork : un processus par connexion, sans fils d'exécution ; historiquement requis par mod_php ;
• worker : plusieurs processus, chacun avec plusieurs fils ;
• event : variante de worker qui gère efficacement les connexions persistantes inactives. C'est le MPM recommandé aujourd'hui, avec PHP exécuté par PHP-FPM.

Apache se distingue par sa configuration décentralisée possible via les fichiers .htaccess, très appréciée en hébergement mutualisé, au prix d'un coût de lecture à chaque requête.

Nginx

Nginx repose sur une architecture événementielle : un petit nombre de processus worker, chacun gérant des milliers de connexions de façon asynchrone. Cette conception le rend très efficace pour servir des fichiers statiques, terminer TLS et relayer des connexions. Il n'interprète pas PHP lui-même : il transmet les requêtes à PHP-FPM via FastCGI.

Les deux peuvent coexister : Nginx en frontal, Apache en arrière-plan.

Écoute et hôtes virtuels

Un serveur web écoute sur une adresse et un port, puis sélectionne le site à servir d'après l'en-tête Host (HTTP/1.1) ou le champ SNI de la poignée de main TLS.

# Nginx — /etc/nginx/sites-available/exemple.conf (exemple)
server {
    listen 80;
    listen [::]:80;
    server_name www.exemple.fr;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name www.exemple.fr;
    ssl_certificate     /etc/ssl/exemple/fullchain.pem;
    ssl_certificate_key /etc/ssl/exemple/privkey.pem;
    root /var/www/exemple;
}

La directive http2 on; est la syntaxe des versions récentes de Nginx (1.25.1 et suivantes) ; les versions plus anciennes utilisent listen 443 ssl http2;.

# Apache — /etc/apache2/sites-available/exemple.conf (exemple)
<VirtualHost *:443>
    ServerName www.exemple.fr
    DocumentRoot /var/www/exemple
    SSLEngine on
    SSLCertificateFile    /etc/ssl/exemple/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/exemple/privkey.pem
    Protocols h2 http/1.1
</VirtualHost>

Bonne pratique : définissez un hôte virtuel par défaut qui répond aux requêtes portant un nom inconnu (ou une adresse IP brute) avec un code 444/403 plutôt que de servir le premier site venu.

Le proxy inverse

Un proxy inverse reçoit les requêtes des clients et les transmet à un ou plusieurs serveurs internes. Il permet de centraliser TLS, de masquer l'architecture interne, de mettre en cache et de répartir la charge.

upstream app_backend {
    server 10.10.20.21:8080 max_fails=3 fail_timeout=10s;
    server 10.10.20.22:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;
}
server {
    listen 443 ssl;
    server_name app.exemple.fr;
    # certificats...
    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

Conséquence n° 1 : l'adresse source change

Vu du serveur applicatif, toutes les connexions proviennent de l'adresse du proxy. Pour connaître l'adresse réelle du client, le proxy ajoute l'en-tête X-Forwarded-For (ou l'en-tête standardisé Forwarded, RFC 7239). Le serveur d'arrière-plan doit être configuré pour faire confiance à cet en-tête uniquement lorsqu'il provient du proxy, sans quoi un client peut falsifier son adresse :

# Sur un Nginx d'arrière-plan
set_real_ip_from 10.10.20.5;
real_ip_header X-Forwarded-For;

# Sur un Apache d'arrière-plan (mod_remoteip)
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 10.10.20.5

Conséquence n° 2 : le pare-feu

Les serveurs applicatifs ne doivent accepter les connexions que depuis le proxy. Un serveur d'arrière-plan joignable directement contourne la terminaison TLS, les en-têtes de sécurité et la journalisation centralisée.

Conséquence n° 3 : les délais d'attente

Chaque maillon a ses propres délais : client → proxy, proxy → application, application → base de données. Un délai trop court côté proxy produit des erreurs 504, alors que l'application fonctionne mais répond lentement.

Diagnostiquer les erreurs 502 et 504

Commandes utiles :

sudo nginx -t && sudo systemctl reload nginx     # tester puis recharger
sudo apachectl configtest                        # "Syntax OK"
sudo ss -tlnp | grep -E ':(80|443|8080)'
curl -sv http://10.10.20.21:8080/ -o /dev/null   # tester l'arrière-plan depuis le proxy
sudo tail -f /var/log/nginx/error.log

Sur RHEL et dérivés, si Nginx ne peut pas se connecter à un port d'arrière-plan, vérifiez SELinux :

sudo setsebool -P httpd_can_network_connect on

TLS : terminer, relayer ou rechiffrer

• Terminaison TLS sur le proxy, HTTP en clair vers l'arrière-plan : simple, adapté si le réseau interne est maîtrisé et segmenté.
• Rechiffrement (TLS jusqu'à l'arrière-plan) : recommandé lorsque le réseau interne n'est pas de confiance ou pour des exigences réglementaires.
• Relais TCP (passthrough) : le proxy ne déchiffre pas ; il ne peut alors ni lire ni modifier les en-têtes HTTP.

Voir TLS et certificats : sécurisation des communications.

Erreurs courantes

• Faire confiance à X-Forwarded-For venant de n'importe qui.
• Laisser les serveurs d'arrière-plan joignables directement.
• Oublier les journaux : sans l'adresse réelle du client, l'analyse d'incident devient impossible.
• Recharger sans nginx -t ou apachectl configtest.
• Ignorer IPv6 : un site qui écoute en IPv4 seulement alors que le DNS publie un enregistrement AAAA devient injoignable pour une partie des clients.

Implications de sécurité

Masquez les versions (server_tokens off; sous Nginx, ServerTokens Prod sous Apache), ajoutez les en-têtes de sécurité pertinents (HSTS une fois HTTPS stabilisé, X-Content-Type-Options, politique de contenu adaptée), limitez les méthodes HTTP et la taille des requêtes, et appliquez une limitation de débit sur les points sensibles (connexion, API). Un pare-feu applicatif (WAF) peut compléter ces mesures sans les remplacer.

Conclusion

Nginx et Apache sont des maillons réseau à part entière : ils écoutent, terminent TLS, relaient et imposent des délais. En configurant correctement les en-têtes d'adresse client, le filtrage vers l'arrière-plan et les délais, vous éliminez la plupart des erreurs 502/504. Pour la redondance du frontal lui-même, voir Haute disponibilité et redondance des infrastructures.

Références

• Documentation officielle Nginx — Module ngx_http_proxy_module
• Documentation Apache HTTP Server 2.4 — Modules MPM
• Documentation Apache — mod_remoteip
• RFC 7239 — Forwarded HTTP Extension
• RFC 9110 — HTTP Semantics