症狀：為什麼表現成「登入轉圈」或整體 API 逾時

AWS MCP Server 與 Agent Toolkit for AWS 這類整合，常把「授權換票 → 列出模型／工具 → 呼叫推理或代理動作」壓在短時間內連續完成。若某一步要經由瀏覽器或裝置碼完成 OAuth，另一步要直打區域內的 bedrock-runtime.*.amazonaws.com 一類 API，還有一步要從 CloudFront 或文件站拉靜態說明，任何一段在 Clash 裡被寬規則提前送去錯誤出口、或該走穩定鏈路卻落進直連，你在介面上看到的多半不是逐行清楚的 TLS 錯誤，而是整體逾時、進度條停住、或登入視窗一直轉。瀏覽器開主控台「看起來正常」也不代表 IDE 內外掛或本機 MCP 子行程走同一套路由表：它們可能繼承不同的 HTTP_PROXY 環境變數、忽略系統代理、或被沙箱限制只認特定介面。

因此，處理這類問題的工程化做法始終是：用連線日誌還原真實主機字串，再把出現過的後綴收斂到同一策略意圖。關鍵字是「網域分流」與「混合路由」——不是先把節點換到延遲最低，而是先確認登入面、資料面、CDN 面是否被同一組規則送去你預期的策略組。產品與區域端點會演進，靜態抄一份網域表往往三個月後就漏命中；本專題強調日誌驅動補規則，與站内 連線日誌與逾時 的文法一致。

ℹ 起手三件事：系統時間與憑證鏈是否正常；同一授權流程內規則命中是否一致；本機HTTPS_PROXY／企業VPN是否讓 IDE 行程繞過 Clash。

與 Notion × AWS 協作專文差在哪

本站 Notion × AWS 處理的是協作軟體同步與其依賴的 Amazon 物件儲存等後綴，問題型態多半是「桌面 App 頁面不同步」「附件上傳卡住」。本篇則對準二〇二六年前後熱門的 MCP 伺服器／Agent Toolkit 開發鏈路：你要對齊的是 IAM 登入行為、區域Bedrock 推理端點、以及說明文檔／套件散佈可能使用的 CDN。兩種題材共用部分 amazonaws.com 詞根，但優先級、子域組合與風險取捨不同；把 Notion 專文的規則整段複製改名，最常發生的是細則順序錯亂或漏補 MCP 工作流程裡冒出來的新別名。

與偏重 IDE Marketplace 與插件下載廉的 JetBrains Central 相比，AWS 鏈多出區域隔離與 STS／SSO 維度：同一帳號在 ap-northeast-1 與 us-east-1 的資料面 DNS 並不相同，規則寫得太「全球一條總線」會誤傷延遲，寫得太碎又不易維護。折衷作法通常是：控制台與身分桶用較完整後綴，資料面以日誌中實際出現的區域主機為準逐步補齊。

MCP Server 與 Agent Toolkit 實際會敲哪些主機

具體主機名稱隨你安裝的套件版本、AWS 釋出與文件更新而變動，不宜在文章裡假裝成永久清單。就典型架構而言，本機 MCP 行程會透過官方 SDK 或 CLI 行為去碰：登入與權杖交換相關端點（可能涵蓋 signin.aws.amazon.com、身分供應商跳轉、或 OIDC 供應商網域）、服務控制平面與主控台讀取的設定 API、以及目標區域上的 Bedrock runtime／control plane資料面。另有很大機率會觸發承載套件說明、範例模板或前端資源的CDN 主機——它們的頂級後綴可能落在 cloudfront.net、awsstatic.com 這類命名空間。若你只把 console.aws.amazon.com 寫進規則而讓 *.amazonaws.com 落進預設 DIRECT，最常看到的就是控制台能開、模型呼叫卻在終端統一逾時。

進階使用者若同時開啟 Organizations、多帳號切換或跨區複寫，日誌裡會再疊 STS、Organizations API、CloudTrail 讀取等主機。Agent Toolkit 的官方範例若再串 GitHub Actions 或其他雲端，主機集合會更廣——本文仍以「在同一台開發機上先把 AWS 身分與 Bedrock 打通」為收斂範圍，其餘依日誌增補。需要挑一款日誌可讀的客戶端時，可先參考 客戶端選型。

三桶分類：登入／控制平面、區域資料面、CDN 靜態鏈

登入、身分與控制平面

OAuth 或 IAM Identity Center、以及傳統主控台登入流程，往往需要瀏覽器彈窗、裝置碼、或對外跳的供應商頁面。若授權主機被你規則表裡的另一條寬規則提前送去了你不想用的出口，體感同樣會是無限轉圈——因為換票請求在低層被拖死，上層只顯示「等待授權」。請把這類主機與接下來資料面請求規劃為同一策略意圖直到整條鏈打通，再考慮依隱私或頻寬細拆，而不是一開始就只代理 runtime。

