Estamos ejecutando n8n 2.26.4 auto-hospedado en Elestio y no podemos conectar Claude.ai a nuestra instancia a través de MCP. El MCP a nivel de instancia está habilitado y el token OAuth/Access está configurado.
Hemos intentado tanto el conector asociado oficial de n8n en Claude.ai como un conector personalizado usando la URL directa del servidor MCP (formato: https://your-instance.vm.elestio.app/mcp-server/http). Ambos fallan con el mismo error en el lado de Claude:
«La autorización con el servidor MCP falló. Puedes verificar tus credenciales y permisos».
Interesantemente, en el lado de n8n la pestaña Connected Clients sí muestra nuevas entradas de Claude cada vez que intentamos conectarnos, por lo que n8n está recibiendo el intento de conexión. El protocolo de autenticación simplemente no se está completando correctamente en el lado de Claude.
Códigos de referencia de los tres intentos fallidos:
- ofid_ccb9a1fd230c7285
- ofid_757ab36960e137e7
- ofid_a02cf908ec28723f
¿Puede alguien ayudarnos a identificar qué está bloqueando la finalización de la autorización?
1 me gusta
Esas filas Connected Clients son útiles: Claude está llegando a n8n, así que el siguiente paso es descubrir la URL vs. el intercambio de tokens. Intenta una reconexión limpia con la URL de MCP directa, luego verifica el registro de n8n para ese mismo ofid_...; si falla durante el intercambio de tokens, pega esa única línea de registro con nombres de host/secretos editados y el tipo de credencial OAuth que usaste.
1 me gusta
Actualización: Hemos profundizado en los registros y encontrado la causa raíz.
Cada intento de conexión muestra:
ValidationError: An invalid 'request.ip' was detected
seguido inmediatamente por “Deleting OAuth client” y “OAuth client deleted successfully”. La sesión OAuth se está creando y luego se destruye inmediatamente porque el limitador de velocidad de n8n está rechazando la IP malformada que proviene del proxy inverso nginx frente a nuestra instancia.
Hemos configurado N8N_TRUST_PROXY=true y N8N_PROXY_HOPS=1 pero el problema está en la capa de nginx. Nginx está reenviando encabezados X-Forwarded-For pero le faltan las directivas real_ip_header y set_real_ip_from, por lo que n8n recibe una IP malformada y destruye la sesión OAuth antes de que se pueda completar el intercambio de tokens.
Hemos escalado el problema a Elestio (nuestro proveedor de alojamiento) para que añada las directivas real_ip de nginx. ¿Hay algo que podamos hacer en el lado de n8n para omitir o desactivar la validación de IP del limitador de velocidad como solución temporal mientras esperamos?
Una cosa que vale la pena probar mientras esperas a Elestio: establece N8N_PROXY_HOPS=0 temporalmente. Esto le dice a n8n que no está detrás de ningún proxy, por lo que deja de intentar analizar los encabezados X-Forwarded-For por completo y usa la dirección IP de conexión sin procesar en su lugar, lo que evita la validación de IP malformada que está causando problemas en el flujo de OAuth. La contrapartida es que la limitación de velocidad se aplicará a la IP del proxy en lugar de las IPs reales de los clientes, pero para un servidor MCP generalmente está bien. Una vez que Elestio aplique las directivas nginx real_ip_header y set_real_ip_from, vuelve a N8N_PROXY_HOPS=1 para que la limitación de velocidad funcione correctamente de nuevo.
1 me gusta
Meesam, trata la idea de N8N_PROXY_HOPS=0 anterior como una prueba temporal de aislamiento, no como la solución. Hace que n8n aplique límite de velocidad contra la IP del proxy, así que mantenlo breve y vuelve una vez que Elestio configure la cadena real de IPs.
No desactives el limitador en sí en n8n para esto. La solución duradera sigue siendo upstream: nginx necesita pasar una cadena de IP de cliente de confianza válida antes de que la ruta OAuth/rate-limit se comporte normalmente.
1 me gusta
Actualización: Se ha hecho progreso. Se corrigió el bucle de eliminación de OAuth. Los registros ahora muestran «Consentimiento aprobado» y «Token de actualización rotado y nuevo token de acceso emitido» en cada intento, por lo que el flujo de OAuth se completa exitosamente en el lado de n8n. Sin embargo, Claude.ai aún muestra «La autorización con el servidor MCP falló». El fallo ahora ocurre después de que OAuth se completa, durante la inicialización de la sesión MCP. ¿Tienes alguna idea de qué podría causar que la sesión MCP falle después de un apretón de manos OAuth exitoso?
Meesam, si n8n ahora muestra consentimiento aprobado y rotación de tokens, deja de buscar por la ruta del proxy/IP en esta parte. La siguiente comprobación es si Claude llega al endpoint de MCP después de OAuth: en ese mismo intento, ¿muestran los logs de n8n una solicitud a /mcp-server/http después de la línea del token, o se queda en silencio?
Si se queda en silencio, probablemente el conector está fallando antes de que la inicialización de sesión llegue a n8n. Si llega una solicitud, pega la primera línea de error de MCP-session con los nombres de host y tokens ocultos; el código de estado ahí importa más que las líneas de OAuth ahora.
Revisé los registros inmediatamente después de un intento de conexión. Después de «Consentimiento aprobado» y rotación de tokens, los registros se quedan completamente silenciosos. No aparece ninguna solicitud a /mcp-server/http en absoluto. Entonces Claude está completando OAuth correctamente pero nunca llega al endpoint de inicialización de la sesión MCP. ¿Qué causaría que Claude.ai se detuviera antes de acceder a /mcp-server/http después de un intercambio de tokens exitoso?
Eso lo reduce mucho: si n8n se queda en silencio después de la rotación de tokens, el paso fallido probablemente ya no sea n8n aceptando el resultado de OAuth. Claude está pasando eso, luego no inicia la solicitud de sesión MCP.
La siguiente pista es la URL MCP del lado del cliente que Claude guardó. ¿Es exactamente la URL pública https://.../mcp-server/http, sin barra diagonal al final ni reescritura de ruta de Elestio? Si esa URL es exacta y n8n aún no ve nada después de la rotación de tokens, esto probablemente esté en el lado del cliente MCP remoto de Claude en lugar de una configuración del flujo de trabajo de n8n.
Hola @Meesam_Raza
En lugar de
¿por qué no usas simplemente esto?
Es más simple
1 me gusta
Intenté el enfoque de clave de API incrustándola en la URL como parámetro de consulta. Aún estoy recibiendo el error «Error de autorización con el servidor MCP» por parte de Claude.
El enfoque del parámetro de consulta no funcionará - el cliente MCP de Claude.ai envía el token como Authorization: Bearer <key> en el encabezado de la solicitud, no como un parámetro de URL. El problema casi seguramente es que nginx de Elestio está eliminando el encabezado Authorization antes de que llegue a n8n.
En tu configuración de nginx de Elestio, asegúrate de que esto esté presente en el bloque de ubicación que maneja MCP:
proxy_set_header Authorization $http_authorization;
Sin esto, nginx transmite cookies y encabezados personalizados pero elimina el encabezado Authorization por defecto, por lo que el servidor MCP de n8n nunca ve el token y rechaza la conexión. Una vez que ese paso de encabezado esté en su lugar, usa la clave API de n8n directamente en el conector de Claude - no se necesita incrustar en la URL.
1 me gusta
Actualización: Probé el endpoint MCP directamente con curl. El endpoint anuncia autenticación Bearer mediante WWW-Authenticate: Bearer realm="n8n MCP Server" pero devuelve "Missing Bearer prefix" incluso al enviar un encabezado Authorization: Bearer <token> válido. El token está llegando a n8n (confirmé que nginx pasa los encabezados Authorization). Tanto el token de acceso MCP como la clave API de n8n devuelven HTTP 401. ¿Hay un formato de token o endpoint específico que el servidor MCP espera para autenticación Bearer directa en 2.26.4?
Resuelto - esto es lo que realmente lo arregló para cualquiera en Elestio:
La causa raíz fue que la configuración de nginx de Elestio no tenía las directivas de proxy específicas relacionadas con MCP. Aunque nginx estaba pasando los encabezados de Authorization para otras rutas, el bloque de ubicación que manejaba el endpoint de MCP de n8n (/mcp-server/http) no estaba configurado correctamente para pasar los encabezados y manejar la inicialización de la sesión MCP.
La solución fue que Elestio actualizara la configuración de nginx del servicio n8n con las directivas de proxy correctas para el endpoint de MCP. No obtuvimos las líneas exactas que cambiaron, pero el síntoma era:
- OAuth se completó exitosamente (consentimiento aprobado, tokens emitidos en los logs de n8n)
- Claude nunca llegó a
/mcp-server/http después del intercambio de tokens, los logs se quedaron en silencio
- La solicitud directa con curl a
/mcp-server/http con un token Bearer devolvió 401 con el error contradictorio «Missing Bearer prefix» aunque el prefijo Bearer estaba presente
- Después de que Elestio actualizara la configuración de nginx para MCP, la conexión funcionó inmediatamente
Otras cosas que arreglamos en el camino que no fueron la causa raíz pero eran problemas reales:
- n8n estaba en 1.121.3, actualizado a 2.26.4 (requerido para soporte estable de MCP)
- Se agregó
N8N_TRUST_PROXY: "true" a docker-compose.yml (buena práctica detrás de un proxy inverso)
- El
N8N_PROXY_HOPS=1 ya estaba configurado correctamente, no cambies esto
Si estás en Elestio y golpeaste el mismo muro, abre un ticket de soporte y pídeles que actualicen la configuración de nginx para MCP en tu servicio n8n. Lo arreglaron rápidamente una vez que les dimos el error específico.
1 me gusta
