Google OAuth dietro reverse proxy: le 4 variabili che n8n non ti dice

Tempo di lettura: 6 minuti — Livello: intermedio

Il sintomo

Hai n8n self-hosted dietro un reverse proxy (nel mio caso un Cloudflare Tunnel). Provi a collegare le credenziali Google — Gmail, Sheets, Calendar, non importa — e al momento del "Sign in with Google" ti becchi un secco:

Unauthorized

Nessun dettaglio, nessun log utile. Solo quello. Se sei qui, probabilmente hai già provato a rifare le credenziali OAuth su Google Cloud Console tre volte. Non è quello il problema.

La causa

Quando n8n sta dietro un reverse proxy, succede questo: il proxy riceve la richiesta in HTTPS sul tuo dominio pubblico, ma la inoltra a n8n in HTTP su localhost. n8n, che non sa di essere dietro un proxy, costruisce l'URL di callback OAuth usando quello che vede lui — cioè l'indirizzo interno sbagliato. Google confronta il callback con quello registrato nella console, non coincide, e il flusso muore con "Unauthorized".

La documentazione ti dirà che serve N8N_PROXY_HOPS. È vero. Ma da sola non basta — e questo è il pezzo che mi è costato una serata.

La soluzione: 4 variabili, tutte insieme

Nel tuo env file (o nel docker-compose) servono tutte e quattro queste variabili:

N8N_EDITOR_BASE_URL=https://n8n.tuodominio.it/
N8N_PROXY_HOPS=1
N8N_PROTOCOL=https
N8N_HOST=n8n.tuodominio.it

Cosa fa ciascuna:

• N8N_EDITOR_BASE_URL — l'URL pubblico completo con cui n8n costruisce i link, incluso il redirect OAuth. Occhio allo slash finale.
• N8N_PROXY_HOPS=1 — dice a n8n di fidarsi degli header X-Forwarded-* del proxy (1 = un proxy davanti; se hai più livelli, aumenta il numero).
• N8N_PROTOCOL=https — forza il protocollo negli URL generati. Senza, n8n può produrre callback in http:// che Google rifiuta.
• N8N_HOST — l'hostname pubblico, senza protocollo e senza slash. Poi ricrea il container (le env si leggono all'avvio, un semplice restart del processo non basta se cambi l'env file esterno):

docker stop n8n && docker rm n8n
docker run -d --name n8n \
  --network la-tua-network \
  -v n8n_data:/home/node/.n8n \
  --env-file /percorso/n8n.env \
  la-tua-immagine-n8n

⚠️ Se usi un volume per i dati, verificalo prima di rimuovere il container: la encryption key di n8n vive nel volume, non nell'env file. Perdere il volume = perdere tutte le credenziali salvate.

Lato Google Cloud Console

Per completezza, nel tuo OAuth Client (tipo "Web application") il redirect URI autorizzato deve essere:

https://n8n.tuodominio.it/rest/oauth2-credential/callback

Esattamente quello, con il tuo dominio pubblico. Se hai le 4 variabili a posto, è l'URL che n8n mostrerà nella schermata delle credenziali — copia quello e incollalo nella console.

Perché nessuna delle guide te lo dice

Perché ognuna delle quattro variabili, presa singolarmente, ha una sua documentazione sensata — ma nessun punto della doc dice "per OAuth dietro proxy servono tutte insieme". Il risultato è che nei forum trovi gente che ne ha impostata una, o due, e continua a vedere "Unauthorized" convinta che il problema sia altrove.

La lezione generale, che vale al di là di n8n: quando un'app self-hosted sta dietro un reverse proxy, l'app deve sapere di esserci. Il proxy risolve il problema per il traffico in entrata, ma tutto ciò che l'app genera (URL, redirect, link nelle email) usa la configurazione interna. Ogni volta che vedi un URL sbagliato spuntare da un'app dietro proxy, la causa è quasi sempre questa.

Checklist rapida

1. ✅ Le 4 variabili nell'env file
2. ✅ Container ricreato (non solo riavviato)
3. ✅ Redirect URI in Google Cloud Console = quello mostrato da n8n
4. ✅ Volume dati preservato Se dopo tutto questo hai ancora problemi, apri gli strumenti sviluppatore del browser durante il flusso OAuth e guarda il parametro redirect_uri nella richiesta verso Google: ti dice esattamente quale URL n8n sta generando, ed è lì che si vede subito quale variabile manca.

---

Questo articolo fa parte della serie "Stack & Infrastruttura" su perfetti.tech — dove racconto quello che costruisco davvero, errori compresi.