為什麼 Agent Toolkit 與 Bedrock 呼叫容易「卡住」？

進入 2026 年，AWS Agent Toolkit 這類把雲端 Agent、工作流程編排與 IDE 深度整合的工具，正在快速進入日常開發流程：你在編輯器裡下指令，背後往往會串起 IAM 身分、Region 端點、模型供應商，以及一連串 AWS API。若網路路徑稍有不穩，最常見的體感不是「立即報錯」，而是請求懸置、倒數計時結束後才跳出逾時，尤其是對 Amazon Bedrock 的 InvokeModel 或串流推論這類可能被拉長到數十秒甚至更久的連線。

許多人的第一反應是把節點換一輪，或乾脆把 Clash 改成全域模式；全域確實能「先順起來」，但也把內網、套件索引、甚至公司 VPN 該直連的流量一起送進代理，後續問題更難收拾。本文目標很單純：用可驗證的 Clash 分流規則，讓 AWS 相關主機名穩定命中你為開發環境保留的一條出口，並在不需要時維持精準直連。若你也在用其他雲端模型 API，可一併對照本站 DeepSeek API 分流 或 Claude Code API 分流 的思路：核心都是把「長連線＋金鑰驗證」從一般網頁流量拆開。

AWS Agent 流量長什麼樣子？先分管理平面與資料平面

要把規則寫得準，先粗略地把流量分類：管理與身分驗證（例如 STS、IAM Identity Center、主控台文件頁）、模型與 Agent 執行（Bedrock Runtime、Agents API）、以及附帶的物件與日誌（S3、CloudWatch、偶發的 CDN 或下載來源）。不同類型對延遲與頻寬的敏感度不同；全部塞進同一個「泛用 AI 策略組」時，常出現兩種現象：一是身分還沒換到有效憑證就送去慢節點，二是長推理已經開始又遇到節點自動輪換，直接在客戶端看見 API 逾時。

實務上你不需要背下完整網域清單，但要知道Bedrock 端點高度 Region 化：bedrock-runtime.region.amazonaws.com 這類主機名會隨你設定的 Region 變動。Agent Toolkit 若在你的專案設定裡指定了 us-east-1，連出去的就應是對應 Region 的後綴；若規則只寫了另一個 Region，或用過於寬鬆的 IP 規則擋在前面，便可能規則看似正確、實際完全沒命中。因此後續步驟會一再強調：以連線日誌裡實際出現的主機名為準。

IDE 外掛、CLI 與「系統代理」常不同步

與網頁版主控台相比，VS Code／JetBrains 外掛與本機執行的 SDK往往不會自動採用你在 macOS 或 Windows 上勾選的系統代理。多數情況下，它們要嘛讀 HTTPS_PROXY 環境變數，要嘛在 TUN 模式下由系統層直接把封包交給 Clash。若你只開了「系統代理」而沒有設定環境變數、也沒啟用 TUN，外掛仍可能嘗試直連，於是出現瀏覽器一切正常、編輯器裡 AWS 卻完全連不上的經典落差。

你可以先選一條最不折騰的路：在常用 shell 設定檔加入混合埠代理變數，或依平台啟用 TUN。若走 TUN，請留意與其他 VPN 的路由競爭，以及雙重代理陷阱；Windows 使用者可對照本站 Windows TUN 排查。若你常在 WSL2 裡跑 AWS CLI 與測試腳本，請同步參考 WSL2 與 Windows Clash 混合埠，避免子系統與宿主機各走各的代理。

為什麼要為 AWS 開一個獨立策略組？

若把 Bedrock 與一般「社群網站、串流」混在同一個 url-test 或高度自動切換的策略組裡，常會發生兩個問題：第一，長連線最忌諱中途換節點，模型回應進行到一半卻被迫重建 TLS，客戶端只報一個冷冰冰的逾時。第二，AWS 的連線對證書鏈、MTU、與部分中繼節點的 HTTP/2 行為較敏感，未必適合用你平常看影片的那個「最快延遲」出口。

