AWS MCP 逾時一定是 Clash 規則問題嗎？

不一定。須先排除 IAM 政策、金鑰組態、區域服務未開通、或 MCP 行程未繼承代理與憑證。若同一台機器上瀏覽器可登入 AWS Console 而 Agent 僅在背景逾時，較像行程未進 TUN／mixed-port，或 sts／區域 API 與 console 走了不同出口。

能不能用一條 DOMAIN-SUFFIX,amazonaws.com 全包？

技術上可以，但會讓所有 Amazon 系後端流量強制走同一出口，可能與公司分流、S3 下載或第三方依賴 amazonaws.com 的服務打架。較穩健作法是依日誌補齊子網域與服務前綴（如 sts、execute-api、各區域服務主機名），再逐步收斂。

AWS MCP Clash 分流（2026）| Clash

1. 為什麼 GA 後仍常看到「AWS MCP 逾時」：與 npm MCP 的差別

多數人第一次碰到 MCP時，問題畫面是「拉不到套件、GitHub tarball 卡住、npx報 ETIMEDOUT」，那是工件下載鏈路；把 npm 與 GitHub 收斂到同一策略組，通常就能大幅降低假陽性。相對地，AWS MCP Server在執行時會更像「嵌入式雲端控制平面」：憑證簽發、角色切換、各服務區域別名、以及 boto3/SDK 對 region 的自動拆解，都會在未來你根本沒輸入主機名的情況下，於背景對多個amazonaws.com後綴送請求。若這些請求一部分經過系統代理、一部分直連，或規則被某條大範圍 GEOIP／國內直連蓋過，你看到的使用者側症狀就會收窄成控制台裡工具呼叫逾時、編輯器面板無回應、或只看到泛用的網路錯誤字串——與 IAM 是否真的允許無關。

這也是為什麼「把 MCP 視為 npm 問題」會失敗：AWS MCP的核心瓶頸常落在身分與端點解析，而不是套件索引。對 Clash 分流而言，解法思維要從固定幾個下載站網域轉向可更新的 AWS 網域覆蓋層：先有日誌證據，再把後綴寫在前面，並讓DNS模式不致讓規則永遠匹配不到你想要的目標。代理軟體無法替你完成 MFA 驗證、繞過組織 SCP、或變更未開通的服務額度；它處理的是出站路徑一致性與TLS 對端可達性。

GA 代表的是產品可取得性成熟，並不保證每台開發機的分割隧道或企業安全軟體不會攔 AWS 全域憑證鏈。本篇所有主機名列舉皆以教學起手式看待，正式環境務必以自己機器的連線紀錄為準增刪規則。

2. 典型現象：STS、區域 API 與 API Gateway 的假性逾時

你可以在腦中對照這幾類可複現症狀：瀏覽器登入 Console 尚可，但 Agent一觸發讀取角色或資源清單就長時間沒結果；或使用 AssumeRole 類操作的延遲異常高，換節點也無效；又或者是 API Gateway這類execute-api子網域的流量被送去與 sts.amazonaws.com不同的出口，使得 HTTP/2 重用或憑證透明度檢核行為異常。boto3在背景會依 region 自動拼出對應的伺服器名稱，若你的規則只放行 *.amazonaws.com 的某一種細分或未含實際子網域格式，會出現「偶發成功、常在重試後失敗」的TLS 卡住感。

這類問題與 Notion／CloudFront 類 AWS 承載頁的搜尋意圖不同：那裡多數在修媒體下載或 Web 應用資產網域；本篇聚焦程式型客戶端與 MCP 對控制平面的呼叫。先排除 IAM 設定錯誤仍很重要：確認角色信任關係、工作階段權杖有效時間、區域是否真的啟用了目標服務。若這些都已核對無誤而逾時仍存在，才把重心移回mihomo 命中順序與出站一致性。

3. 連線地圖：控制台、IAM、STS 與服務別名網域

