OAuth-Redirect zeigt auf localhost: Google/Microsoft-Credentials reparieren

OAuth-Redirect zeigt bei n8n auf localhost? So beheben Sie redirect_uri_mismatch mit N8N_HOST und WEBHOOK_URL.

n8n baut die OAuth-Redirect-URI aus den Variablen N8N_PROTOCOL, N8N_HOST und N8N_PORT zusammen. Ohne eigene Konfiguration ergibt das http://localhost:5678/rest/oauth2-credential/callback. Google und Microsoft lehnen diese Adresse ab, sobald sie nicht exakt in der Anbieter-Konfiguration hinterlegt ist. Die Lösung besteht aus zwei Schritten. Sie setzen die öffentliche Adresse in n8n und tragen die im Credential angezeigte Redirect-URI unverändert beim Anbieter ein.

Warum zeigt n8n localhost statt Ihrer Domain?

n8n zeigt localhost, weil der Dienst seine öffentliche Adresse nicht selbst erkennen kann. Er berechnet Editor- und Callback-URLs aus drei Variablen mit festen Standardwerten.

Variable | Standardwert laut Doku | Bedeutung

Variable: N8N_PROTOCOL · Standardwert laut Doku: http · Bedeutung: Protokoll, über das n8n erreicht wird

Variable: N8N_HOST · Standardwert laut Doku: localhost · Bedeutung: Hostname, unter dem n8n läuft

Variable: N8N_PORT · Standardwert laut Doku: 5678 · Bedeutung: HTTP-Port des Dienstes

Variable: N8N_ENDPOINT_REST · Standardwert laut Doku: rest · Bedeutung: Pfadsegment vor /oauth2-credential/callback

Quelle: Deployment-Variablen und Endpoint-Variablen.

Auf dem eigenen Rechner ist dieser Wert korrekt, denn der Browser greift tatsächlich über localhost zu. Auf einem Server, in Docker oder hinter einem Reverse Proxy stimmt er nicht mehr. n8n sieht intern weiterhin nur Port 5678, während der Nutzer über HTTPS und Ihre Domain kommt.

Welche Umgebungsvariablen setzen Sie für die richtige Redirect-URI?

Sie setzen N8N_WEBHOOK_URL und N8N_EDITOR_BASE_URL auf die vollständige öffentliche Adresse, dazu Protokoll, Host und Proxy-Anzahl. Diese Werte überschreiben die automatische Berechnung.

Variable | Wert im Produktivbetrieb | Wirkung

Variable: N8N_PROTOCOL · Wert im Produktivbetrieb: https · Wirkung: ersetzt den Standardwert http

Variable: N8N_HOST · Wert im Produktivbetrieb: n8n.ihre-domain.de · Wirkung: reine Domain ohne Protokoll

Variable: N8N_WEBHOOK_URL · Wert im Produktivbetrieb: https://n8n.ihre-domain.de/ · Wirkung: Basis-URL für Webhooks hinter einem Proxy

Variable: N8N_EDITOR_BASE_URL · Wert im Produktivbetrieb: https://n8n.ihre-domain.de/ · Wirkung: öffentliche Editor-URL, auch für E-Mails und SAML

Variable: N8N_PROXY_HOPS · Wert im Produktivbetrieb: 1 · Wirkung: Anzahl der vorgeschalteten Proxys, Standard ist 0

Ein Hinweis zu älteren Anleitungen im Netz: N8N_WEBHOOK_URL ersetzt die frühere Variable WEBHOOK_URL. Der alte Name funktioniert weiter als Alias, erzeugt beim Start aber eine Deprecation-Warnung im Log.

Als Ausschnitt aus der docker-compose.yml sieht die Konfiguration so aus. Die Portbindung auf 127.0.0.1 sorgt dafür, dass nur der Reverse Proxy die Instanz erreicht.

1services:
2 n8n:
3 image: n8nio/n8n:2.36.9
4 restart: always
5 ports:
6 - "127.0.0.1:5678:5678"
7 environment:
8 - N8N_PROTOCOL=https
9 - N8N_HOST=n8n.ihre-domain.de
10 - N8N_PORT=5678
11 - N8N_WEBHOOK_URL=https://n8n.ihre-domain.de/
12 - N8N_EDITOR_BASE_URL=https://n8n.ihre-domain.de/
13 - N8N_PROXY_HOPS=1
14 - GENERIC_TIMEZONE=Europe/Berlin
15 - TZ=Europe/Berlin
16 volumes:
17 - n8n_data:/home/node/.n8n
18
19volumes:
20 n8n_data:

