IDE 調用 AWS MCP Server 總逾時？2026 以 Clash 穩定 AWS API 分流實測步驟

為什麼 AWS MCP Server 進 IDE 後，特別容易「看得到外掛、拿不到雲端」？

2026 年起，AWS MCP Server與周邊的 Agent Toolkit、範本與文件把「用自然語言在編輯器裡查帳號狀態、列資源、叫用受控 API」這件事變得更可複製。對已習慣 Clash 或 Mihomo 做開發者代理的讀者來說，麻煩卻往往不在「完全沒網路」，而在路徑分裂：同一台機器上，Chrome 打開 AWS 管理主控台很順，Cursor 或 VS Code 面板裡的 MCP 工具卻對 IAM、Security Token Service（STS）、或形如 bedrock-runtime.*.amazonaws.com 的區域端點報逾時；有時則卡在登入跳轉、裝置授權頁載入不全，讓人誤以為是外掛版本壞掉或訂閱權限不足。

這類問題的典型根因，是 AWS API 呼叫鏈會同時碰到全球型服務主機、區域型端點、以及與瀏覽器 SSO 相關的網域；任一環節若被過大的 GEOIP 規則提早結束比對、或被導向與瀏覽器不同的出口，就會出現「只有 IDE 子行程不穩」的表象。本文與站內 泛用 MCP 工具鏈分流專文的分工在於：那篇收斂 npm、GitHub、PyPI 與一般遠端 MCP 傳輸；本篇則點名 AWS 主機家族與憑證／STS 行為，給一套可抄寫後再依日誌微調的 AWS API 分流流程，並可直接搭配 Cursor／VS Code 擴充生態專文理解「編輯器是否偵測到系統 Proxy」這一層。

合規提醒：Clash／Mihomo 與 Clash Verge Rev 等用戶端負責本機轉送與規則管理，不提供遠端節點。請在合法授權與公司政策允許下使用 AWS 服務，並遵守當地法規；本文主機名與規則僅供網路除錯參考，實際端點以官方文件與您帳號區域為準。

症狀分桶：逾時、登入轉圈、還是規則誤中？

實務上建議先把現象分成三桶，避免一上來就換訂閱或重灌 IDE。第一桶是純 API 逾時：日誌裡反覆出現對 sts.amazonaws.com、iam.amazonaws.com、或某區域 *.amazonaws.com 的 HTTPS 長連線中斷，錯誤訊息偏 ETIMEDOUT、context deadline exceeded 這類語意。第二桶是瀏覽器才能完成、外掛永遠等不到回呼：常見於裝置碼登入或組織要求經由特定 IdP，若只有瀏覽器走 TUN 或系統 Proxy，而啟動 MCP 子行程的環境變數沒對齊，就會形成半套登入。第三桶則是規則誤導：延遲看起來像「節點偶爾全紅」，其實是您把整段 amazonaws.com 塞進過寬的 RULE-SET 或更早的 MATCH，讓部分請求去了不適合 STS 長握手的出口。

因此除錯的第一個動作永遠是把真實主機名寫下來。不論您使用 Clash Verge MCP 相關教學截圖哪種皮膚，核心日誌裡顯示的 SNI 才是最終要寫進 DOMAIN-SUFFIX 或 Provider 的依據；憑印象複製論壇清單而跳過這一步，後面會很難收斂。

AWS 側常見主機輪廓（用作規則起點）

下列分組不是「永遠正確的防火牆白名單」，而是您在連線列表里最常需要對照的後綴家族。若某工具改用 CloudFront 別名或新子域，請以日誌為准補上。

  • 身分與會話：sts.amazonaws.com、sts.*.amazonaws.com（部分區域或其他服務附帶 STS 路徑）、iam.amazonaws.com、以及組織常用的 IAM Identity Center 相關主機（實際名稱請從登入流程複製）。
  • 區域 AWS API：大多形如 服務名.區域代碼.amazonaws.com，例如 ec2.ap-northeast-1.amazonaws.com、bedrock-runtime.us-east-1.amazonaws.com；分流粒度可以是 DOMAIN-SUFFIX,amazonaws.com 再配例外直連，或依服務拆細。
  • 主控台與登入體驗：console.aws.amazon.com、signin.aws.amazon.com、portal.aws.amazon.com、文件站 docs.aws.amazon.com；這些更常出現在「人在瀏覽器授權、IDE 等回呼」場景。
  • 套件與發佈鏈：官方範本、Smithy 模型或 CLI／SDK 下載有時仍會碰到 aws.amazon.com 子域、github.com、registry.npmjs.org；若外掛在啟動時順便拉範本，請併讀 工具鏈專文避免只修 AWS 後綴卻漏了套件機。

若您使用企業PrivateLink 或內部 API 閘道，公開文件里的主機名可能完全不適用；此時仍適用本文的方法論（置前規則、獨立群組、DNS 對齊），但條目必須改成您內網的私有 DNS 名稱。

規則順序：為什麼「我加了 amazonaws.com 卻沒效」？

在 mode: rule 下，Clash 家族核心採自上而下、命中即停。若訂閱合併後的實際串列里，先有寬泛的 GEOIP,CN,DIRECT、巨大的 RULE-SET、或兜底的 MATCH,PROXY，而您手寫的 AWS 細則被排在後面，表面上就會表現成「規則檔明明有存檔，連線卻完全不照抄」。實務請在圖形用戶端或文字編輯器捲到最終合成的 rules，而不是只看您剪貼的片段。

與 國內外分流骨架並用時，請特別注意「國內直連」類條目是否會誤傷您認為應出海的 API：某些網路環境下，把全部 amazonaws.com 丟進單一 PROXY 反而比半套直連穩，因為 STS 握手的時間Budget 很吃往返一致性。

策略群組設計：建議單獨開一個 AWS_MCP

許多人習慣所有海外貨都叫 PROXY，但 IDE 外掛需要的是可對照的重現性：當 MCP 逾時時，您要能一鍵把出口改成手選節點做 A／B。建議至少拆出一個 select 型 AWS_MCP，內含一組 url-test 子群與 DIRECT 對照，並在 Clash Verge Rev 面板用易搜尋的短名稱，避免與訂閱自動注入撞名。

當測速全綠但 AWS API 仍斷線時，優先手動固定節點做實驗；若固定後立刻穩定，問題多半在 url-test 的 interval 與 tolerance 讓長工作階段中頻繁換出口。可參考 健康檢查與容忍值專文微調，而不是盲目新增 DOMAIN。

YAML 骨架範例（請替換為您環境的真實節點名）

以下片段示範在寬泛兜底前插入 AWS 相關後綴；區域政策允許直連的服務請自行加更早的 DIRECT 規則，勿未審核即套用於生產帳號：

YAMLproxy-groups:
  - name: "AWS_MCP"
    type: select
    proxies:
      - "AWS_AUTO"
      - "Hand-Picked-Stable"
      - DIRECT
  - name: "AWS_AUTO"
    type: url-test
    proxies: []
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 40

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Put BEFORE broad GEOIP / catch-all MATCH
  - DOMAIN-SUFFIX,amazonaws.com,AWS_MCP
  - DOMAIN-SUFFIX,amazonaws.com.cn,AWS_MCP
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_MCP
  - DOMAIN,signin.aws.amazon.com,AWS_MCP
  - DOMAIN,portal.aws.amazon.com,AWS_MCP
  - DOMAIN,console.aws.amazon.com,AWS_MCP
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若您尚未完成訂閱匯入，可先依 訂閱匯入教學建立基礎群組，再把上列 proxies: [] 換成實際節點名稱，以免出現「規則引用不存在的 group」的合成錯誤。

IDE 與子行程：Clash 開了，MCP 為什麼仍可能直連？

Cursor、VS Code 與其外掛宿主在啟動子行程時，未必繼承您 shell 里的 HTTPS_PROXY；有些語言執行緒會讀系統 Proxy，有些則完全不理。若只有瀏覽器通、桌面程式不通，請交叉閱讀 全域與瀏覽器分流辨析，評估是否改開 TUN 模式讓進程級流量強制進核心。