區域資料面（含 Bedrock runtime）

Amazon Bedrock 呼叫多半落在所選區域的 *amazonaws.com 命名空間內（實際子域請以控制台顯示、SDK 錯誤訊息與連線日誌為準）。若環境強制區域資料落地，將流量誤送至其他區域出口，可能出現延遲暴增或被服務端拒絕；若完全直連卻遇到線路品質問題，則會在應用層被包裝成API 逾時。在可接受的誤傷範圍內，DOMAIN-SUFFIX,amazonaws.com 類後綴級規則便於維護，但可能把與本題無關的 AWS 服務一併帶走；若不可接受，就改為日誌驅動的精細清單並承擔較高補漏頻率。

CDN／靜態與載入鏈

文件、範例壓縮檔、或 IDE 插件市場拉 metadata 時，常經由邊緣 CDN。若 API 已走代理而某段靜態仍直連（或反過來），症狀仍可能是整體失敗。做法與其他 AI 工具專題相同：先把日誌出現過的 CDN 後綴與登入／資料面桶指向同一策略意圖，驗證通過後再依團隊政策細拆。細節可複習 規則分流最佳實踐 裡關於註解與順序的寫法，讓六個月後的你還敢改檔。

Bedrock 與區域端點：別只盯著單一 runtime 主機名

初學者常只搜尋「bedrock-runtime」字樣寫一條 DOMAIN，卻忽略列出模型、管理供應商設定、或讀取用量指標時還會碰其他服務子域。升級 SDK、切換推理設定檔、或啟用新的智慧體功能時，主機清單可能一夕改變；舊規則若仍「存在檔案裡」但不再命中，就會出現神秘的間歇性逾時。務必在每次大版本升級後重跑一次授權與最小推理範例，並保存那段時間的連線日誌 diff。若你同時用 Claude Code 或其他雲端模型 CLI 做對照實驗，也可讀 Claude Code 專文 裡「三桶＋日誌」框架，概念可直接平移，只在網域層換成 Amazon 實測結果。

策略組命名與「同一意圖」收斂

建議新建語意清楚的策略組，例如 AWS_MCP，並在設定註解寫明：「本機 MCP／Agent Toolkit／Bedrock 鏈」。Clash 規則由上而下命中即停，沒寫到的名稱會掉进 MATCH：若預設直連，只要出現一個對你環境不可靠的新子域，就回到登入或推理整體卡死。暫時改為「全域強制代理」若能立刻改善，幾乎可斷言是漏覆蓋或混合路由；長期仍應收斂成具體後綴，避免拖慢內網與本地服務。與企業出口政策牴觸時，請先與資安／網路團隊對齊允許清單，再落地規則檔。

DOMAIN-SUFFIX 示意與誤傷權衡

下列片段僅為示意：策略組名、GEOIP 與 MATCH 請依你的訂閱與環境自訂；重點是順序表達優先級，並讓登入、資料面與常見 CDN 後綴在驗證階段共享同一意圖。實際部署前請以連線日誌校對，勿盲抄。

Illustrative YAML fragment

rules:
  # Console and sign-in (adjust to your observed hosts)
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_MCP
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS_MCP
  # Data plane bucket (broad; narrow if needed)
  - DOMAIN-SUFFIX,amazonaws.com,AWS_MCP
  # Common doc / static CDNs (verify in logs)
  - DOMAIN-SUFFIX,cloudfront.net,AWS_MCP
  - DOMAIN-SUFFIX,awsstatic.com,AWS_MCP
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN-KEYWORD 對超大命名空間容易誤傷，不建議當主力。規則集能批次納入社群清單，但請確保規則集更新 URL 本身不被循環代理拖死，否則新別名永遠進不了表。站內 常見問題 可回頭查 DNS 基礎觀念。

OAuth、SSO 與本機回呼卡住時的三件事

第一，本機回呼：裝置授權或瀏覽器回跳若被防火牆、端點防護或企業政策擋在 localhost，Clash 再完美也無法完成 OAuth。第二，授權相關主機是否與後續 Bedrock 呼叫命中同一策略組；若前半段走高效出口、後半段直連卡在劣質路由，體感仍是整體失敗。第三，系統時間與中間人憑證：時間漂移或企業 TLS 檢查會讓握手看起來「停住」。釐清後再用日誌補 CDN 漏網之魚。

DNS、fake-ip、嗅探：為何 IDE 行程更挑剔

