HTTPS pour n8n : configurer un reverse proxy avec Caddy ou Nginx

Vous configurez HTTPS pour n8n en plaçant un reverse proxy tel que Caddy ou Nginx devant l'instance n8n. Le proxy prend en charge le chiffrement SSL vers l'extérieur et transmet les requêtes en interne à n8n sans chiffrement. Pour que cela fonctionne, n8n doit savoir lui-même sous quelle adresse publique il est accessible, sinon l'application affiche des URL de webhook incorrectes et les déclencheurs des services externes échouent sans effet. Les variables responsables de cela s'appellent WEBHOOK_URL et N8N_PROXY_HOPS. État : juillet 2026.

Pourquoi un reverse proxy seul ne suffit-il pas ?

Un reverse proxy seul ne suffit pas, car n8n compose par défaut ses URL à partir des variables N8N_PROTOCOL, N8N_HOST et N8N_PORT, qui pointent par défaut vers http, localhost et le port interne 5678. Si n8n s'exécute derrière Caddy ou Nginx, l'application ne voit en interne toujours que la connexion HTTP sur le port 5678, tandis que les utilisateurs et les services externes accèdent à l'instance via HTTPS sur le port 443 sous votre propre domaine. Le proxy doit transmettre cette différence entre la vue interne et externe à n8n. La documentation officielle de n8n sur les URL de webhook derrière des reverse proxys décrit précisément ce problème comme point de départ de la configuration.

Qu'est-ce que le piège WEBHOOK_URL ?

Le piège WEBHOOK_URL survient lorsque n8n est certes accessible via HTTPS, mais que l'interface et l'enregistrement de nouveaux webhooks utilisent toujours une adresse interne ou incorrecte. Pour vous en tant qu'exploitant, cela paraît souvent inoffensif au premier abord, car l'éditeur se charge normalement dans le navigateur. Mais dès qu'un service externe, comme un outil de formulaire ou une plateforme de paiement, tente d'appeler le webhook enregistré, la requête échoue, car l'URL enregistrée n'est pas accessible depuis l'extérieur. Selon la documentation, vous résolvez cela en définissant manuellement WEBHOOK_URL sur votre adresse externe complète, par exemple https://n8n.votre-domaine.fr/, et N8N_PROXY_HOPS sur le nombre de proxys en amont, donc 1 dans les configurations à proxy unique.

Quels en-têtes votre proxy doit-il transmettre à n8n ?

Votre proxy doit transmettre au moins trois en-têtes à n8n pour que le paramètre WEBHOOK_URL prenne effet. La documentation n8n cite concrètement les en-têtes suivants à cet effet.

• X-Forwarded-Proto: indique à n8n si la requête d'origine est arrivée au proxy en HTTP ou en HTTPS.
• X-Forwarded-Host: transmet le nom d'hôte appelé par l'utilisateur, c'est-à-dire votre domaine réel au lieu du nom interne.
• X-Forwarded-For: transmet l'adresse IP réelle du client, qui disparaîtrait sinon derrière l'adresse IP du proxy.

Si ces en-têtes sont absents ou si N8N_PROXY_HOPS n'est pas défini correctement, n8n ignore les informations transmises et revient aux valeurs par défaut internes, même si WEBHOOK_URL est défini.

Caddy ou Nginx : que convient à votre configuration n8n ?

Pour n8n lui-même, peu importe que vous utilisiez Caddy ou Nginx comme reverse proxy, tant que les en-têtes mentionnés arrivent correctement et que WEBHOOK_URL ainsi que N8N_PROXY_HOPS sont définis. La différence réside dans l'effort d'exploitation : Caddy délivre et renouvelle automatiquement les certificats, tandis qu'avec Nginx vous organisez vous-même la délivrance des certificats, par exemple via Certbot, et saisissez manuellement les en-têtes dans la configuration du serveur. Autrement, la documentation n8n sur la configuration de SSL décrit également une méthode sans reverse proxy séparé : vous définissez N8N_SSL_CERT et N8N_SSL_KEY afin que n8n lise directement lui-même le certificat et la clé. Vous assumez alors vous-même la responsabilité du renouvellement en temps voulu, ce qui se fait généralement automatiquement avec Caddy.

Pourquoi la connexion échoue-t-elle parfois malgré un certificat correct ?

La connexion échoue parfois malgré un certificat correct, car n8n marque par défaut les cookies de session comme "secure", contrôlé via N8N_SECURE_COOKIE avec une valeur par défaut de true. Un cookie marqué comme secure n'est transmis par le navigateur que via une connexion HTTPS réellement chiffrée. Si l'information HTTPS n'atteint pas n8n via X-Forwarded-Proto, n8n considère en interne la connexion comme non chiffrée et rejette le cookie ; le formulaire de connexion échoue alors sans message d'erreur évident. WEBHOOK_URL, les en-têtes du proxy et N8N_SECURE_COOKIE sont techniquement liés et doivent donc toujours être vérifiés ensemble.

Si cela vous semble trop sujet aux erreurs pour une utilisation en production, chez NordFlux nous prenons en charge la configuration de l'hébergement dans le cadre de nos services n8n à prix fixe, y compris la configuration HTTPS et webhook décrite ici.

Questions fréquentes sur HTTPS pour n8n

Dois-je définir WEBHOOK_URL manuellement si mon proxy termine déjà SSL ?

Oui, vous devez définir WEBHOOK_URL manuellement dans presque toutes les configurations de reverse proxy, car sinon n8n ne connaît pas l'adresse externe. Le proxy termine certes le chiffrement, mais cela ne change rien au fait qu'en interne n8n continue d'utiliser les valeurs par défaut de N8N_PROTOCOL, N8N_HOST et N8N_PORT. Seule la définition explicite de WEBHOOK_URL garantit que les webhooks enregistrés contiennent l'adresse réellement accessible.

Quelle est la différence entre un reverse proxy et des certificats SSL directs dans n8n ?

La différence réside dans qui termine le chiffrement : avec un reverse proxy comme Caddy ou Nginx, le proxy prend en charge le certificat, la communication vers n8n se fait en interne via HTTP. Avec des certificats directs, n8n lit lui-même le certificat et la clé via N8N_SSL_CERT et N8N_SSL_KEY et vous gérez vous-même le renouvellement.

Combien de sauts de proxy dois-je indiquer pour N8N_PROXY_HOPS si Cloudflare se trouve devant Caddy ou Nginx ?

Pour un seul reverse proxy devant n8n, vous indiquez 1, pour un niveau supplémentaire en amont comme Cloudflare, une valeur plus élevée en conséquence. La valeur doit correspondre exactement au nombre d'étapes que traverse la requête, sinon n8n évalue incorrectement les en-têtes X-Forwarded. En cas de doute, testez avec un appel de webhook entrant quelle adresse IP client n8n enregistre réellement.

Puis-je aussi exploiter n8n en HTTPS sans domaine propre ?

Techniquement, Caddy et la plupart des autorités de certification gratuites nécessitent un domaine avec une entrée DNS publique, une simple adresse IP ne suffit pas en pratique. Pour des webhooks en production provenant de services externes, vous avez de toute façon besoin d'une adresse stable et accessible publiquement, c'est pourquoi un sous-domaine dédié pour n8n est recommandé indépendamment de la question du certificat.