AWS Agent Toolkit 上線後 IDE 裡 AWS 技能總逾時？Clash 分流 IAM／STS／工具網域實測（2026）

為何 2026 年「編輯器裡 AWS 技能」會比瀏覽器更吃 Clash 分流？

AWS Agent Toolkit與其周邊的 AI 編碼代理工作流，把雲端查詢、帳號脈絡與工具呼叫收斂進 VS Code／Cursor 這類宿主；對已使用 Clash 或 Mihomo／Clash Verge Rev做IDE 代理整理的讀者，症狀常不是全程斷線，而是只有技能面板、Q Chat 或某個自動重試迴圈在轉圈圈：背景裡對 IAM、STS、OIDC、以及形如 q.us-east-1.amazonaws.com／codewhisperer.us-east-1.amazonaws.com的流量延遲飄高，最後被 IDE 誤判成逾時。表面上看像外掛壞掉，骨子裡卻是多段彼此相依的 HTTPS 主機分散在不同策略桶——任何一段被過寬的 GEOIP 或兜底 RULE-SET提前截走，就會出現工作台登入看得到、編輯器技能拿不到的分裂現象。

本文與站內同名主題但不同切面的兩篇文章如何分工：〈AWS MCP Server × IDE 分流〉收斂在「透過 MCP 呼叫服務 API 時」常見的 amazonaws.com區域鏈路；本篇則補齊Agent Toolkit／Amazon Q 外掛在官方文件中單獨列出的idetoolkits.amazonwebservices.com、idetoolkits-hostedfiles.amazonaws.com、aws-toolkit-language-servers.amazonaws.com等Toolkit 與語言伺服器供應鏈，以及身分流程裡常被遺漏的 .awsapps.com、oidc.Region.amazonaws.com、*.sso.*.amazonaws.com這類身分與 SSO 端點。（端點出處請以 AWS 線上文件的「Toolkit allow list」章節為準，本文僅將其對應至規則可寫性與國內直連避雷。）套件與公開範本拉取仍可併讀泛用 MCP／開發鏈路分流；編輯器是否吃到系統 Proxy 則可對照Cursor／VS Code 擴充與分流專文。

合規提醒：Clash／Mihomo 用戶端只負責本機轉送與規則，不提供遠端節點。請在您所屬環境法令與公司政策許可範圍內使用雲端與IDE 代理設定；表中網域名稱仍以官方出版物為準，若服務分拆或新增區域，請以連線日誌實際 SNI補規則而非硬抄社群清單。

先分桶症狀：逾時登入／技能失敗／還是國內站被波及？

在遇到Toolkit相關錯誤時，建議把現象分到三種桶，避免一上來就調訂閱或重灌編輯器。第一類是純 STS／IAM／區域 API 逾時：紀錄裡反覆對 sts.amazonaws.com或某區*.amazonaws.com出現長連線中斷或 SDK 報錯裡的 ETIMEDOUT語意。第二類是身分與 OIDC SSO 不完整：瀏覽器已到 *.awsapps.com，但編輯器子行程未能完成同一組 redirect／token 交換——常見成因是瀏覽器走 TUN、語言伺服器直連，或對 oidc.Region.amazonaws.com的出口與主控台不同。第三類是Toolkit 宿主檔／端點表拉不下：啟動階段若 idetoolkits.amazonwebservices.com子路徑或 hosted JSON 卡住，會表現為外掛初始化失敗而非單純模型回答變慢。

若您發現國內可直連網站變得不穩定，請先懷疑是否新增了過寬、位置又太晚的MATCH,PROXY或被錯配的 DNS，並對照本站國內外分流骨架：本篇強調的是在不誤傷國內直連的前提下，把AWS Agent Toolkit所需海外網域上移到合理出口，而非把國內流量硬塞進代理。

依官方列表可下筆的分流錨點（當規則起點）