fake-ip 若與規則覆蓋順序不一致，會出現「解析看起來正確、分流決策卻不同」的割裂；殘留的 shell 代理環境變數、或 IDE 內嵌的獨立網路堆疊，也會讓 GUI 與終端子行程背離。排障順序應該是：先從日誌抓到真實主機字串，再對照規則命中與解析路徑，而不是先猜「AWS 掛了」。若你同時使用企業 VPN，請先確認路由表競合，再談更換節點供應商。

規則順序與 MATCH：避免假穩定

寬規則若排在細則之上，會出現「同事可以、你不行」的假隨機，因為訂閱版本或預設 MATCH 略有不同。API 逾時在這種背景下特別誤導：你會以為是節點品質問題，實則是規則順序問題。把 AWS MCP／Bedrock 相關段落集中在清單前段、並定期 diff 訂閱更新，比暴雷後通宵重裝有效得多。

TUN 與本機代理行程

不依循系統代理的程式，用 TUN 能快速驗證「是不是漏代理」：好處是一次收斂更多子行程；代價是與 VPN、虛擬機路由表更容易衝突。建議當成診斷手段與必要時常開選項，細節見 TUN 深度解析。在容器內跑 MCP 時，還要確認環境變數與 DNS 是否在該 network namespace 生效。

訂閱與規則集更新通道

若拉訂閱或規則集更新的 HTTP 請求被送去會失敗的出口，規則可能永遠停在上個版本，新出現的區域別名從未進清單。請先確保更新通道可靠，詳見 訂閱／節點維護。與其他終端 AI 題交錯閱讀時，保持「三桶＋日誌」框架不變，只在網域清單層換成 Amazon 實測結果即可。

⚠ 合規聲明：請遵守所在地法律、雇主資安政策與 AWS 服務條款。本文僅提供網路分流與除錯思路，不鼓勵未經授權存取或使用雲端資源。

合規環境自檢清單

  1. 確認你對目標帳號、區域與 Bedrock 功能具合法授權與組織許可。
  2. 校準系統時間，排除攔截本機 OAuth 回呼的資安套件。
  3. 登入、主控台讀取、runtime 呼叫各取一段連線日誌：是否命中預期策略組。
  4. 檢查 fake-ip／嗅探組態是否與規則集版本一致；必要時對關鍵後綴補先手規則。
  5. 審視規則順序，確認沒有寬規則遮擋 AWS 細則。
  6. 驗證訂閱與規則集能成功更新，沒有循環代理或 TLS 攔截。
  7. 若僅在特定 IDE 外掛或容器失敗，檢查環境變數、TUN／VPN 競合後再評估節點品質。
  8. 若誤傷面不可接受，將大後綴拆細並以規則集版本管理。

每次只改一項設定並留存日誌快照，才能把運氣變成可維護的 網域分流 方案。

常見問題

問：我已經代理主控台，為什麼還要管 CloudFront？
答：工具鏈可能在背景拉說明或範例資源；其中一段直連卡住時，整體仍可能以API 逾時呈現。三類主機應共享同一策略意圖直到驗證通過，再談細拆。

問：DOMAIN-SUFFIX,amazonaws.com 會不會太大包？
答：可能把與本題無關的 AWS 服務一併帶走，這是維護成本與誤傷的交換。可行做法是：先用大包驗證問題是否在混合路由，再逐步改為日誌驅動的精細清單。

問：需要為 MCP 單獨開一個節點嗎？
答：不一定。多數情境下策略組一致比「專屬節點」更關鍵；節點品質是在路由一致之後才該挑的第二層。

結語

在本地或 IDE 使用 AWS MCP Server、Agent Toolkit for AWS 與 Amazon Bedrock 時，穩定性多半取決於 OAuth／身分、區域資料面 API、以及CDN 靜態鏈是否被 Clash 以一致策略接起來，並以連線日誌對回具體主機名。把這件事做好，官方的模型清單與區域端點演進後，你能快速補規則，而不是整晚盲換節點。

市面上一體化「懶人梯子」常以黑箱換簡單：延遲數字好看也未必解釋得了為何 STS 換票卡住或哪段 CloudFront 反覆逾時。Clash V.CORE 的定位是把網域分流寫成可讀、可驗證的結構：策略組、DOMAIN-SUFFIX、規則集與清晰的命中順序，讓 AWS 開發鏈上的問題回到工程可解範圍。

單純 VPN或只提供匣選單的圖形代理，在臨時翻牆時或許足夠，但長期對齊雲端 API 開發時，往往缺乏規則粒度與日誌透明度，同一種混合路由會在不同 IDE 版本間反覆出現。Clash V.CORE 支援規則模式與 TUN 並用，相容現代內核與規則集生態，讓 MCP 與 Bedrock 調校真正有憑有據。

→ 免費下載 Clash V.CORE：用具可追溯的策略與日誌，把 AWS MCP／Bedrock 放回可預期的網域分流流程。