HTTPS for n8n: Setting Up a Reverse Proxy with Caddy or Nginx

You set up HTTPS for n8n by placing a reverse proxy such as Caddy or Nginx in front of the n8n instance. The proxy handles SSL encryption on the outside and forwards requests internally to n8n unencrypted. For this to work, n8n itself must know under which public address it is reachable, otherwise the application shows incorrect webhook URLs and triggers from external services fail silently. The variables responsible for this are called WEBHOOK_URL and N8N_PROXY_HOPS. As of: July 2026.

Why isn't a reverse proxy alone enough?

A reverse proxy alone is not enough because n8n assembles its URLs by default from the variables N8N_PROTOCOL, N8N_HOST and N8N_PORT, which by default point to http, localhost and the internal port 5678. If n8n runs behind Caddy or Nginx, the application internally still only sees the HTTP connection on port 5678, while users and external services address the instance via HTTPS on port 443 under your own domain. The proxy must pass this discrepancy between the internal and external view on to n8n. The official n8n documentation on webhook URLs behind reverse proxies describes exactly this problem as the starting point of the configuration.

What is the WEBHOOK_URL trap?

The WEBHOOK_URL trap occurs when n8n is reachable via HTTPS, but the interface and the registration of new webhooks still use an internal or incorrect address. For you as the operator, this often looks harmless at first, because the editor loads normally in the browser. However, as soon as an external service such as a form tool or a payment platform tries to call the registered webhook, the request fails because the stored URL is not reachable from outside. According to the documentation, you solve this by manually setting WEBHOOK_URL to your complete external address, for example https://n8n.your-domain.com/, and N8N_PROXY_HOPS to the number of upstream proxies, so 1 in single-proxy setups.

Which headers must your proxy pass on to n8n?

Your proxy must pass at least three headers on to n8n for the WEBHOOK_URL setting to take effect at all. The n8n documentation specifically names the following headers for this.

• X-Forwarded-Proto: tells n8n whether the original request arrived at the proxy via HTTP or HTTPS.
• X-Forwarded-Host: passes on the hostname called by the user, i.e. your actual domain instead of the internal name.
• X-Forwarded-For: passes on the actual client IP, which would otherwise disappear behind the proxy's IP address.

If these headers are missing or N8N_PROXY_HOPS is not set correctly, n8n ignores the forwarded information and falls back to the internal default values, even if WEBHOOK_URL is set.

Caddy or Nginx: What fits your n8n setup?

For n8n itself, it does not matter whether you use Caddy or Nginx as a reverse proxy, as long as the headers mentioned arrive correctly and WEBHOOK_URL and N8N_PROXY_HOPS are set. The difference lies in the operational effort: Caddy issues and renews certificates automatically, whereas with Nginx you organize the certificate issuance yourself, for example via Certbot, and enter the headers manually in the server configuration. Alternatively, the n8n documentation on setting up SSL also describes a way entirely without a separate reverse proxy: you set N8N_SSL_CERT and N8N_SSL_KEY so that n8n reads the certificate and key directly itself. In that case, however, you also bear the responsibility for timely renewal yourself, which usually happens automatically with Caddy.

Why does login sometimes fail despite a correct certificate?

Login sometimes fails despite a correct certificate because n8n marks session cookies as "secure" by default, controlled via N8N_SECURE_COOKIE with a default value of true. A cookie marked as secure is only transmitted by the browser over an actually encrypted HTTPS connection. If the HTTPS information does not reach n8n via X-Forwarded-Proto, n8n considers the connection internally unencrypted and discards the cookie, causing the login form to fail without an obvious error message. WEBHOOK_URL, the proxy headers and N8N_SECURE_COOKIE are technically interconnected and should therefore always be checked together.

If this is too error-prone for you for production use, at NordFlux we take care of the hosting setup as part of our n8n services at a fixed price, including the HTTPS and webhook configuration described here.

Frequently asked questions about HTTPS for n8n

Do I need to set WEBHOOK_URL manually if my proxy already terminates SSL?

Yes, you need to set WEBHOOK_URL manually in almost every reverse proxy setup, because otherwise n8n does not know the external address. The proxy does terminate the encryption, but this does not change the fact that n8n internally continues to use the default values from N8N_PROTOCOL, N8N_HOST and N8N_PORT. Only the explicit WEBHOOK_URL ensures that registered webhooks contain the address that is actually reachable.

What is the difference between a reverse proxy and direct SSL certificates in n8n?

The difference lies in who terminates the encryption: with a reverse proxy such as Caddy or Nginx, the proxy handles the certificate, and communication with n8n runs internally via HTTP. With direct certificates, n8n reads the certificate and key itself via N8N_SSL_CERT and N8N_SSL_KEY, and you manage the renewal yourself.

How many proxy hops do I enter for N8N_PROXY_HOPS if Cloudflare runs in front of Caddy or Nginx?

For a single reverse proxy in front of n8n, you enter 1; for an additional upstream layer such as Cloudflare, correspondingly higher. The value must correspond exactly to the number of stations the request passes through, otherwise n8n evaluates the X-Forwarded headers incorrectly. If in doubt, test with an incoming webhook call which client IP n8n actually logs.

Can I also run n8n via HTTPS without my own domain?

Technically, Caddy and most free certificate authorities require a domain with a public DNS entry; a plain IP address is not sufficient for this in practice. For production webhooks from external services, you need a stable, publicly reachable address anyway, which is why a dedicated subdomain for n8n is advisable independently of the certificate issue as well.