Google OAuth redirect_uri_mismatch auf Staging-Instanz — Production funktioniert einwandfrei mit derselben OAuth-App

Fragen
,
1

<n8n version: 2.20.7
Datenbank: SQLite (Standard)
Ausführung über: Docker (selbstgehostet, Ubuntu 24.04 auf DigitalOcean)
Reverse Proxy: nginx mit SSL via Certbot/Let’s Encrypt
Problem:
Ich habe zwei selbstgehostete n8n-Instanzen:
Produktion: n8n.revvittsystems.com — Gmail OAuth funktioniert perfekt, einschließlich dem Erstellen neuer Anmeldedaten
Staging: staging.revvittsystems.com — Gmail OAuth schlägt mit Fehler 400: redirect_uri_mismatch fehl
Beiden Instanzen führen n8n 2.20.7 auf Docker mit nginx Reverse Proxy aus. Beide verwenden dieselbe Google Cloud OAuth-App (gleiche Client-ID/Secret). Ich habe auch versucht, einen völlig separaten OAuth-Client nur mit der Staging-Redirect-URI zu erstellen — derselbe Fehler.
Was ich bestätigt habe:
Die Redirect-URI, die in der n8n Staging-UI angezeigt wird, ist https://staging.revvittsystems.com/rest/oauth2-credential/callback
Diese genaue URI ist in der Google Cloud Console unter Authorized redirect URIs registriert
Ich habe die Google-Fehler-URL decodiert und bestätigt, dass die Redirect-URI, die n8n sendet, https://staging.revvittsystems.com/rest/oauth2-credential/callback ist — sie stimmt exakt überein
X-Forwarded-Proto $scheme ist in nginx gesetzt, sodass n8n das https://-Präfix korrekt generiert
App wird in Google OAuth Zustimmungsbildschirm in Produktion veröffentlicht
In Inkognito-Fenster getestet — derselbe Fehler
Das Erstellen einer neuen Anmeldedaten in der Produktion funktioniert sofort — die Google OAuth-App selbst ist in Ordnung
Das Erstellen eines separaten brandneuen OAuth-Clients nur für Staging schlägt mit demselben Fehler fehl
Staging .env:
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
Staging nginx-Konfiguration:
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;
}
}
Zusätzlicher Hinweis: Wenn ich als Owner/Admin-Konto auf Staging angemeldet bin und auf „Mit Google anmelden

2

Hi @Sam_Rao, willkommen!
Ich denke, deine n8n_proxy_hops ist entweder nicht gesetzt oder nicht richtig gemäß deinem Setup konfiguriert. Diese Umgebungsvariable sollte so aussehen:

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

und stelle sicher, dass deine Nginx-Konfiguration auch diese Dinge aktiviert hat:

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

Lass mich wissen, wie das nach einem Neustart funktioniert.

3

Hallo @Sam_Rao

Die Redirect-URI-Nichtübereinstimmung, die du auf deiner Staging-Instanz erfährst, ist ein häufiges, aber frustrierendes Hindernis bei n8n-Deployments. Auch wenn die URL identisch aussieht, sind Googles Authentifizierungsserver äußerst streng. Der Prozess erfordert eine exakte, Zeichen-für-Zeichen-Übereinstimmung zwischen dem Wert, der in deiner Google Cloud Console definiert ist, und dem Wert, den n8n in seiner Anfrage sendet. Wenn es auch nur ein einziger Zeichen Unterschied gibt, wie z. B. ein fehlender abschließender Schrägstrich, wird die Authentifizierung sofort abgelehnt.

Eine der häufigsten Ursachen für diesen Fehler, besonders nach Konfigurationsänderungen, ist Googles globale Propagierungsverzögerung. Auch wenn du die autorisierten Redirect-URIs in der Google Cloud Console aktualisiert hast, können diese Änderungen mehrere Stunden brauchen, um sich über Googles Infrastruktur auszubreiten. Wenn du diese Einstellungen kürzlich geändert hast, ist die wahrscheinlichste Lösung, einfach ein paar Stunden zu warten und es dann erneut zu versuchen, da das System möglicherweise noch die alte Konfiguration verwendet.

Es ist auch wichtig zu überprüfen, dass die Umgebungsvariablen in deinem Docker-Container deinen Erwartungen entsprechen. Obwohl deine .env-Datei korrekt aussieht, ist es möglich, dass der laufende n8n-Prozess eine andere Konfiguration hat, da caching oder die Art, wie der Container initialisiert wurde, zu unterschiedlichen Einstellungen führt. Wenn du einen Befehl ausführst, um die Umgebungsvariablen aus dem Container auszugeben, kannst du bestätigen, dass die Einstellungen WEBHOOK_URL und N8N_PROTOCOL korrekt angewendet werden und nicht auf interne, falsche Werte zurückfallen.