與AWS API相關的閘道請求在不同服務會落在不同伺服器別名：STS常見為 sts.amazonaws.com 及各區域的 sts.<region>.amazonaws.com；IAM許多呼叫可走全域 iam.amazonaws.com；控制台導向與聯合身分登入則會牽涉 signin.aws.amazon.com、*.awsapps.com 等公司設定相關主機名。若 MCP 對外暴露了需要經過 REST API／HTTP API的整合，請注意 *.execute-api.*.amazonaws.com 這類API Gateway 執行端點常被遺漏，尤其在 Agent 並非透過瀏覽器而是透過程式庫發送請求時。

身分與權杖：優先對齊 STS 全域與區域後綴，避免 AssumeRole/GetCallerIdentity 等呼叫走散。
服務 API：依你最常啟用的產品補區域別名（例如運算／儲存／無伺服器運算類服務對應的 <service>.<region>.amazonaws.com 模式）；實際清單以日誌為準動態追加。
Console 輔助：需要在瀏覽器與 Agent 同時穩定時，確保控制台相關主機名不要與 API 出站刻意拆成互相打架的節點家族，除非你非常清楚為何要分岔。
CloudFront／S3 附件：若工具鏈還會下載公開文件桶或說明頁 CDN，視情況併入與本站 AWS／CDN文相同的觀念，但依然建議分層規則以利除錯。

對 amazonaws.com 做過寬DOMAIN-SUFFIX會影響面極大（含你可能沒想到的第三方供應商子網域）。實務上較可取的是：先細、後寬——在日誌中重複出現者升級為規則，避免一開始就以「一刀切」換來更難查的側面效應。

4. 策略組設計：一條穩定的「AWS Agent 出口」

對 Coding Agent場景建議將「會被 MCP 用到的 AWS API、STS、以及必要的控制台登入主機名」導向同一策略組或同一細分策略組族群，並對該族群啟用你信任的低切換／url-test 穩定性設定。把工作流想像成 boto3：一次對話會在短時間打一串不同服務別名，若規則讓前半段連線經過低延遲節點、後半段跌入直連或另一個國家出口的轉發，最常見的外在表現即是逾時閾值前先被客戶端放棄。Clash能幫助你顯式看見每一段連線對應的規則名稱——這對排除「到底是不是代理問題」非常關鍵。

進階團隊可以再把「資料面下載」（例如巨型日誌匯出或大型套件）獨立到另一個策略組，但那應在日誌裡先證明它與 MCP 控制能力呼叫確實分離，否則過早分拆只會重蹈覆轍。IAM與安全群組並不由 Clash 代管：代理只處理傳輸路徑，權限邊界仍以 AWS 帳號設計為準。

5. mihomo 規則範例片段與順序注意

下列片段示意如何將 AWS 類後綴置於 GEOIP／廣義直連之前。請將 AWS-AGENT（或你想要的名稱）接到實際 proxy-groups item，並視需求增刪區域：註解一律使用英文以利版本控制與國際協作。

① 精簡 DOMAIN-SUFFIX 起手式（請以日誌補全）

# proxy-groups excerpt (conceptual)
proxy-groups:
  - name: AWS-AGENT
    type: select
    proxies:
      - YOUR-STABLE-NODE
      - DIRECT

# rules — place BEFORE broad GEOIP / domestic DIRECT shortcuts
rules:
  - DOMAIN,signin.aws.amazon.com,AWS-AGENT
  - DOMAIN-SUFFIX,amazonaws.com,AWS-AGENT
  - DOMAIN-SUFFIX,awsapps.com,AWS-AGENT
  # Narrow overrides can be inserted above if you split traffic intentionally

上方的 amazonaws.com整段範例屬於為了可讀性而做的大範圍覆蓋：正式環境請改寫成你實際需要的子集合，否則容易與非預期的 AWS Marketplace 類流量交錯。更細的做法是拆出 sts.amazonaws.com、區域 STS、預計會用的服務前綴，以及 API Gateway用到的 execute-api 模式。規則順序自上而下匹配：任何「國內 IP 自動直連」若放在前面，會把你想代理的區域對撞成錯誤的出口。

若在 Fake-IP 環境發現規則看似命中卻連線仍異常，請對照站上 Fake-IP 與 redir-host的深度說明，理解解析還原與實際連線目標是否一致。

6. DNS、Fake-IP 與 Agent／終端機行程邊界

Coding Agent常跑在獨立行程或 IDE 的子行程裡，對系統 PAC、瀏覽器擴充套件，或只靠「手動開關全域 VPN」都不敏感。對 Windows／macOS 而言，最常見地雷是：Agent 沒走 TUN、mihomo 的 mixed-port 沒對齊 HTTP_PROXY 等環境變數，或 NO_PROXY 把某些 AWS 子網域錯誤排除——表面看像你懷疑 MCP「壞掉」，但其實是行程級別的出站沒有被 Clash 接管。

在DNS側，請確保 dns 區塊與規則所用的命名一致：不要把 AWS 強制劫持到國內供應商解析，除非你非常清楚對方快取政策不會扭曲區域對應。Fake-IP能加速規則匹配，但當 MCP 仍以「真 IP」對外建立第二條並行連線時，若還原邏輯不同步會出現半套連線。建議在日誌中同時對照 DNS 紀錄與連線目標，而不是只相信自己的記憶裡「我上週規則好像寫對了」。

對企業終端監控／HTTPS 解密設備要特別小心：AWS MCP與 boto3 路徑若遇到公開信任鏈以外的 MITM，常以握手失敗結束。Clash 無法在應用層繞過公司政策；若環境強制解密，請與 IT 協調放行或改用受控的出口。

7. 實測驗證：日誌、延遲與最小重現步驟

建議以最小重現驗證：先對單一目標區域跑一次唯讀操作（例如列舉你已授權的資源類型），觀察 mihomo 日誌中每一跳的 host 與規則名稱是否都落在你的 AWS-AGENT 策略組。若發現 STS 呼叫走了 DIRECT而資料面 API 經過代理，就優先視為規則順序或行程代理缺口，而非立即懷疑 IAM。你也可以用 curl 對 STS 公開端點做 HEAD 級探測，但不要在公開紀錄中貼任何個人存取金鑰或工作階段權杖。

對於會頻繁重試的 MCP 客戶端，延遲分佈可能比「平均值」更有意義：注意p95 是否在逾時閾值附近抖動，並檢視節點是否啟用了不合適的 multiplex 或對 AWS 來說不友善的 QUIC 強制。若你已把 AWS 出站收斂而延遲仍高，那才是合理的換節點或接洽供應商時機。把觀察寫成一頁備忘能讓隊友複用，而不是每次 GA 級新聞都把同一批問題在社交平台上重複發問。

8. 常見問題

為什麼我已經在瀏覽器登入 IAM 仍可用的情況下，Agent 還會失敗？瀏覽器走的是另一套程式與 Cookie／SSO 流程；MCP／boto3 往往使用環境憑證或角色鏈。請先確認行程代理與 DNS，再回看 IAM。MCP GA 並不會自動修復本機出站分裂。

需要為每個 Region 手寫規則嗎？起手可用泛化後綴或 rule-provider 自動維護表，但一定要留有核對命中率的流程；對高合規環境，寧可細但可審計，也不要黑箱巨型規則集。

與 boto3 Proxy 環境變數如何搭配？若你已設定 HTTP_PROXY，請確認其指向與規則一致的 mixed-port／旁路監聽，並避免對 AWS 的呼叫不小心繞過代理。Clash 規則與環境變數若各走各的，是最常見的隱性逾時來源。

收尾

AWS MCP Server GA把雲端控制平面能力放到了 Coding Agent 旁邊，真正的工程挑戰卻往往不是「協定新不新」，而是你願不願意在日誌裡承認出站路徑正在分裂。STS、區域別名與API Gateway 閘道同時發力時，單鍵 GLOBAL VPN 類產品很難讓你看到哪個子網域在抖動——它們多數把一切都包進無法細分的隧道，對企業區網或 IAM 除錯也不友善。相對而言，Clash 生態／mihomo讓你先寫下可讀的 DOMAIN 覆蓋層與對齊的 DNS／Fake-IP，再決定要代理還直連。與只靠系統級開關的客戶端相比，你能把 MCP 對 AWS API 的呼叫收斂到穩定的策略組並用日誌反覆驗證，這在 GA 後大量團隊同時試用 MCP 的情境下，能少掉許多假性「伺服器掛了」的結論。