Nous exécutons n8n 2.26.4 auto-hébergé sur Elestio et nous ne pouvons pas connecter Claude.ai à notre instance via MCP. MCP au niveau de l’instance est activé et le jeton OAuth/Access est configuré.
Nous avons essayé à la fois le connecteur partenaire officiel n8n sur Claude.ai et un connecteur personnalisé utilisant l’URL du serveur MCP direct (format : https://your-instance.vm.elestio.app/mcp-server/http). Les deux échouent avec la même erreur du côté Claude :
« L’autorisation avec le serveur MCP a échoué. Vous pouvez vérifier vos identifiants et permissions. »
Interessant, du côté n8n, l’onglet Connected Clients affiche bien de nouvelles entrées Claude à chaque tentative de connexion, donc n8n reçoit bien la demande de connexion. L’établissement de liaison d’authentification ne s’effectue juste pas avec succès du côté Claude.
Codes de référence des trois tentatives échouées :
- ofid_ccb9a1fd230c7285
- ofid_757ab36960e137e7
- ofid_a02cf908ec28723f
Quelqu’un peut-il nous aider à identifier ce qui empêche l’autorisation de se terminer ?
1 « J'aime »
Ces lignes Connected Clients sont utiles : Claude atteint n8n, donc la prochaine division est la découverte d’URL par rapport à l’échange de tokens. Essayez une reconnexion propre avec l’URL MCP directe, puis vérifiez le log n8n pour ce même ofid_... ; si elle échoue lors de l’échange de tokens, collez cette ligne de log avec les noms d’hôtes/secrets masqués et le type de credential OAuth que vous avez utilisé.
1 « J'aime »
Mise à jour : Nous avons approfondi l’analyse des journaux et trouvé la cause racine.
Chaque tentative de connexion affiche :
ValidationError: An invalid 'request.ip' was detected
immédiatement suivie de « Deleting OAuth client » et « OAuth client deleted successfully ». La session OAuth est créée puis immédiatement fermée car le limiteur de débit de n8n rejette l’adresse IP malformée en provenance du reverse proxy nginx devant notre instance.
Nous avons défini N8N_TRUST_PROXY=true et N8N_PROXY_HOPS=1 mais le problème se situe au niveau de nginx. Nginx transmet les en-têtes X-Forwarded-For mais il manque les directives real_ip_header et set_real_ip_from, donc n8n reçoit une adresse IP malformée et ferme la session OAuth avant que l’échange de jetons puisse s’effectuer.
Nous avons signalé à Elestio (notre fournisseur d’hébergement) d’ajouter les directives real_ip de nginx. Y a-t-il quelque chose que nous pouvons faire du côté de n8n pour contourner ou désactiver la validation IP du limiteur de débit comme solution de contournement en attendant ?
Une chose utile à essayer en attendant Elestio : définissez temporairement N8N_PROXY_HOPS=0. Cela indique à n8n qu’il n’est pas derrière un proxy, donc il arrête complètement de chercher à analyser les en-têtes X-Forwarded-For et utilise l’IP brute de la connexion à la place — ce qui contourne la validation d’IP malformée qui interrompt la négociation OAuth. Le compromis est que la limitation de débit s’appliquera à l’IP du proxy plutôt qu’aux vraies adresses IP des clients, mais pour un serveur MCP, c’est généralement acceptable. Une fois que Elestio applique les directives nginx real_ip_header et set_real_ip_from, revenez à N8N_PROXY_HOPS=1 pour que la limitation de débit fonctionne correctement à nouveau.
1 « J'aime »
Meesam, traite l’idée N8N_PROXY_HOPS=0 ci-dessus comme un test d’isolation temporaire, pas comme la correction. Cela fait que n8n applique une limite de débit par rapport à l’IP du proxy, donc garde-la courte durée et bascule une fois qu’Elestio configure la véritable chaîne real-IP.
Ne désactive pas le limiteur lui-même dans n8n pour cela. La correction durable est toujours en amont : nginx doit transmettre une chaîne d’adresses IP clientes de confiance valides avant que le chemin OAuth/rate-limit se comporte normalement.
1 « J'aime »
Mise à jour : Des progrès ont été faits. La boucle de suppression OAuth est corrigée. Les logs affichent désormais « Consent approved » et « Refresh token rotated and new access token issued » à chaque tentative, donc le flux OAuth se termine avec succès du côté n8n. Cependant Claude.ai affiche toujours « Authorization with the MCP server failed ». L’échec se produit maintenant après la completion d’OAuth, lors de l’initialisation de la session MCP. Avez-vous une idée de ce qui pourrait causer l’échec de la session MCP après une authentification OAuth réussie ?
Meesam, si n8n affiche maintenant le consentement approuvé et la rotation des tokens, arrête de chercher du côté du proxy/IP pour cette partie. Le prochain contrôle est de vérifier si Claude atteint le point de terminaison MCP après OAuth : dans cette même tentative, les logs de n8n affichent-ils une requête à /mcp-server/http après la ligne du token, ou est-ce que ça devient silencieux ?
Si ça devient silencieux, le connecteur échoue probablement avant que l’initialisation de la session n’atteigne n8n. Si une requête arrive, colle la première ligne d’erreur de MCP-session avec les noms d’hôte et tokens masqués ; le code de statut là-bas est plus important que les lignes OAuth maintenant.
J’ai vérifié les logs immédiatement après une tentative de connexion. Après « Consent approved » et la rotation des tokens, les logs deviennent complètement silencieux. Aucune requête à /mcp-server/http n’apparaît. Claude réussit donc l’authentification OAuth mais n’atteint jamais le point de terminaison d’initialisation de la session MCP. Qu’est-ce qui pourrait amener Claude.ai à s’arrêter avant de frapper /mcp-server/http après un échange de tokens réussi ?
Cela réduit beaucoup les possibilités : si n8n se tait après la rotation du jeton, l’étape échouée n’est probablement plus n8n acceptant le résultat OAuth. Claude dépasse ce stade, puis ne démarre pas la demande de session MCP.
L’indice suivant est l’URL MCP côté client que Claude a enregistrée. Est-ce exactement l’URL publique https://.../mcp-server/http, sans slash final ni réécriture de chemin depuis Elestio ? Si cette URL est exacte et que n8n ne voit toujours rien après la rotation du jeton, le problème se situe probablement du côté du client MCP distant Claude plutôt que d’un paramètre du workflow n8n.
Salut @Meesam_Raza
Au lieu de
pourquoi ne pas utiliser ceci ?
C’est plus simple
1 « J'aime »
J’ai essayé l’approche de clé API en l’intégrant dans l’URL en tant que paramètre de requête. Je reçois toujours « L’autorisation avec le serveur MCP a échoué » du côté de Claude.
L’approche avec paramètre de requête ne fonctionnera pas - le client MCP de Claude.ai envoie le token comme Authorization: Bearer <key> dans l’en-tête de la requête, pas comme un paramètre d’URL. Le problème vient presque certainement du fait que le nginx d’Elestio supprime l’en-tête Authorization avant qu’il n’atteigne n8n.
Dans votre configuration nginx Elestio, assurez-vous que ceci est présent dans le bloc location qui gère MCP :
proxy_set_header Authorization $http_authorization;
Sans ceci, nginx laisse passer les cookies et les en-têtes personnalisés mais supprime l’en-tête Authorization par défaut, donc le serveur MCP de n8n ne voit jamais le token et rejette la connexion. Une fois que ce passage d’en-tête est en place, utilisez la clé API n8n directement dans le connecteur Claude - pas besoin d’incorporation dans l’URL.
1 « J'aime »
Mise à jour : Test direct de l’endpoint MCP avec curl. L’endpoint annonce une authentification Bearer via WWW-Authenticate: Bearer realm="n8n MCP Server" mais retourne "Missing Bearer prefix" même lors de l’envoi d’un header Authorization: Bearer <token> valide. Le token atteint n8n (confirmé par nginx qui transmet les headers Authorization). L’utilisation du token d’accès MCP et de la clé API n8n retournent tous deux HTTP 401. Y a-t-il un format de token spécifique ou un endpoint que le serveur MCP attend pour une authentification Bearer directe en 2.26.4 ?
Résolu - voici ce qui a vraiment réglé le problème pour ceux sur Elestio :
La cause première était que la configuration nginx d’Elestio manquait de directives proxy spécifiques à MCP. Même si nginx transmettait les en-têtes Authorization pour d’autres routes, le bloc location gérant le point de terminaison n8n MCP (/mcp-server/http) n’était pas correctement configuré pour transmettre les en-têtes et gérer l’initialisation de la session MCP.
La solution a été qu’Elestio mette à jour la configuration nginx du service n8n avec les bonnes directives proxy pour le point de terminaison MCP. Nous n’avons pas eu les lignes exactes qu’ils ont changées, mais le symptôme était :
- OAuth s’est complété avec succès (consentement approuvé, jetons émis dans les logs n8n)
- Claude n’a jamais accédé à
/mcp-server/http après l’échange de jetons, les logs sont devenus silencieux
- Une requête curl directe vers
/mcp-server/http avec un jeton Bearer a retourné 401 avec l’erreur contradictoire « Missing Bearer prefix » même quand le préfixe Bearer était présent
- Après qu’Elestio a mis à jour la configuration nginx MCP, la connexion a fonctionné immédiatement
Autres choses que nous avons réglées en chemin qui n’étaient pas la cause première mais qui étaient des problèmes réels :
- n8n était en 1.121.3, mise à jour vers 2.26.4 (requise pour le support stable de MCP)
- Ajout de
N8N_TRUST_PROXY: "true" au docker-compose.yml (bonne pratique derrière un reverse proxy)
- La variable
N8N_PROXY_HOPS=1 était déjà correctement définie, ne la changez pas
Si vous êtes sur Elestio et vous heurtez au même mur, ouvrez un ticket d’assistance et demandez-leur de mettre à jour la configuration nginx MCP pour votre service n8n. Ils l’ont réglé rapidement une fois que nous leur avons donné l’erreur spécifique.
1 « J'aime »