n8n liest Umgebungsvariablen ausschließlich beim Start ein. Nach der Änderung ist deshalb ein docker compose up -d --force-recreate n8n nötig.

Wie prüfen Sie, ob die Adresse jetzt stimmt?

Sie prüfen die gesetzten Variablen direkt im laufenden Container und rufen anschließend den Health-Endpunkt über die öffentliche Domain auf. Beide Zeilen laufen ohne weitere Werkzeuge.

1# 1. Adress-Variablen im laufenden Container anzeigen
2docker compose exec n8n env | grep -E '^N8N_(HOST|PORT|PROTOCOL|WEBHOOK_URL|EDITOR_BASE_URL|PROXY_HOPS)='
3
4# 2. Erreichbarkeit über die öffentliche Domain prüfen, erwartet wird 200
5curl -s -o /dev/null -w '%{http_code}\n' https://n8n.ihre-domain.de/healthz

Der Pfad /healthz stammt aus der Variablen N8N_ENDPOINT_HEALTH mit dem Standardwert healthz. Liefert der Aufruf einen anderen Wert als 200, liegt das Problem beim Proxy und nicht bei den n8n-Variablen.

Wie lautet die Redirect-URI, die Sie beim Anbieter eintragen?

Die Redirect-URI besteht aus Ihrer öffentlichen Basis-URL und dem festen Pfad /rest/oauth2-credential/callback. n8n zeigt sie im Credential-Formular an, sobald Sie den Anmeldetyp OAuth2 wählen.

1https://n8n.ihre-domain.de/rest/oauth2-credential/callback

Kopieren Sie diesen Wert aus dem Credential-Dialog, statt ihn abzutippen. Die n8n-Dokumentation zu Google-OAuth verlangt eine exakte Übernahme inklusive Protokoll und Portnummer.

Was unterscheidet Google und Microsoft beim Eintragen?

Beide Anbieter verlangen einen exakten Abgleich, unterscheiden sich aber im Ablageort und in den Regeln. Die folgende Tabelle stellt die Punkte gegenüber, die in der Praxis abweichen.

Punkt | Google Cloud Console | Microsoft Entra App-Registrierung

Punkt: Ablageort · Google Cloud Console: OAuth-Client, Feld Autorisierte Weiterleitungs-URIs · Microsoft Entra App-Registrierung: App-Registrierung, Bereich Authentifizierung

Punkt: Fehlermeldung · Google Cloud Console: redirect_uri_mismatch · Microsoft Entra App-Registrierung: AADSTS50011

Punkt: Groß- und Kleinschreibung · Google Cloud Console: wird unterschieden · Microsoft Entra App-Registrierung: wird unterschieden

Punkt: Abschließender Schrägstrich · Google Cloud Console: muss übereinstimmen · Microsoft Entra App-Registrierung: muss übereinstimmen

Punkt: Sonderzeichen im Pfad · Google Cloud Console: keine Einschränkung dokumentiert · Microsoft Entra App-Registrierung: ! $ ' ( ) , ; nicht unterstützt

Punkt: Wirksamkeit der Änderung · Google Cloud Console: nach dem Speichern · Microsoft Entra App-Registrierung: drei bis fünf Minuten Wartezeit

Die Regeln auf der Microsoft-Seite stehen in der Übersicht zu Umleitungs-URIs und deren Einschränkungen. Verbinden Sie das Credential in n8n nach der Änderung neu, damit ein frischer Token abgerufen wird.

Typische Fehler und Ursachen

Der Credential-Dialog zeigt weiterhin `localhost:5678`. Ursache ist ein fehlender Neustart, denn n8n liest Umgebungsvariablen nur beim Start. Lösung: Container mit --force-recreate neu starten und den Dialog erneut öffnen. Quelle: Deployment-Variablen.

Die Anmeldung landet trotz gesetzter Domain auf `http` statt `https`. Ursache ist ein Reverse Proxy, dessen Weiterleitungs-Header n8n nicht auswertet. Lösung: N8N_PROXY_HOPS auf die Anzahl der vorgeschalteten Proxys setzen, bei einem Proxy also 1. Quelle: Deployment-Variablen.

Google meldet `redirect_uri_mismatch`, obwohl die Adresse richtig aussieht. Ursache ist meist ein Zeichenunterschied, etwa ein zusätzlicher Schrägstrich oder ein kopiertes Leerzeichen. Lösung: die Adresse aus dem n8n-Dialog neu kopieren und den Eintrag beim Anbieter ersetzen. Quelle: Google-OAuth in n8n.

Microsoft meldet `AADSTS50011` direkt nach dem Speichern. Ursache ist die Verzögerung, mit der Entra ID neue Umleitungs-URIs übernimmt. Lösung: drei bis fünf Minuten warten, danach den Anmeldeversuch in einem privaten Browserfenster wiederholen. Quelle: Fehlerbehebung zu AADSTS50011.

Google-Nodes brechen nach einem Server-Umzug ab. Ursache sind nicht vollqualifizierte Domains in den Adress-Variablen. Lösung: N8N_EDITOR_BASE_URL und die Webhook-Basis-URL auf die vollständige Domain setzen. Quelle: Häufige Probleme mit Google Drive.

Wer eine n8n-Instanz produktiv mit mehreren OAuth-Verbindungen betreibt, will bei jedem Umzug nicht erneut an Redirect-URIs schrauben. Genau dabei unterstützt NordFlux bei der n8n-Einrichtung, damit Automatisierungen mit deutscher Datenhoheit auch nach einem Update stabil laufen.

Häufige Fragen zu OAuth-Redirect-Problemen in n8n

Muss ich n8n nach dem Setzen der Variablen neu starten?

Ja, ein Neustart ist zwingend. n8n liest Umgebungsvariablen nur beim Start des Prozesses ein. Ohne Neustart bleibt die alte Redirect-URI aktiv, auch wenn die Werte bereits korrekt gesetzt sind.

Reicht es, nur die Webhook-Basis-URL zu setzen?

Meistens ja, denn N8N_WEBHOOK_URL überschreibt die automatisch berechnete Adresse. N8N_EDITOR_BASE_URL brauchen Sie zusätzlich, wenn Links in versendeten E-Mails oder SAML-Weiterleitungen noch falsch sind.

Warum tritt der Fehler manchmal auch bei n8n Cloud auf?

Auch dort kann die angezeigte Redirect-URL von der hinterlegten Adresse abweichen, etwa nach einem Wechsel der Workspace-Domain. Kopieren Sie die aktuell angezeigte Adresse erneut und aktualisieren Sie den Eintrag beim Anbieter.

Gilt die gleiche Lösung auch für Microsoft-Credentials?

Ja, das Prinzip ist identisch. Auch Entra ID vergleicht die gesendete Adresse zeichengenau mit der Liste in der App-Registrierung. Setzen Sie dieselben Variablen und tragen Sie die angezeigte Adresse als Umleitungs-URI ein.

Simon Glowik, Gründer von NordFlux
Über den Autor

Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.

Zertifizierungen

  • Microsoft zertifiziert — PL-900 und AZ-900
  • UiPath zertifiziert — Automation Developer Associate
Alle Beiträge
Weiterlesen

Verwandte Anleitungen

Kostenlose Erstanalyse

OAuth-Redirect landet auf localhost? Zeit für stabilen Betrieb

N8N_HOST, WEBHOOK_URL und N8N_EDITOR_BASE_URL müssen bei jeder Umgebungsänderung neu zusammenpassen, sonst kippt die OAuth-Anbindung wieder auf localhost oder in einen redirect_uri_mismatch. NordFlux übernimmt den betreuten n8n-Betrieb inklusive Umgebungsvariablen, Reverse-Proxy-Konfiguration und OAuth-Anbindungen, damit Google- und Microsoft-Credentials dauerhaft funktionieren statt bei jedem Deployment neu zu brechen. Im ersten Gespräch schauen wir uns Ihre n8n-Umgebung an und beheben die Ursache, nicht nur das Symptom.

n8n Kosten und Lizenzenn8n Beratung

  • Saubere Konfiguration von N8N_HOST, WEBHOOK_URL und Reverse Proxy in einem Zug
  • OAuth-Anbindungen zu Google und Microsoft, die auch nach Updates stabil bleiben
  • Betreuter Betrieb, der Umgebungsfehler vor dem nächsten Deployment abfängt