下列分組對應《AWS Toolkit for VS Code／Amazon Q firewall allow list》中常見項目，並轉換成 Mihomo／Clash 可直接使用的DOMAIN／DOMAIN-SUFFIX 思路。實務上區域代號（例如 us-east-1）會隨組態而變，請以您日誌中出現的全名為最高優先：

  • Toolkit bootstrap 與設定：idetoolkits.amazonwebservices.com及其子路徑（端點表 JSON）、idetoolkits-hostedfiles.amazonaws.com底下通知與外掛設定檔。重點：.amazonwebservices.com與.amazonaws.com屬不同後綴 bucket，僅擋其中一張往往仍會在半初始化狀態打轉。
  • Amazon Q／語言伺服器：aws-toolkit-language-servers.amazonaws.com、區域態的aws-language-servers.us-east-1.amazonaws.com（其他區請按日誌替換）；以及 Q／CodeWhisperer 對應的codewhisperer.us-east-1.amazonaws.com、q.us-east-1.amazonaws.com、specs.q.us-east-1.amazonaws.com、desktop-release.codewhisperer.us-east-1.amazonaws.com等。
  • Telemetry／匿名身分：client-telemetry.us-east-1.amazonaws.com、cognito-identity.us-east-1.amazonaws.com。Telemetry 並非總在主路徑上，但被企業過濾器擋時常造成「進階面板灰掉」的假性故障。
  • 身分、SSO、Builder／企業 IAM Identity Center：[alias].awsapps.com、oidc.Region.amazonaws.com、portal.sso.Region.amazonaws.com、sso-portal.Region.amazonaws.com pattern、維運主控台的*.console.aws.a2z.com與 *.aws.dev references、以及管理主控台靜態資源用的*.awsstatic.com。這些項目若只開瀏覽器白名單而 IDE 側被另一出口命中，最典型的就是 STS 已取得但Skills 呼叫鏈仍需二次互動時失敗。
  • 區域 AWS API（與 MCP 重疊處）：形如service.region.amazonaws.com的大家族；可把DOMAIN-SUFFIX,amazonaws.com作為兜底，再配合企業對國內與國際分割（如amazonaws.com.cn）的特例提前寫。IAM／STS及區域端點常與 Toolkit 技能共用同一身分後端，對延遲敏感，宜放在可觀測的AWS_TOOLKIT群組而非混用泛泛的AI_PROXY。
  • 第三方參照（套件／schema）：官方 allow list 會引用 raw.githubusercontent.com、api.github.com甚至 devfile schema；這些並非 AWS服務本身故障所致，卻可能造成 IDE 側阻塞，必要時請回到MCP／開發鏈路分流專文視情況加前置網域名稱。

實務建議：不要一次把三十個DOMAIN複製進訂閱；先用連線紀錄圈出失敗視窗的前五個 hostname，置前命中並觀察，再將穩定型後綴沉澱為 Provider 或直接寫入主配置，以免過度打寬規則反而遮蔽真正誤匹配的RULE-SET。

規則順序：為什麼 IAM／STS、「技能」會被 GEOIP CN 搶走？

Core 的比對順序為由上而下、命中即停。若合成的最終規則陣列中，先有寬鬆GEOIP,CN,DIRECT或自動下發的國內直連合集，而其中某條又意外地符合了您以為在海外範疇的一部分解析結果／IP 段，後面即使再寫amazonaws.com也可能永遠讀不到。另一方面，過早的MATCH,PROXY也可能把本應由企業對等直連或因合規必須落地的流量硬拖向海外節點，造成國內服務體感變慢或憑證／延遲異常。

因此對AWS Agent Toolkit請採三明治結構：區域與公司政策允許的國內明確DIRECT與區網規則放最頂 → 將 Toolkit／身分／區域amazonaws.com置入獨立的AWS_TOOLKIT群組 → 最後再接較大的分流集合與兜底。記得在每回合除錯時展開實際 merge 結果，而不是只看您備份片段，否則常見「規則寫進檔案卻總不中」的假 bug。

策略群組：請把 Toolkit 拉出通用 PROXY

技能與對話往往需要穩定的 TCP 對與區域對齊：若將其與短影片、CDN 等高頻換節點流量共用url-test，可能在長對話過程中被健康檢查誤切入高延遲出口。建議像本站 AWS MCP 文章一樣，拆分AWS_TOOLKIT：type:select下掛一組延遲測試子群組、再保留DIRECT對照以利 A／B。url-test／tolerance 專文可協助在您確認規則已命中後調整自動切換，而不是靠盲加網域名稱。

對跨區帳號，若 STS 主要走全域sts.amazonaws.com端點，區域調用多在region-specific後綴下的服務 hostname，請避免同時間在策略裡對同一技能頻繁切換出口，否則容易觸發 SDK credential cache 重置，看起來像權杖重新整理失敗。

YAML 骨架（請將節點名與區域占位替換）

下面是示範如何在常見國內直連兜底之上、但不要把 Toolkit 細則塞到國內大類之後忘記回頭調整。其中# AWS Toolkit/Q/identity anchors區塊展示置前順序：區網優先於雲資源細則，雲資源細則優先於寬 GEOIP。切勿未審核即套入生產帳號。

YAMLproxy-groups:
  - name: "AWS_TOOLKIT"
    type: select
    proxies:
      - "TK_AUTO"
      - "Handpicked-LowLatency"
      - DIRECT
  - name: "TK_AUTO"
    type: url-test
    proxies: []
    url: https://sts.amazonaws.com
    interval: 300
    tolerance: 35

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  # AWS Toolkit/Q/identity anchors (place ABOVE broad GEOIP buckets)
  - DOMAIN-SUFFIX,idetoolkits.amazonwebservices.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,idetoolkits-hostedfiles.amazonaws.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,aws-toolkit-language-servers.amazonaws.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,q.us-east-1.amazonaws.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,codewhisperer.us-east-1.amazonaws.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,oidc.us-east-1.amazonaws.com,AWS_TOOLKIT
  - DOMAIN-KEYWORD,sso-portal,AWS_TOOLKIT
  # Global AWS API mantle (narrow with corp policy if needed)
  - DOMAIN-SUFFIX,amazonaws.com,AWS_TOOLKIT
  - DOMAIN-SUFFIX,amazonaws.com.cn,DIRECT
  - DOMAIN-SUFFIX,awsapps.com,AWS_TOOLKIT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