建議至少建立一個名稱明確的策略組（本文示意叫 AWS_DEV），類型先用 select，手動選一個你長期觀察穩定的節點；行為確認後，再評估要不要改成 fallback。若你同時用 Cursor 這類 IDE 內嵌 AI，也可對照 Cursor IDE 分流，讓「雲端 Agent」與「IDE 內建連線」互不搶規則，除錯時比較好對症下藥。

主機名從哪裡來？請相信連線日誌

和任何雲端供應商一樣，AWS 的服務 front-end 會演進：新 Region、新模型供應商整合、或文件頁改用不同 CDN，都會讓「社群流傳的一份域名表」悄悄過期。硬背清單不如養成觸發問題當下看日誌的習慣。具體做法：暫時讓 Agent Toolkit 執行一次會呼叫 Bedrock 的操作，同時開啟 Clash 連線面板，把這幾秒內出現的後綴寫下來；再將對應的 DOMAIN-SUFFIX 規則放在 MATCH 之前。

日誌裡若同時看到 amazonaws.com 與 aws.amazon.com，不要隨便二選一；管理文件、部分內嵌資源與說明頁可能走後者，而實際推理仍在前者。若你只覆蓋其中一類，就會出現登入或說明頁能開、Invoke 卻失敗的落差。對於偶發的下載或靜態資源，可視情況另開 AWS_CDN 策略組，或暫時與 AWS_DEV 共用，重點是你在日誌中能看見命中哪一條規則。

規則順序：讓 AWS 專用段落落在對的位置

Clash 自上而下的第一個命中即成立。若一條寬鬆的 MATCH,PROXY 或區域規則排在前面，Bedrock 相關請求就永遠進不了 AWS_DEV，你再怎麼調整節點都徒勞。建議的骨架是：先內網與保留位址直連，再必須直連的業務系統，接著是像 AWS 這種「要精準出口」的開發者服務，然後才是地區分流，最後 MATCH 兜底。

若你的設定檔已經有 Ollama、容器映像或大型模型下載的分流，可參考 Ollama 與 Hugging Face 分流 的排版經驗，把「大檔下載組」與「API 長連線組」分開，避免搶節點。記住：越具體、越跟本次逾時相關的網域越要靠前；越寬鬆、越像兜底的越往後。

DNS、Fake-IP 與 SNI：為何「能 ping」不代表能推理

許多 Bedrock 客戶端走 HTTPS 並依賴正確的 SNI。若你啟用 Fake-IP，DNS 在客戶端看起來會像「怪 IP」，實際連線仍由 Clash 映射回真實目標。一般情況下透明無感，但若某些 SDK 在應用層自己做了解析快取，或混用 IP 規則與網域規則，就可能出現命中順序不符合預期的邊角案例。實務上可先以純 DOMAIN-SUFFIX 收斂，把複雜度降到最低；需要更細行為時再查本站 文件中的 Fake-IP 說明。

設定檔示意：獨立策略組與占位規則

下列 YAML 僅為結構示意：策略組名稱、節點與網域請以你的訂閱與日誌為準，合併前請先備份設定檔。註解一律使用英文以利工具相容。

proxy-groups:
  # AWS developer stack — start with 'select' for long Bedrock calls
  - name: AWS_DEV
    type: select
    proxies:
      - YOUR_STABLE_NODE
      - DIRECT

  # Optional: static/docs downloads if logs show different CDN hosts
  - name: AWS_CDN
    type: select
    proxies:
      - YOUR_STABLE_NODE
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - GEOIP,PRIVATE,DIRECT

  # Replace suffixes with log-observed hostnames for your regions
  - DOMAIN-SUFFIX,amazonaws.com,AWS_DEV
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_DEV
  - DOMAIN-SUFFIX,amazon.com,AWS_CDN

  - GEOIP,CN,DIRECT
  - MATCH,YOUR_DEFAULT_GROUP

如果你確定所有 Bedrock 相關端點都落在 amazonaws.com 之下，一條後綴規則往往就足夠；但若日誌出現外部模型供應商或第三方整合網域，就要另外補規則，不要硬塞進「看起來像 AWS」的桶子裡，否則下次更新工具鏈時又會失靈。

環境變數：讓 CLI 與腳本安靜地走混合埠

