<n8n 版本：2.20.7
資料庫：SQLite（預設）
執行方式：Docker（自架式，Ubuntu 24.04 on DigitalOcean）
反向代理：nginx 搭配 SSL（Certbot/Let’s Encrypt）
問題：
我有兩個自架的 n8n 執行個體：
生產環境：n8n.revvittsystems.com — Gmail OAuth 運作完美，包括建立全新的認證資料
預備環境：staging.revvittsystems.com — Gmail OAuth 失敗，每次都出現 Error 400: redirect_uri_mismatch
兩個執行個體都在 Docker 上執行 n8n 2.20.7，使用 nginx 反向代理。兩者都使用相同的 Google Cloud OAuth 應用程式（同一個用戶端 ID/密鑰）。我也嘗試建立了一個全新的 OAuth 用戶端，僅包含預備環境的重新導向 URI — 出現相同的錯誤。
我已確認的事項：
預備環境 .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
預備環境 nginx 設定：
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;
}
}
額外說明：以擁有者/管理員帳戶登入預備環境時，點選「使用 Google 登入」會出現 414 URI Too Long 錯誤（n8n 的已知問題，會將管理員範圍附加至 URL）。以非管理員成員帳戶建立時會越過 414 錯誤，但會遇到 redirect_uri_mismatch。
問題：當 URI 已確認正確且完全相符時，還有什麼會導致 redirect_uri_mismatch？n8n 2.20.7 的 OAuth 流程中是否有特定之處可能導致全新執行個體出現此問題？
描述問題/錯誤/問題
錯誤訊息是什麼（如果有的話）？
請分享您的工作流程
(選取畫布上的節點，使用鍵盤快速鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 複製和貼上工作流程。)
分享最後一個節點傳回的輸出
您的 n8n 設定資訊
- n8n 版本：
- 資料庫（預設：SQLite）：
- n8n EXECUTIONS_PROCESS 設定（預設：own, main）：
- 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：
- 作業系統：
嗨 @Sam_Rao，歡迎！
我認為你的 n8n_proxy_hops 要麼未設置，要麼根據你的設置設置不正確，該環境變數應該看起來像這樣：
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
並確保你的 Nginx 配置也啟用了這些設置：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
重新啟動後，請告訴我進展如何。
Hi @Sam_Rao
你在預備環境上遇到的重定向 URI 不符問題是 n8n 部署中常見但令人沮喪的障礙。即使 URL 看起來完全相同，Google 的認證伺服器也極為嚴格。該程序要求 Google Cloud Console 中定義的值與 n8n 在其請求中發送的值完全相符，字元對字元。即使只有一個字元不同，例如遺漏尾部斜線，認證也會立即被拒絕。
導致此錯誤最常見的原因之一，特別是在組態變更後，是 Google 的全球傳播延遲。即使你已在 Google Cloud Console 中更新了授權重定向 URI，這些變更也可能需要數小時才能在 Google 基礎設施中傳播。如果你最近修改了這些設定，最可能的解決方案是等待幾小時後再試一次，因為系統可能仍在使用舊組態。
驗證你的 Docker 容器內的環境變數是否與預期相符也至關重要。雖然你的 .env 檔案看起來正確，但由於快取或容器的初始化方式，執行中的 n8n 程序可能具有不同的組態。執行指令從容器內部列印環境變數將幫助你確認 WEBHOOK_URL 和 N8N_PROTOCOL 設定是否正確應用，而非預設為內部的錯誤值。
docker exec <container_id> env
你也應該檢查 Nginx 組態是否存在任何潛在衝突。雖然你目前的設定是標準設定，但要確保 X-Forwarded-Proto 和 X-Forwarded-Host 等標頭被正確傳遞，且未被其他服務覆寫。如果你使用了 Cloudflare 等額外層，請驗證它們在到達 Nginx 反向代理前是否未修改或剝除這些標頭，因為這樣會導致 n8n 無法產生正確的安全重定向 URL。
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
關於 Google Cloud Console 設定，請確保你專案的 OAuth 同意畫面已正確設定預備環境。如果你的應用程式目前處於測試階段，你必須在控制台內的「測試使用者」清單中明確新增任何你用於測試的帳戶。此外，請確保專案設定沒有網域限制，以免導致預備網域被視為不同於生產環境。
最後，你的管理員帳戶遇到的 414 錯誤表示產生的 OAuth URL 超過了典型的字元限制。這是由於範圍和狀態資料的累積而引起的已知問題。使用非管理員帳戶成功完成認證是繞過此問題的最佳方式，因為它允許初始握手發生並建立未來互動所需的必要工作階段 Cookie。將產生的 URL 參數與你的控制台組態並排比較仍然是識別任何隱藏差異的最確定方式。
嗨 Anshul！
感謝你的幫助！
我應用了建議的修正 — 仍然收到 redirect_uri_mismatch 錯誤。
進行的變更：
容器環境確認所有變數正確：
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
Google 的錯誤詳情顯示：
redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback
這與在 Google Cloud Console 中註冊的內容完全相符。我也試過建立一個全新的 OAuth 用戶端，只設定 staging 重新導向 URI — 出現同樣的錯誤。
在生產環境（n8n.revvittsystems.com）上建立新憑證會立即運作，使用相同的 Google OAuth 應用程式。此問題特定於 staging 實例。
該憑證是從非管理員／成員帳戶建立的，以避免管理員帳戶的 414 URI Too Long 錯誤。
嗨！謝謝你的幫助！請查看我對 @Anshul_Namdev 的回覆。我也在這裡附上它。
…
嗨 Anshul！
謝謝你的幫助！
我應用了建議的修復 — 仍然收到 redirect_uri_mismatch 錯誤。
進行的更改：
容器環境變數確認所有變數都正確：
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
Google 的錯誤詳情顯示：
redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback
這與在 Google Cloud Console 中註冊的內容完全匹配。我也嘗試過建立一個完全新的 OAuth 用戶端，只包含預備環境重新導向 URI — 同樣的錯誤。
在生產環境（n8n.revvittsystems.com）上建立新的憑證可以立即與相同的 Google OAuth 應用程式搭配使用。該問題特定於預備環境實例。
該憑證是從非管理員/成員帳戶建立的，以避免管理員帳戶出現 414 URI Too Long 錯誤。
Sam，既然 Google 正在回應完全相同的 staging callback，請將 URL 生成問題與 OAuth 用戶端問題分開。檢查 staging redirect URI 是否在 n8n 實際在 staging credential 中使用的相同 Web 應用程式用戶端 ID 上；如果 n8n 仍然發送第一個 client_id，將 URI 放在同一專案中的第二個用戶端上將毫無幫助。
下一個確定性檢查：在硬刷新後建立新的 staging credential，然後只比較已編輯的 Google 錯誤參數：client_id 後綴、redirect_uri、scope、access_type 和 prompt。不要發佈密鑰。如果 client_id 後綴不是您預期的 staging 用戶端，不匹配在 n8n credential 記錄內部；如果正確，問題在 Google OAuth 用戶端配置/傳播中，而不是 nginx。