Google OAuth redirect_uri_mismatch en instancia de staging — la aplicación OAuth funciona bien en producción

<n8n version: 2.20.7
Basedatos: SQLite (predeterminado)
Ejecución mediante: Docker (autohospedado, Ubuntu 24.04 en DigitalOcean)
Proxy inverso: nginx con SSL mediante Certbot/Let’s Encrypt
Problema:
Tengo dos instancias de n8n autohospedadas:
Producción: n8n.revvittsystems.com — OAuth de Gmail funciona perfectamente, incluida la creación de nuevas credenciales
Stagin: staging.revvittsystems.com — OAuth de Gmail falla con Error 400: redirect_uri_mismatch cada vez
Ambas instancias ejecutan n8n 2.20.7 en Docker con proxy inverso nginx. Ambas utilizan la misma aplicación OAuth de Google Cloud (mismo ID de cliente/Secreto). También intenté crear un cliente OAuth completamente separado solo con el URI de redireccionamiento de staging — mismo error.
Lo que he confirmado:
El URI de redireccionamiento que se muestra en la interfaz de usuario de n8n staging es https://staging.revvittsystems.com/rest/oauth2-credential/callback
Este URI exacto está registrado en Google Cloud Console bajo URI de redireccionamiento autorizados
Decodifiqué la URL de error de Google y confirmé que el redirect_uri que n8n envía es https://staging.revvittsystems.com/rest/oauth2-credential/callback — coincide exactamente
X-Forwarded-Proto $scheme está configurado en nginx para que n8n genere correctamente el prefijo https://
La aplicación se publica en Producción en la pantalla de consentimiento OAuth de Google
Probado en ventana incógnita — mismo error
Crear una nueva credencial en producción funciona inmediatamente — la aplicación OAuth de Google en sí está bien
Crear un cliente OAuth completamente nuevo solo para staging también falla con el mismo error
Archivo .env de staging:
N8N_HOST=staging.revvittsystems.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
GENERIC_TIMEZONE=America/New_York
Configuración nginx de staging:
server {
listen 443 ssl;
server_name staging.revvittsystems.com;
ssl_certificate /etc/letsencrypt/live/staging.revvittsystems.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/staging.revvittsystems.com/privkey.pem;
large_client_header_buffers 4 16k;
location / {
proxy_pass http://localhost:5678;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_buffer_size 16k;
proxy_buffers 4 16k;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Nota adicional: Al iniciar sesión como propietario/cuenta de administrador en staging, hacer clic en «Iniciar sesión con Google» genera un error 414 URI Too Long en su lugar (error conocido de n8n donde los ámbitos de administrador se añaden a la URL). Crear desde una cuenta de miembro no administrador supera el error 414 pero se encuentra con el redirect_uri_mismatch.
Pregunta: ¿Qué más podría causar redirect_uri_mismatch cuando el URI está confirmado como correcto y coincide exactamente? ¿Hay algo específico sobre el flujo OAuth de n8n 2.20.7 que pudiera causar esto en una instancia nueva?

Describe el problema/error/pregunta

¿Cuál es el mensaje de error (si lo hay)?

Por favor, comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte el resultado devuelto por el último nodo

Información sobre tu instalación de n8n

  • Versión de n8n:
  • BasedDatos (predeterminado: SQLite):
  • Configuración N8N_EXECUTIONS_PROCESS de n8n (predeterminado: own, main):
  • Ejecutar n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:

Hola @Sam_Rao, ¡bienvenido!
Creo que tu n8n_proxy_hops está sin configurar o no está configurado correctamente según tu setup. Esa variable de entorno debería verse así:

N8N_HOST=staging.revvittsystems.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_PROXY_HOPS=1
WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com/
GENERIC_TIMEZONE=America/New_York

y asegúrate de que tu configuración de Nginx también tenga estas cosas habilitadas:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;

Cuéntame cómo va después de reiniciar.

Hola @Sam_Rao

El error de desajuste de URI de redirección que experimentas en tu instancia de staging es un obstáculo común pero frustrante en los despliegues de n8n. Incluso cuando la URL parece idéntica, los servidores de autenticación de Google son extremadamente estrictos. El proceso requiere una coincidencia exacta, carácter por carácter, entre el valor definido en tu Consola de Google Cloud y el valor que n8n envía en su solicitud. Si hay incluso una única diferencia de carácter, como una barra diagonal final faltante, la autenticación será rechazada inmediatamente.

Una de las causas más frecuentes de este error, especialmente después de cambios de configuración, es el retraso de propagación global de Google. Incluso si has actualizado los URI de redirección autorizados en la Consola de Google Cloud, esos cambios pueden tardar varias horas en propagarse a través de la infraestructura de Google. Si recientemente modificaste estas configuraciones, la solución más probable es simplemente esperar unas horas e intentar de nuevo, ya que el sistema puede estar utilizando aún la configuración antigua.

También es vital verificar que las variables de entorno dentro de tu contenedor Docker coincidan con tus expectativas. Aunque tu archivo .env se ve correcto, es posible que el proceso n8n en ejecución tenga una configuración diferente debido al almacenamiento en caché o a cómo se inicializó el contenedor. Ejecutar un comando para imprimir las variables de entorno desde dentro del contenedor te ayudará a confirmar que los ajustes WEBHOOK_URL y N8N_PROTOCOL se aplican correctamente y no están usando valores internos incorrectos por defecto.

docker exec <container_id> env

También deberías examinar tu configuración de Nginx para detectar posibles conflictos. Aunque tus ajustes actuales son estándar, asegúrate de que encabezados como X-Forwarded-Proto y X-Forwarded-Host se pasen correctamente sin ser sobrescritos por otros servicios. Si estás utilizando capas adicionales como Cloudflare, verifica que no estén modificando ni eliminando estos encabezados antes de que lleguen a tu proxy inverso Nginx, ya que esto impediría que n8n genere la URL de redirección segura correcta.

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;

Con respecto a la configuración de la Consola de Google Cloud, asegúrate de que la pantalla de consentimiento de OAuth de tu proyecto esté configurada correctamente para el entorno de staging. Si tu aplicación está actualmente en la fase de pruebas, debes agregar explícitamente cualquier cuenta que estés utilizando para pruebas a la lista de «Usuarios de prueba» dentro de la consola. Además, asegúrate de que la configuración del proyecto no tenga restricciones de dominio que puedan causar que el dominio de staging se trate de manera diferente a tu entorno de producción.

Finalmente, el error 414 encontrado por tu cuenta de administrador indica que la URL de OAuth generada está superando los límites de caracteres típicos. Este es un problema conocido causado por la acumulación de permisos y datos de estado. Completar exitosamente la autenticación con una cuenta que no sea de administrador es la mejor manera de eludir esto, ya que permite que ocurra el protocolo de enlace inicial y establece las cookies de sesión necesarias para futuras interacciones. Comparar los parámetros de la URL generada lado a lado con tu configuración de consola sigue siendo la forma más definitiva de identificar cualquier discrepancia oculta.

¡Hola Anshul!

¡Gracias por tu ayuda!


Apliqué las correcciones sugeridas — sigo obteniendo redirect_uri_mismatch.

Cambios realizados:

  • Agregué N8N_PROXY_HOPS=1 a .env (confirmé dentro del contenedor con docker exec)

  • Agregué X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto a nginx

  • Reinicié tanto el contenedor de nginx como el de n8n

El env del contenedor confirma que todas las variables son correctas:

WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
N8N_PROXY_HOPS=1
N8N_HOST=staging.revvittsystems.com

Los detalles del error de Google muestran:

redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback

Esto coincide exactamente con lo registrado en Google Cloud Console. También intenté crear un cliente OAuth completamente nuevo con solo el URI de redirección de staging — mismo error.

Crear una nueva credencial en producción (n8n.revvittsystems.com) funciona inmediatamente con la misma app de OAuth de Google. El problema es específico de la instancia de staging.

La credencial se está creando desde una cuenta que no es admin/miembro para evitar el error 414 URI Too Long con cuentas de admin.


¡Hola! ¡Gracias por tu ayuda! Por favor, ve mi respuesta a @Anshul_Namdev. También la estoy incluyendo aquí.

¡Hola Anshul!

¡Gracias por tu ayuda!


Apliqué las correcciones sugeridas — sigo recibiendo redirect_uri_mismatch.

Cambios realizados:

  • Agregué N8N_PROXY_HOPS=1 a .env (confirmado dentro del contenedor vía docker exec)

  • Agregué X-Forwarded-For, X-Forwarded-Host, y X-Forwarded-Proto a nginx

  • Reinicié tanto nginx como el contenedor n8n

El env del contenedor confirma que todas las variables son correctas:

WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
N8N_PROXY_HOPS=1
N8N_HOST=staging.revvittsystems.com

Los detalles del error de Google muestran:

redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback

Esto coincide exactamente con lo que está registrado en Google Cloud Console. También intenté crear un cliente OAuth completamente separado solo con el redirect URI de staging — mismo error.

Crear una nueva credencial en producción (n8n.revvittsystems.com) funciona inmediatamente con la misma aplicación OAuth de Google. El problema es específico de la instancia de staging.

La credencial se está creando desde una cuenta sin privilegios de administrador/miembro para evitar el error 414 URI Too Long con cuentas de administrador.


Sam, dado que Google está devolviendo la devolución de llamada de staging exacta, separa el problema de generación de URL del problema del cliente OAuth. Verifica que el URI de redirección de staging esté en el mismo ID de cliente de aplicación web que n8n realmente está usando en la credencial de staging; tener el URI en un segundo cliente del mismo proyecto no servirá si n8n sigue enviando el primer client_id.

Siguiente comprobación determinista: crea una credencial de staging nueva después de una actualización forzada, luego compara solo los parámetros de error de Google redactados: sufijo de client_id, redirect_uri, scope, access_type y prompt. No publiques el secreto. Si el sufijo de client_id no es el cliente de staging que esperas, la discrepancia está dentro del registro de credencial de n8n; si es correcto, el problema está en la configuración/propagación del cliente OAuth de Google en lugar de nginx.