<n8n version: 2.20.7
Base de données: SQLite (par défaut)
Exécuté via: Docker (auto-hébergé, Ubuntu 24.04 sur DigitalOcean)
Proxy inverse: nginx avec SSL via Certbot/Let’s Encrypt
Problème:
J’ai deux instances n8n auto-hébergées:
Production: n8n.revvittsystems.com — OAuth Gmail fonctionne parfaitement, y compris la création de nouvelles identifiants
Staging: staging.revvittsystems.com — OAuth Gmail échoue avec Erreur 400: redirect_uri_mismatch à chaque fois
Les deux instances exécutent n8n 2.20.7 sur Docker avec proxy inverse nginx. Les deux utilisent la même application OAuth Google Cloud (même ID client/Secret). J’ai également essayé de créer un client OAuth complètement séparé avec uniquement l’URI de redirection de staging — même erreur.
Ce que j’ai confirmé:
L’URI de redirection affiché dans l’interface de staging n8n est https://staging.revvittsystems.com/rest/oauth2-credential/callback
Cet URI exact est enregistré dans la console Google Cloud sous URIs de redirection autorisés
J’ai décodé l’URL d’erreur Google et confirmé que l’URI redirect_uri que n8n envoie est https://staging.revvittsystems.com/rest/oauth2-credential/callback — il correspond exactement
X-Forwarded-Proto $scheme est configuré dans nginx afin que n8n génère correctement le préfixe https://
L’application est publiée en Production sur l’écran de consentement OAuth Google
Testé en mode incognito — même erreur
La création d’une nouvelle identifiant en production fonctionne immédiatement — l’application OAuth Google elle-même fonctionne bien
La création d’un client OAuth complètement nouveau et séparé uniquement pour staging échoue également avec la même erreur
.env de Staging:
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
Configuration nginx de Staging:
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;
}
}
Note supplémentaire: Lorsque je suis connecté en tant que propriétaire/administrateur sur staging, cliquer sur « Se connecter avec Google » donne une erreur 414 URI Trop long (bug connu de n8n où les portées admin sont ajoutées à l’URL). La création à partir d’un compte de membre non-administrateur dépasse l’erreur 414 mais atteint le redirect_uri_mismatch.
Question: Qu’est-ce qui d’autre pourrait causer redirect_uri_mismatch quand l’URI est confirmé correct et correspond exactement? Y a-t-il quelque chose de spécifique au flux OAuth de n8n 2.20.7 qui pourrait causer ceci sur une instance nouvelle?!-- Hé! Le moyen le plus rapide de trouver des solutions est d’utiliser la fonction 
de recherche en haut à droite.
Si votre question n’a pas été posée auparavant, veuillez suivre le modèle ci-dessous. Ignorez les questions qui ne vous sont pas pertinentes.
Vous pouvez poster dans n’importe quelle langue - nous allons traduire votre message pour vous!
→
Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant)?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
- Version n8n:
- Base de données (par défaut: SQLite):
- Paramètre n8n EXECUTIONS_PROCESS (par défaut: own, main):
- Exécution n8n via (Docker, npm, n8n cloud, application de bureau):
- Système d’exploitation: