HTTPS para n8n: configurar un proxy inverso con Caddy o Nginx

Usted configura HTTPS para n8n colocando un proxy inverso como Caddy o Nginx delante de la instancia de n8n. El proxy se encarga del cifrado SSL hacia el exterior y reenvía las solicitudes internamente a n8n sin cifrar. Para que esto funcione, n8n debe saber bajo qué dirección pública es accesible, de lo contrario la aplicación muestra URL de webhook incorrectas y los disparadores de servicios externos fallan sin efecto. Las variables responsables de esto se llaman WEBHOOK_URL y N8N_PROXY_HOPS. Estado: julio de 2026.

¿Por qué no basta con un proxy inverso por sí solo?

Un proxy inverso por sí solo no es suficiente, porque n8n compone sus URL por defecto a partir de las variables N8N_PROTOCOL, N8N_HOST y N8N_PORT, que por defecto apuntan a http, localhost y el puerto interno 5678. Si n8n se ejecuta detrás de Caddy o Nginx, la aplicación sigue viendo internamente solo la conexión HTTP en el puerto 5678, mientras que los usuarios y los servicios externos acceden a la instancia mediante HTTPS en el puerto 443 bajo su propio dominio. El proxy debe transmitir esta diferencia entre la vista interna y externa a n8n. La documentación oficial de n8n sobre URL de webhook detrás de proxies inversos describe exactamente este problema como punto de partida de la configuración.

¿Qué es la trampa de WEBHOOK_URL?

La trampa de WEBHOOK_URL ocurre cuando n8n es accesible mediante HTTPS, pero la interfaz y el registro de nuevos webhooks siguen utilizando una dirección interna o incorrecta. Para usted como operador, esto suele parecer inofensivo al principio, porque el editor se carga con normalidad en el navegador. Sin embargo, en cuanto un servicio externo, como una herramienta de formularios o una plataforma de pago, intenta llamar al webhook registrado, la solicitud falla porque la URL almacenada no es accesible desde el exterior. Según la documentación, esto se soluciona configurando manualmente WEBHOOK_URL con su dirección externa completa, por ejemplo https://n8n.su-dominio.es/, y N8N_PROXY_HOPS con el número de proxies previos, es decir, 1 en configuraciones de proxy único.

¿Qué cabeceras debe reenviar su proxy a n8n?

Su proxy debe reenviar al menos tres cabeceras a n8n para que la configuración de WEBHOOK_URL surta efecto. La documentación de n8n menciona concretamente las siguientes cabeceras para ello.

• X-Forwarded-Proto: indica a n8n si la solicitud original llegó al proxy mediante HTTP o HTTPS.
• X-Forwarded-Host: transmite el nombre de host que el usuario ha solicitado, es decir, su dominio real en lugar del nombre interno.
• X-Forwarded-For: transmite la IP real del cliente, que de otro modo desaparecería detrás de la dirección IP del proxy.

Si faltan estas cabeceras o N8N_PROXY_HOPS no está configurado correctamente, n8n ignora la información reenviada y vuelve a los valores internos por defecto, incluso si WEBHOOK_URL está configurado.

Caddy o Nginx: ¿qué se adapta a su configuración de n8n?

Para n8n en sí, no importa si utiliza Caddy o Nginx como proxy inverso, siempre que las cabeceras mencionadas lleguen correctamente y WEBHOOK_URL y N8N_PROXY_HOPS estén configurados. La diferencia radica en el esfuerzo operativo: Caddy emite y renueva certificados automáticamente, mientras que con Nginx usted organiza la emisión del certificado usted mismo, por ejemplo mediante Certbot, e introduce las cabeceras manualmente en la configuración del servidor. Alternativamente, la documentación de n8n sobre la configuración de SSL también describe una forma completamente sin un proxy inverso independiente: usted configura N8N_SSL_CERT y N8N_SSL_KEY para que n8n lea directamente el certificado y la clave por sí mismo. Sin embargo, en ese caso también asume usted mismo la responsabilidad de la renovación oportuna, lo cual con Caddy suele ocurrir automáticamente.

¿Por qué a veces falla el inicio de sesión a pesar de un certificado correcto?

El inicio de sesión a veces falla a pesar de un certificado correcto porque n8n marca las cookies de sesión como "secure" de forma predeterminada, controlado mediante N8N_SECURE_COOKIE con un valor por defecto de true. Una cookie marcada como secure solo se transmite por el navegador a través de una conexión HTTPS realmente cifrada. Si la información HTTPS no llega a n8n a través de X-Forwarded-Proto, n8n considera internamente que la conexión no está cifrada y descarta la cookie; el formulario de inicio de sesión falla entonces sin un mensaje de error evidente. WEBHOOK_URL, las cabeceras del proxy y N8N_SECURE_COOKIE están técnicamente relacionados y por ello siempre deben revisarse juntos.

Si esto le resulta demasiado propenso a errores para el uso en producción, en NordFlux nos encargamos de la configuración del hosting dentro de nuestros servicios de n8n a precio fijo, incluyendo la configuración de HTTPS y webhooks aquí descrita.

Preguntas frecuentes sobre HTTPS para n8n

¿Debo configurar WEBHOOK_URL manualmente si mi proxy ya termina SSL?

Sí, debe configurar WEBHOOK_URL manualmente en casi cualquier configuración de proxy inverso, porque de lo contrario n8n no conoce la dirección externa. El proxy sí termina el cifrado, pero eso no cambia el hecho de que n8n siga usando internamente los valores por defecto de N8N_PROTOCOL, N8N_HOST y N8N_PORT. Solo la WEBHOOK_URL explícita garantiza que los webhooks registrados contengan la dirección que realmente es accesible.

¿Cuál es la diferencia entre un proxy inverso y certificados SSL directos en n8n?

La diferencia radica en quién termina el cifrado: con un proxy inverso como Caddy o Nginx, el proxy se encarga del certificado, y la comunicación con n8n se realiza internamente mediante HTTP. Con certificados directos, n8n lee el certificado y la clave por sí mismo mediante N8N_SSL_CERT y N8N_SSL_KEY, y usted gestiona la renovación de forma independiente.

¿Cuántos saltos de proxy debo indicar en N8N_PROXY_HOPS si Cloudflare está delante de Caddy o Nginx?

Para un único proxy inverso delante de n8n, indique 1; para una capa adicional previa como Cloudflare, un valor correspondientemente más alto. El valor debe corresponder exactamente al número de estaciones que atraviesa la solicitud, de lo contrario n8n evalúa incorrectamente las cabeceras X-Forwarded. En caso de duda, pruebe con una llamada de webhook entrante qué IP de cliente registra realmente n8n.

¿Puedo operar n8n con HTTPS sin un dominio propio?

Técnicamente, Caddy y la mayoría de las autoridades de certificación gratuitas requieren un dominio con una entrada DNS pública; una simple dirección IP no es suficiente para ello en la práctica. Para los webhooks de producción de servicios externos, de todos modos necesita una dirección estable y accesible públicamente, por lo que se recomienda un subdominio propio para n8n independientemente del tema del certificado.