Nginx comme reverse proxy pour une stack Laravel + Node

Une application Laravel s’accompagne de plus en plus souvent d’un service Node.js à côté — un serveur WebSocket pour du temps réel, un microservice, un outil de build. Faire cohabiter les deux proprement derrière un seul nom de domaine, sans exposer des ports différents à l’utilisateur, est le rôle naturel d’un reverse proxy Nginx.

Sommaire

1. Pourquoi un reverse proxy plutôt que des ports exposés
2. Structure d’une configuration Nginx à deux backends
3. Le cas particulier du WebSocket
4. Terminer le TLS au niveau de Nginx
5. En-têtes à transmettre aux applications
6. Pièges fréquents

Pourquoi un reverse proxy plutôt que des ports exposés

Exposer Laravel sur le port 80 et un service Node sur le port 3000 directement au public multiplie les certificats TLS à gérer, complique le pare-feu, et expose inutilement l’implémentation interne dans les URLs (domaine.com:3000). Un reverse proxy Nginx en frontal reçoit tout le trafic sur les ports standards (80/443) et redirige en interne vers le bon service selon le chemin ou le sous-domaine, ce qui reste totalement invisible côté client.

Structure d’une configuration Nginx à deux backends

Une configuration typique déclare un bloc location par service : location / pointe vers PHP-FPM pour Laravel (via fastcgi_pass), tandis que location /realtime/ ou un sous-domaine dédié (ws.domaine.com) redirige vers le service Node avec proxy_pass http://127.0.0.1:3000;. Cette séparation par chemin ou sous-domaine permet à chaque service d’évoluer indépendamment, sans que l’un ne bloque les déploiements de l’autre.

Le cas particulier du WebSocket

Une connexion WebSocket démarre comme une requête HTTP classique puis « upgrade » vers un protocole persistant — Nginx doit être configuré explicitement pour transmettre cet upgrade, sinon la connexion échoue silencieusement ou retombe en polling dégradé. Cela demande deux en-têtes précis dans le bloc location concerné : proxy_set_header Upgrade $http_upgrade; et proxy_set_header Connection "upgrade";, en plus d’un proxy_http_version 1.1; (le protocole HTTP/1.0 ne supporte pas l’upgrade de connexion).

Terminer le TLS au niveau de Nginx

Le certificat TLS (Let’s Encrypt ou autre) se configure une seule fois, au niveau de Nginx, qui déchiffre le trafic entrant avant de le retransmettre en clair vers Laravel et Node sur le réseau interne du serveur. Cette approche — dite de terminaison TLS — évite de dupliquer la gestion des certificats dans chaque application et centralise le renouvellement (via certbot, par exemple) à un seul endroit.

En-têtes à transmettre aux applications

Sans configuration explicite, une application derrière un reverse proxy voit l’adresse IP interne de Nginx plutôt que celle du visiteur réel, et peut perdre l’information du protocole d’origine (HTTP vs HTTPS). Les en-têtes X-Real-IP, X-Forwarded-For et X-Forwarded-Proto doivent être transmis explicitement, et Laravel doit être configuré pour leur faire confiance via le middleware TrustProxies (sans quoi request()->ip() et la détection HTTPS restent incorrectes).

Pièges fréquents

Les erreurs les plus courantes : oublier proxy_http_version 1.1 pour le WebSocket (l’upgrade échoue silencieusement) ; ne pas configurer TrustProxies côté Laravel après avoir mis en place le reverse proxy, ce qui casse la détection HTTPS et génère des redirections en boucle ; et laisser un timeout Nginx par défaut trop court pour une connexion WebSocket longue durée, qui la coupe après quelques dizaines de secondes d’inactivité (proxy_read_timeout à ajuster explicitement).

Chez Any In IT, cette architecture reverse proxy est celle que nous mettons en place quand un projet Laravel a besoin de fonctionnalités temps réel ou d’un microservice complémentaire, sans complexifier l’hébergement pour l’utilisateur final.