docker exec <container_id> env

Du solltest auch deine Nginx-Konfiguration auf mögliche Konflikte überprüfen. Während deine aktuellen Einstellungen Standard sind, stelle sicher, dass Header wie X-Forwarded-Proto und X-Forwarded-Host korrekt weitergeleitet werden, ohne von anderen Services überschrieben zu werden. Wenn du zusätzliche Schichten wie Cloudflare verwendest, überprüfe, dass diese Header nicht verändert oder entfernt werden, bevor sie deinen Nginx-Reverse-Proxy erreichen, da dies verhindern würde, dass n8n die korrekte sichere Redirect-URL generiert.

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

Bezüglich der Google Cloud Console-Einrichtung stelle sicher, dass der OAuth-Zustimmungsbildschirm deines Projekts ordnungsgemäß für die Staging-Umgebung konfiguriert ist. Wenn sich deine App derzeit in der Testphase befindet, musst du jedes Konto, das du zum Testen verwendest, explizit zur Liste „Testnutzer

4

hi Anshul!

Danke für deine Hilfe!

Ich habe die vorgeschlagenen Fixes angewendet — bekomme immer noch redirect_uri_mismatch.

Vorgenommene Änderungen:

  • N8N_PROXY_HOPS=1 zu .env hinzugefügt (bestätigt im Container via docker exec)

  • X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto zu nginx hinzugefügt

  • Sowohl nginx als auch n8n Container neu gestartet

Container env bestätigt, dass alle Variablen korrekt sind:

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

Googles Fehlerdetails zeigen:

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

Das stimmt genau mit dem überein, was in der Google Cloud Console registriert ist. Ich habe auch versucht, einen völlig neuen OAuth-Client nur mit dem Staging-Redirect-URI zu erstellen — derselbe Fehler.

Eine neue Credential auf Production (n8n.revvittsystems.com) zu erstellen funktioniert sofort mit derselben Google OAuth App. Das Problem ist spezifisch für die Staging-Instanz.

Die Credential wird von einem Nicht-Admin/Member-Konto erstellt, um den 414 URI Too Long Bug bei Admin-Konten zu vermeiden.

5

Hallo! Danke für deine Hilfe! Bitte schau dir meine Antwort auf @Anshul_Namdev an. Ich füge sie hier auch ein.

…

Hi Anshul!

Danke für deine Hilfe!

Ich habe die vorgeschlagenen Fixes angewendet — erhalte immer noch redirect_uri_mismatch.

Vorgenommene Änderungen:

  • N8N_PROXY_HOPS=1 zu .env hinzugefügt (im Container mittels docker exec bestätigt)

  • X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto zu nginx hinzugefügt

  • Sowohl nginx als auch n8n Container neu gestartet

Container-Umgebung bestätigt, dass alle Variablen korrekt sind:

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

Googles Fehlerdetails zeigen:

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

Dies stimmt genau mit dem überein, was in der Google Cloud Console registriert ist. Ich habe auch versucht, einen völlig neuen OAuth-Client zu erstellen, nur mit dem Staging-Redirect-URI — selber Fehler.

Eine neue Anmeldedaten auf Production (n8n.revvittsystems.com) zu erstellen funktioniert sofort mit derselben Google-OAuth-App. Das Problem ist spezifisch für die Staging-Instanz.

Die Anmeldedaten werden von einem Nicht-Admin-/Member-Konto aus erstellt, um den 414 URI Too Long Bug mit Admin-Konten zu vermeiden.

6

Sam, da Google exakt den staging-Callback zurückgibt, trenne das URL-Generierungsproblem vom OAuth-Client-Problem. Überprüfe, dass die staging-Redirect-URI auf derselben Web-Application-Client-ID ist, die n8n tatsächlich in den staging-Credentials verwendet; die URI auf einem zweiten Client im selben Projekt zu haben hilft nicht, wenn n8n weiterhin die erste client_id sendet.

Nächster deterministischer Check: Erstelle eine neue staging-Credential nach einem Hard Refresh, und vergleiche dann nur die redigierten Google-Error-Parameter: client_id-Suffix, redirect_uri, scope, access_type und prompt. Poste das Secret nicht. Wenn das client_id-Suffix nicht der staging-Client ist, den du erwartest, liegt die Nichtübereinstimmung im n8n-Credential-Datensatz; wenn es korrekt ist, liegt das Problem in der Google-OAuth-Client-Konfiguration/Ausbreitung statt in nginx.