其中q.us-east-1.amazonaws.com請按您環境換成連線日誌實際出現的區域對應全名；若身分中心在非 IAD region，對應的oidc／portal.sso也需一併改寫。proxies:[]請替換成訂閱裡真實的節點名；若發生「引用不存在的群組」，多半是 GUI 自動合成順序與您手寫模板衝突，請回到終端機合成的完整 YAML。

IDE 子行程、DNS／fake-ip 與 Telemetry 邊際案例

就算系統匣Tray顯示 Clash 已開啟，語言伺服器仍可能：(1) 直接略過應用層 PAC；(2) 另行啟用 OS DoH；(3)在 Windows 上與 WSL 分流。若對照紀錄完全沒有amazonaws.com或idetoolkitsSNI，但瀏覽器側抓端點表成功，十有八九是TUN／環境變數未對齊子行程。可分別閱讀TUN 指南、全域與瀏覽器差異，以及Windows DNS fake-ip專題；macOS permission 問題則對照系統延伸權限。

若企業對telemetry類網址做白名單外全擋，Clash 再怎麼分也過不了閘道；此時需要和資安對齊 allow list（仍建議區分 Telemetry 與核心 API）。

實測步驟（建議照序）

  1. 在編輯器用最小操作重現問題（開啟 Q 面板／觸發一次技能）；於 Clash Verge 連線紀錄或日誌中抄下前五個hostname以及規則名稱／策略群組。
  2. 若紀錄中完全沒有 AWS 類 SNI，先在同一宿主用curl -v https://sts.amazonaws.com確認是否進核心；再走 TUN／系統 Proxy 對照。
  3. 將官方表中與前述 hostname 對應的DOMAIN-SUFFIX／DOMAIN-KEYWORD移動到GEOIP,CN,DIRECT與兜底MATCH之前（必要時區分您企業對amazonaws.com.cn的直連特例）。
  4. 把AWS_TOOLKIT暫改成手選單一節點，若馬上穩定，聚焦調整TK_AUTO的interval與tolerance，而不是繼續擴張網域名稱。
  5. 若症狀集中在登入，核對*.awsapps.com、oidc.*、signin.aws是否與 API 請求共用同一出口。
  6. 若仍有 schema／GitHub 拉取問題，再回到開發鏈路 MCP 規則專文補齊次級請求。

常見問題

和 AWS MCP Server 規則可以共用嗎？

可以共用amazonaws.com級別兜底，但若只抄 MCP 專文而不加 Toolkit 宿主檔／語言伺服器／Q／OIDC SSO分組，仍會漏掉本篇列出的amazonwebservices.com與身分網域。建議並讀兩篇，並對照連線紀錄去重合併規則表。

國內直連會否被誤判？

只要把國內直連細則維持在合理的頂序，並避免把國內大類寫得過寬去覆蓋尚未解析的流量，就能把 Toolkit 細則放進出海桶而不製造國內反噬。對任何「國內站突然變慢」第一步仍是檢查兜底 MATCH而非怪節點。

安全提醒：請勿將含 Builder ID／企業入口截圖外傳；下載來源不明的「一鍵白名單」可能混入不可審的出口或過寬的MATCH規則，反而擴大攻擊面。

結語

相較市面上只泛泛談論「開代理就好了」的討論串，許多解法既無法對照官方 Toolkit allow list，也常把GEOIP與過寬兜底塞在錯誤深度，結果是技能逾時修了、國內直連反倒被拖慢，或 STS／OIDC／Q 三台主機各占不同桶，排錯像猜謎。ClashSource延續同一份核心行為敘述，把AWS Agent Toolkit × Clash 分流 × IAM／STS × IDE 代理對應到可複製的流程：先有日誌、再上移規則、最後調群組換節奏，並與站內 MCP 專文在網域層互補。

如果您希望先在圖像化用戶端把訂閱與基底策略跑順，再回到本文對 Toolkit 細則做第二輪收口，可先從訂閱匯入教學著手。ClashSource整理多平台安裝與排錯資產，讓策略與觀測可與具體提供商解耦聚焦。若想一次取得整理好的桌面端套件，亦可前往 免費下載 ClashSource ，通常數分鐘內就能把底座拉起並開始對照相關連線紀錄調整本篇骨架。