Wir führen n8n 2.26.4 selbst gehostet auf Elestio aus und können Claude.ai nicht über MCP mit unserer Instanz verbinden. MCP auf Instanzebene ist aktiviert und OAuth/Access Token sind konfiguriert.
Wir haben sowohl den offiziellen n8n-Partner-Connector auf Claude.ai als auch einen benutzerdefinierten Connector mit der direkten MCP-Server-URL ausprobiert (Format: https://your-instance.vm.elestio.app/mcp-server/http). Beide schlagen mit demselben Fehler auf der Claude-Seite fehl:
„Authorization with the MCP server failed. You can check your credentials and permissions.„
Interessanterweise zeigt der Reiter „Connected Clients
1 „Gefällt mir“
Diese Connected Clients-Zeilen sind hilfreich: Claude erreicht n8n, also geht es als nächstes um URL-Erkennung vs. Token-Austausch. Versuchen Sie eine saubere Neuverbindung mit der direkten MCP-URL, überprüfen Sie dann das n8n-Log auf die gleiche ofid_...; falls es beim Token-Austausch fehlschlägt, fügen Sie diese eine Log-Zeile mit redigierten Hostnamen/Geheimnissen und dem OAuth-Credential-Typ ein, den Sie verwendet haben.
1 „Gefällt mir“
Update: Wir haben die Logs genauer untersucht und die Grundursache gefunden.
Jede Verbindungsversuch zeigt:
ValidationError: An invalid 'request.ip' was detected
gefolgt unmittelbar von „Deleting OAuth client
Eine Sache, die du ausprobieren kannst, während du auf Elestio wartest: Setze N8N_PROXY_HOPS=0 vorübergehend. Das teilt n8n mit, dass es nicht hinter einem Proxy läuft, daher stoppt es den Versuch, X-Forwarded-For-Header zu parsen, und verwendet stattdessen die rohe Verbindungs-IP — das umgeht die fehlerhafte IP-Validierung, die den OAuth-Handshake blockiert. Der Kompromiss ist, dass Rate Limiting auf die IP des Proxys angewendet wird, statt auf die echten Client-IPs, aber für einen MCP-Server ist das üblicherweise okay. Sobald Elestio die real_ip_header- und set_real_ip_from-nginx-Direktiven anwendet, schalte zurück auf N8N_PROXY_HOPS=1, damit Rate Limiting wieder korrekt funktioniert.
1 „Gefällt mir“
Meesam, behandle die N8N_PROXY_HOPS=0-Idee oben als temporären Isolationstest, nicht als Lösung. Sie führt dazu, dass n8n gegen die Proxy-IP Rate-Limiting anwendet, also halte das kurz und wechsele zurück, sobald Elestio die echte IP-Kette einstellt.
Deaktiviere den Limiter selbst in n8n nicht dafür. Die dauerhafte Lösung liegt noch vorgelagert: nginx muss eine gültige vertrauenswürdige Client-IP-Kette weitergeben, bevor der OAuth/Rate-Limit-Pfad normal funktioniert.
1 „Gefällt mir“
Update: Fortschritt gemacht. Die OAuth-Lösch-Schleife ist behoben. Die Logs zeigen jetzt „Consent approved
Meesam, wenn n8n jetzt Zustimmung genehmigt und Token-Rotation anzeigt, höre auf, den Proxy/IP-Pfad für diesen Teil zu untersuchen. Der nächste Check ist, ob Claude den MCP-Endpunkt nach OAuth erreicht: Zeigen die n8n-Logs bei demselben Versuch einen Request zu /mcp-server/http nach der Token-Zeile, oder wird es still?
Wenn es still wird, schlägt der Connector wahrscheinlich fehl, bevor Session Init n8n erreicht. Wenn ein Request ankommt, füge die erste MCP-Session-Fehlerzeile mit redigierten Hostnamen/Tokens ein; der Status Code dort ist jetzt wichtiger als die OAuth-Zeilen.
Habe die Logs unmittelbar nach einem Verbindungsversuch überprüft. Nach „Consent approved
Das grenzt es stark ein: Wenn n8n nach der Token-Rotation stillschweigend innehalten, ist der fehlgeschlagene Schritt wahrscheinlich nicht mehr, dass n8n das OAuth-Ergebnis akzeptiert. Claude kommt da durch, startet aber nicht die MCP-Session-Anfrage.
Der nächste Hinweis ist die clientseitige MCP-URL, die Claude gespeichert hat. Ist es genau die öffentliche https://.../mcp-server/http-URL, ohne nachgelagerten Schrägstrich/Pfad-Umschreiben von Elestio? Wenn diese URL exakt ist und n8n nach der Token-Rotation immer noch nichts sieht, liegt das wahrscheinlich auf der Claude-Remote-MCP-Client-Seite statt an einer n8n-Workflow-Einstellung.
Hey @Meesam_Raza
Statt
warum verwendest du nicht einfach das?
Es ist einfacher
1 „Gefällt mir“
Habe den API-Key-Ansatz ausprobiert, indem ich ihn als Query-Parameter in die URL eingebettet habe. Auf Claudes Seite erhalte ich immer noch „Autorisierung mit dem MCP-Server fehlgeschlagen
Der Query-Parameter-Ansatz funktioniert nicht – Claude.ai’s MCP-Client sendet das Token als Authorization: Bearer <key> im Request-Header, nicht als URL-Parameter. Das Problem ist mit großer Sicherheit, dass Elestio’s nginx den Authorization-Header entfernt, bevor er n8n erreicht.
In deiner Elestio-nginx-Konfiguration stelle sicher, dass dies im Location-Block für die MCP-Behandlung vorhanden ist:
proxy_set_header Authorization $http_authorization;
Ohne diesen Header leitet nginx Cookies und benutzerdefinierte Header weiter, verwirft aber standardmäßig den Authorization-Header, sodass n8n’s MCP-Server das Token nie sieht und die Verbindung ablehnt. Sobald dieser Header-Passthrough eingerichtet ist, verwende den n8n-API-Schlüssel direkt im Claude-Connector – es ist keine URL-Einbettung erforderlich.
1 „Gefällt mir“
Update: Den MCP-Endpunkt direkt mit curl getestet. Der Endpunkt wirbt via WWW-Authenticate: Bearer realm="n8n MCP Server" für Bearer-Authentifizierung, gibt aber "Missing Bearer prefix" zurück, auch wenn ein gültiger Authorization: Bearer <token>-Header gesendet wird. Das Token erreicht n8n (bestätigt, dass nginx Authorization-Header durchleitet). Sowohl das MCP-Zugriffstoken als auch der n8n API-Schlüssel geben beide HTTP 401 zurück. Erwartet der MCP-Server in 2.26.4 ein spezifisches Token-Format oder einen bestimmten Endpunkt für direkte Bearer-Authentifizierung?
Gelöst – hier ist die tatsächliche Lösung für alle auf Elestio:
Die Grundursache war die fehlende MCP-spezifische Proxy-Direktiven in der Elestio-nginx-Konfiguration. Obwohl nginx die Authorization-Header für andere Routen weitergab, war der Location-Block, der den n8n-MCP-Endpunkt (/mcp-server/http) verwaltet, nicht korrekt konfiguriert, um die Header weiterzuleiten und die MCP-Session-Initialisierung zu handhaben.
Die Lösung war, dass Elestio die nginx-Konfiguration für den n8n-Service mit den korrekten Proxy-Direktiven für den MCP-Endpunkt aktualisiert hat. Wir bekamen die genauen Zeilen nicht zu sehen, die sie geändert haben, aber das Symptom war:
- OAuth wurde erfolgreich abgeschlossen (Zustimmung genehmigt, Token in n8n-Logs ausgestellt)
- Claude hat
/mcp-server/http nach dem Token-Austausch nie aufgerufen, Logs wurden still
- Direkter curl zu
/mcp-server/http mit einem Bearer-Token gab 401 mit dem widersprüchlichen Fehler „Missing Bearer prefix
1 „Gefällt mir“