在尚未啟用 TUN 的情況下，為 shell 加上標準代理變數通常是最快的入口。請把埠號換成你的 mixed-port：

# Add to ~/.zshrc or ~/.bashrc
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1,192.168.0.0/16,10.0.0.0/8"

修改後執行 source ~/.zshrc，再用 curl -v https://sts.region.amazonaws.com 這類輕量端點測試是否顯示 Uses proxy env variable HTTPS_PROXY。隨後回到 Clash 日誌，確認命中 AWS_DEV 而不是默默落進 MATCH。NO_PROXY 請保留完整內網段，避免把本機後端或 Docker API 也送去代理。

驗證流程：一次處理一層，不要一次改十個地方

第一步，確認 IDE／CLI 流量真的進了 Clash：沒有日誌，就代表還在直連或變數沒吃到。第二步，確認 Bedrock 相關連線在策略欄位顯示 AWS_DEV（或你自訂的名稱），而不是被更寬鬆規則提前接走。第三步，用短請求測試 STS 或輕量 API，再換成實際 Agent 場景觀察是否仍在逾時。第四步，若只有長推理失敗，優先懷疑節點對長連線或 HTTP/2 的相容性，先把策略組固定在手動節點，關掉自動輪詢。第五步，核對 Region 設定與日誌主機名是否一致，避免「客戶端以為在美東、規則卻只覆蓋美西」這種配置落差。

現象對照：從症狀倒推下一步

若還接到 OpenAI 相容端點，要拆開嗎？

部分工具會用 OpenAI 相容的 URL 形狀，但實際後端仍落回 Bedrock 託管模型；也有團隊混用官方 OpenAI 與 Bedrock。若把兩者硬擠在同一策略組，你很難判斷逾時究竟是哪一條供應鏈出了問題。建議在日誌裡先區分主機名：若出現 openai.com 或特定第三方網域，就為其建獨立組；Bedrock 相關仍以 amazonaws.com 為核心去收斂。這樣當你在 VS Code 同時跑多個外掛時，也比較不會發生規則搶過頭的副作用。

常見問題

瀏覽器一切正常，為什麼還是逾時？

因為瀏覽器走的是系統代理，IDE 外掛與本機 SDK 常常沒有。請先完成環境變數或 TUN 的統一，再談規則優化。

只靠 DOMAIN-SUFFIX,amazonaws.com 夠不夠？

對大多數 Bedrock Runtime 場景夠用，但若日誌出現其他頂級域或合作夥伴網域，就要補規則；請以觀察為主，不要假設供應商永遠不變。

可以先開全域再縮小嗎？

當成短期診斷手段可以，但不建議長期關在全域；把內網與套件註冊表一起代理，只會掩蓋真正的規則衝突。診斷完請回到分區規則。

結語：為雲端 Agent 準備一條「長連線友善」的出口

相比一般社群或影音站點，AWS Agent Toolkit 與 Bedrock API更考驗連線的連續穩定度與身分驗證的可重試性。把這類流量塞進泛用「AI 分流組」或隨延遲自動跳的節點池，往往就是把逾時問題藏進黑盒子。透過獨立策略組、以日誌驅動的網域補全，以及正確的代理入口（環境變數或 TUN），你可以把狀況收斂成可逐步驗證的工程題。

相較部分只提供固定規則清單、卻不要求你理解流量路徑的工具，Clash 讓規則與節點分層管理，並可用連線紀錄逐條對照命中與延遲；當雲端供應商調整端點時，你也只需更新少數幾行，而不是整包重灌。若你希望以一個客戶端統一處理開發、遠端與模型 API 的出口，可以先到本站下載頁取得適用於你平台的版本，再依本文流程把 AWS 相關網域收斂到專屬策略組。

相比只能全機一刀切開全域、或把規則寫死在單一訂閱裡的傳統做法，Clash 讓「身分驗證、模型推理、附件下載」這些不同時間尺度的請求可以各自對應合適節點與順序，長期維護成本也更清楚。若你正在準備長期使用 Bedrock 與 Agent 工具鏈，不妨免費下載 Clash，用可驗證的分流把開發環境的 API 逾時問題降到最低。