在 macOS 上若系統延伸功能未核准，TUN 可能看似開啟實際未接管；此時可對照 隱私權與延伸權限專文排查。Windows 則常與 WSL、Docker Desktop 或企業 VPN 搶路由表有關，必要時分段驗證「宿主機 IDE」與「容器內 CLI」各走哪條路。

DNS、fake-ip 與「規則看起來對卻時靈時不靈」

使用 enhanced-mode: fake-ip 時，規則比對與解析行為綁在一起。若某些內部測試域名該進 fake-ip-filter 卻漏掉，或作業系統層啟用了不透過核心的 DoH，會讓 Clash 面板裡的命中與您預期不一致。建議在穩定重現的時間窗內，暫時關閉 OS 的安全 DNS做對照，並從日誌確認最終策略是否為 AWS_MCP。

若您懷疑是 redir-host 與應用程式 SNI 行為不相容，可平行閱讀 Windows 上的 DNS 模式專文；重點仍是一次只改一個變因，避免同時改 DNS、規則與節點三件事情。

可複製的實測步驟（建議照序做）

  1. 在 IDE 內最小重現一次 MCP 動作，於 Clash Verge 連線列表或日誌中抄下完整主機名與命中規則，確認是否落進預期的 AWS_MCP。
  2. 若完全沒有對應連線記錄，先在宿主機以 curl -v https://sts.amazonaws.com 對照：有記錄代表至少系統層進了核心，沒有則回到系統 Proxy／TUN是否生效。
  3. 將 DOMAIN-SUFFIX,amazonaws.com 整段上移到所有會提早結束比對的寬泛條目之前，存檔後再觀察 STS／IAM 是否仍被別的 RULE-SET 截走。
  4. 把 AWS_MCP 暫改為手選單一節點，若穩定則調整 url-test 參數；若仍失敗，換節點供應商或連線協議做對照，而不是先在 YAML 堆 DOMAIN。
  5. 登入類問題併查 signin.aws.amazon.com 與 portal.aws.amazon.com 是否與 API 走同一策略群組，避免瀏覽器與子行程出口分岔造成裝置碼流程卡死。
  6. 最後再回頭用 工具鏈專文補齊 npm／github.com 等外掛啟動時可能觸發的次級請求。

常見問題

為什麼瀏覽器能開 AWS 主控台，IDE 裡的 AWS MCP 卻逾時？

瀏覽器與 IDE 子行程預設走的網路堆疊不同；再加上 STS、IAM 與區域端點對延遲抖動敏感，很容易表現成「只有外掛壞掉」。請用日誌驗證兩邊是否命中同一規則與同一出口，而不是只看表面上「有開 Clash」。

Clash Verge 要怎麼確認 MCP 請求真的進了核心？

在連線紀錄中搜尋實際 SNI；若沒有任何 amazonaws.com 相關條目，卻在政策里寫了 DOMAIN，幾乎可以判定是應用程式未走代理或 DNS 繞路，應回到 TUN 與環境變數章節處理。

安全提醒：請勿使用來路不明的一鍵規則包，以免出口不可審或留下過寬放行；訂閱連結與帳號憑證同等敏感，請勿公開分享截圖。

結語

AWS MCP Server把雲端操作塞進 IDE，網路層卻仍是「一堆高度相關、但出口適性不同的 HTTPS 主機」之組合；若不把 amazonaws.com 家族收斂到可觀測的獨立策略群組，並對齊 IDE 代理、DNS 與 TUN，很容易把可修的路由問題誤判成產品缺陷。相對地，只依賴論壇碎片規則、缺少連線日誌對照的作法，往往在帳號一換區域或企業一換 IdP 就整組失靈，排錯成本反而更高。

ClashSource始終以「同一核心行為、可驗證的規則順序」整理各類場景教學，讓 Clash Verge MCP 這類工作流可以與訂閱節點解耦思考：您專注在策略與觀測，出口仍由您自選的服務商提供。若您希望先把用戶端與圖形介面就緒，再疊加本文的 AWS API 分流骨架，不妨先從本站索引安裝流程，再依日誌微調主機名。歡迎前往 免費下載 ClashSource 取得整理好的用戶端資源，通常幾分鐘內就能把基底環境跑起來並開始對照連線紀錄。