描述問題/錯誤/問題
我在嘗試設定我的 Google OAuth2 Client ID 時收到一個錯誤通知。我過去成功完成過這個設定，它一直都能正常運作。但使用這個新的 Gmail 帳戶時，我總是會收到以下錯誤：
n8n 設定資訊
- n8n 版本： 透過 Hostinger 自託管
你看到的錯誤訊息（「嘗試的動作失敗，請重試」）實際上來自 Google 自己的 Cloud Console，而不是來自 n8n。這是一個通用訊息，表示 Google 的系統在嘗試儲存你的 OAuth 用戶端設定時發生故障。這通常是因為瀏覽器中的衝突，而不是 n8n 設定中的錯誤。
最常見的原因是在同一個瀏覽器工作階段中登入多個 Google 帳戶，這經常會導致 Google Cloud Console 混淆。若要修正這個問題，最快的解決方案是開啟一個無痕或隱私視窗，然後只登入你用於此設定的特定 Google 帳戶。如果這不起作用，請嘗試停用瀏覽器擴充功能（例如廣告攔截器）或清除瀏覽器的快取和 Cookie。
最後，請再次確認你已選擇「Web 應用程式」作為應用程式類型。當貼上來自 n8n 的重新導向 URI 時，請確保連結的開頭或結尾沒有意外的空格。由於你是透過 Hostinger 進行自我代管，請同時驗證你的 n8n 環境變數 WEBHOOK_URL 是否正確設定，並包含 https:// 字首，因為缺少協定可能會導致 Google 拒絕該請求。
由於瀏覽器的變更並未解決問題，我建議暫時不要把這當作 n8n 的問題，而是直接測試 Google 專案本身。如果同一個 Google 帳戶或專案無法建立任何 OAuth 用戶端，問題可能出在 Google 那一方，而不是 n8n。你能確認一下這是全新的專案，還是從舊的設置重複使用的專案嗎？
@OMGItsDerek 非常感謝你的回覆..這是一個全新的專案。我其實是在為和我在同一個組織工作的同事設定這個。我再次確認過::當我在我的 Google Console 中新增另一個用戶端時,我沒有遇到任何問題。但對她來說,我總是收到相同的錯誤通知。有什麼訣竅可以解決這個問題嗎?
根據你提供的新資訊，以下是可能發生的情況
你看到的錯誤是一個通用的「包羅萬象」訊息，這表示 Google 知道出了問題，但沒有告訴你確切是什麼。由於你可以為自己建立用戶端，但無法為同事的新帳戶建立，問題不在於程序本身，而很可能是該特定新帳戶上遺失的設定或限制。
最常見的罪魁禍首是「OAuth 同意畫面」。可以把它想象成使用者登入時看到的數位「歡迎墊」。每個全新的專案都需要自己的同意畫面才能完全設定。如果任何必填欄位是空的，或者沒有「儲存並繼續」到最後，Google 就會阻止你建立用戶端 ID。
你也應該檢查帳戶權限。即使你的同事是你組織的一部分，她可能沒有這個特定專案的「編輯者」或「擁有者」角色。如果她只有「檢視者」或有限存取權限，主控台可能會讓她開啟建立頁面，但一旦她試著實際儲存新 ID，就會觸發錯誤。
因為這是全新的 Gmail 帳戶，Google 可能在套用暫時的安全「冷卻期」。為了防止垃圾郵件，Google 有時會限制新帳戶在幾天內建立安全認證。此外，請確保應用程式設定為「內部」（僅供貴公司使用），而不是「外部」，因為外部應用程式需要更嚴格的驗證程序。
不要忽視簡單的瀏覽器故障。Google Cloud 主控台非常複雜，經常被來自其他帳戶的舊 Cookie 或快取資料搞混。簡單地切換到「無痕」或「隱私」視窗，或嘗試完全不同的瀏覽器，往往能清除這些沒有明確技術原因的「幽靈」錯誤。
要快速解決這個問題，首先嘗試使用無痕視窗。如果這不行，回到「OAuth 同意畫面」並確保每一頁都已填寫並儲存。最後，驗證你的同事是否在專案的 IAM 設定中列為「編輯者」。如果這些都失敗了，等待 24 到 48 小時讓新帳戶被系統完全信任。
這通常發生在 webhook URL 或 n8n 公開 URL 錯誤或未正確設定時，導致 OAuth 重導向 URL 生成不正確。
這在新帳戶上發生時，通常是因為尚未先設定 OAuth 同意畫面。在建立 Client ID 之前：
-
前往 APIs & Services > OAuth consent screen 並完成設定
-
然後前往 APIs & Services > Library 並啟用你需要的特定 API（Gmail API、Google Drive 等）
-
然後建立認證
如果你已經執行過這些步驟，請嘗試在無痕視窗中操作；Google Cloud Console 有時會快取不良狀態，導致無法建立認證。
前往 Google Cloud Console 中的 OAuth 同意畫面設定。查看 使用者類型。如果設定為 內部，它會立即拒絕任何電子郵件網域名稱與您不同的人。將使用者類型變更為 外部，儲存變更，然後嘗試新增他們。
請讓我知道這是否有效，或者你們是否使用相同的電子郵件。
我遇到同樣的問題，我使用的回呼 URL 是正確的，但我不知道如何解決這個無用的問題。我已經將 3 個 Gmail 帳號連接到一個帳戶，這可能是 Google 封鎖我的原因嗎？我應該托管新的 n8n 實例還是什麼？
感謝 @SE-automations，但我其實已經設定為外部了。我收到相同的錯誤
@Oguzhan_Murat 這也會是我第3個連接的帳戶。我之前從未遇過問題，但這個帳戶有問題。不過我也不確定這是否真的是問題所在
@Asim_Arman 非常感謝。我之前已經啟用了所有需要的 API。不幸的是，這並沒有改變什麼。無痕模式也沒有幫助。真的很奇怪！
嘿，我是完全的新手，但在設置時遇到了完全相同的問題。我用AI找到了我的解決方案，希望能幫助大家 
Google 在品牌區域中不再允許 Hostinger 的標準域名作為頂級域名。那裡必須註冊自己的域名。
解決方案很簡單：使用自己的域名，通過 CNAME 記錄創建一個子域名（例如，前面加上 api.），然後在 Hostinger 面板中通過 .yaml 編輯器輸入。這樣 Hostinger 域名就會消失，一切都能正常運作。
作為其餘 Google 連接的參考，這個視頻會有幫助：
以下是步驟的簡短摘要：
1. 在域名提供商創建 CNAME 記錄
主網站不會被更改。只是在自己的域名提供商處創建一個子域名：
-
類型：
CNAME -
主機名/名稱：
api（或其他縮寫） -
目標/值： 完整的 Hostinger 地址，末尾帶一個點（例如
n8n.srvXXXXX.hstgr.cloud.）。 -
*重要（將「子域名？」選項保持停用，不要忘記 URL 末尾的點！
2. 在 Hostinger hPanel 中進行調整
為了讓 n8n 使用新地址，需要在 Hostinger 中調整 Docker 項目：
-
在 VPS 菜單中前往 Docker 管理器 → 項目，管理 n8n 項目。
-
在下方的環境區域中更改變量：
-
DOMAIN_NAME=eigene-domain.de（主域名，不包括 www 或 https） -
SUBDOMAIN=api（選擇的 CNAME 縮寫）
-
-
點擊保存並部署。Hostinger 將重新啟動 n8n 並生成 SSL 證書。
3. 完成 Google Cloud Console
-
OAuth 同意屏幕： 在授權的域名中現在輸入自己的主域名（例如
eigene-domain.de）。Google 現在會立即接受這個頂級域名。 -
憑據： 在 OAuth 客戶端 ID 下的授權的重定向 URI 中，使用新域名輸入 n8n 回調 URL：
https://eigene-domain.de
很抱歉沒有成功，也許這個修復方法會有幫助：
在 Google Cloud 中，前往 OAuth 同意畫面標籤。在「使用者類型」下，如果你使用的是標準的 @gmail.com 帳戶，你必須將其保持為「外部」，但要尋找「發佈狀態」部分。確保它設定為「測試模式」（不要點擊「發佈應用程式」）。最後，你必須明確地將你的新 Gmail 地址新增到下方的「測試使用者」清單中。如果你的電子郵件不在測試清單上，Google 會阻止連線。
讓我知道這是否有效。
歡迎來到 n8n 社區 @Benjamin2
由於在您的帳戶上可以運作，但在您同事的帳戶上卻失敗，我會檢查 Google Workspace 的權限/限制，或使用具有 Owner/Editor 角色的帳戶在專案中建立 OAuth Client。只需複製 Google 憑證中的 OAuth Redirect URL，並將其貼到 Authorized redirect URIs 中。
如果仍然出現錯誤，請分享您的 json（不含敏感資料），以便我們更好地了解情況。
我有相同的問題。一個在大約一週前還能正常運作的 Google Calendar 憑證突然停止工作了。
我的 Google Cloud Console 應用程式不再接受 Hostinger URL。
嘿，各位，
非常感謝你們的回覆。最後我設法解決了。
遺憾的是，我無法確切說出到底是什麼修復了這個問題。我最好的猜測是我創建的 Google Cloud 專案設定有些問題。
我沒有對 Hostinger、網域設定或類似的任何東西進行任何更改來讓它運作。我只是重新嘗試了一次，並使用了最初的預設專案「My First Project」，沒有重新命名它。
突然間，一切都正常了。
再次感謝你們的幫助！
@albertocv 關於 Hostinger URL 問題 - Google 開始對 OAuth 授權來源強制執行更嚴格的網域驗證。常見的解決方案：確保「授權 JavaScript 來源」項目完全符合你的 Hostinger 網域（包括協議，例如 https://yourapp.hostinger.com 不含尾部斜線），並將 n8n 執行個體的回呼 URL 新增至「授權重新導向 URI」，格式為 https://yourapp.hostinger.com/rest/oauth2-credential/callback。如果你使用 Hostinger 子網域，也可以嘗試在 OAuth 同意畫面中新增根網域作為授權網域。
我會先檢查這是 Google Cloud OAuth 設定問題，而不是 n8n 工作流程問題。
通常的檢查清單是：
1. 在 Google Cloud Console 中，確認 OAuth 用戶端類型是「Web 應用程式」，而不是「桌面應用程式」。
2. 將 n8n Google 認證畫面上顯示的確切 n8n 重新導向 URL 加入「已授權的重新導向 URI」。必須完全相符，包括 http/https 和任何路徑。
3. 如果 OAuth 同意畫面仍處於「測試」狀態，請在「測試使用者」下新增你正在使用的 Gmail 帳戶。
4. 為認證啟用必要的 API，例如根據節點類型啟用 Gmail API 或 Google Sheets API。
5. 變更重新導向 URI 或同意設定後，在 n8n 中建立新的認證連線，而不是重複使用舊的失敗快顯視窗。
對於自託管 n8n，也要檢查你的公開 n8n URL 是否穩定，以及 WEBHOOK_URL / N8N_EDITOR_BASE_URL 是否指向你在瀏覽器中使用的相同公開網域。這裡的不相符通常會建立錯誤的回呼 URL。
可以從 n8n 認證回呼 URL 的已編輯螢幕擷取畫面和 Google Cloud OAuth 重新導向 URI 清單以非同步方式診斷。不需要帳戶存取。