當你在本機安裝或試用 AWS Agent Toolkit，想把 AWS 管理主控台、說明文件、以及編輯器透過 Model Context Protocol（MCP）連上的雲端工具鏈一併走穩，最常撞牆的不是「會不會用」，而是哪些網域沒被規則蓋到、哪個行程根本沒吃到代理，以及 MCP 逾時背後其實是單一子資源載入失敗。 這篇文章以 Clash Verge Rev 為客戶端，示範如何把「主控台瀏覽」「雲端 API」「MCP 長連線」拆成可維護的分流與除錯路徑；若你尚未完成基礎安裝，可先閱讀 Clash Verge Rev Windows 完整設定教學 建立訂閱與基礎模式，再回到本文處理開發情境。
一、先釐清「Agent Toolkit 流量地圖」
要把 Clash 規則寫得可預測，第一步是接受一件事：雲端開發不是單一網址。 你在瀏覽器開啟的 AWS 管理主控台會再拉一組靜態資源、區域服務與身分驗證相關網域；終端機裡的 AWS CLI 或程式碼中的 AWS SDK 可能改走另一批 API 主機名；而編輯器外掛若透過 MCP 對外部服務做工具呼叫，又可能出現本機回呼、長時間佇列與串流回應等與一般 HTTPS 下載不同的行為。 若你把所有流量都丟進同一個「慢節點」或「全部 DIRECT」，就很容易出現「主控台大框載入了，但某個內嵌面板一直轉圈」或「MCP 顯示逾時但其實是 DNS 先失敗」的假象。
建議你用一張紙或筆記本列出三類目標：人類瀏覽的介面（主控台、說明中心）、程式化的雲 API（依服務與區域變動的主機名）、以及 MCP 對話鏈（外掛設定的 MCP Host、埠與是否走 TLS）。 每列一項就問自己兩句話：這條連線在作業系統裡是誰發起的？它會不會自動繼承瀏覽器的系統代理？ 這兩句話答不出來，後面再怎麼調逾時秒數都只是在賭運氣。
二、為什麼用 Clash Verge Rev 做「可觀測的分流」
Clash 系譜的核心價值在於規則引擎與政策組：你可以先決定哪些網域必須命中哪個出站，再把「實驗性節點」「常用落地」與「僅供瀏覽」拆開。 Clash Verge Rev 則把圖形介面、設定同步與本機檔案路徑收斂到對桌面使用者友善的型態，對需要長期維護多份設定、或要在公司與家中切換環境的開發者來說，成本通常低於只靠作業系統內建代理。 對 AWS Agent Toolkit 這類會同時碰到瀏覽器、CLI、外掛行程的工具鏈，你最需要的是可重複的命中紀錄：哪個請求被哪條規則接走、是不是意外用了 DIRECT、是否有 TLS 握手失敗。沒有這些資訊，你只能不斷在編輯器裡按重新連線。
實務上我會建議你把規則寫成「由窄到寬」：先為已知的 MCP Host 或固定的開發後端寫 DOMAIN，再把 AWS 相關的廣域後缀用 DOMAIN-SUFFIX 接住，最後才落到地區或預設政策。
這樣當主控台因新子網域載入失敗時，你可以很快從記錄中抄到新主機名，而不是整包規則打掉重寫。
若你目前完全沒有規則習慣，也不要急著複製一整份社群大全；先讓管理主控台首頁與登入流程穩定，再擴充分流到 API 與 MCP。
三、AWS 管理主控台：常見網域與規則寫法思路
AWS 管理主控台與說明文件涉及多個頂級與子網域，實際清單會隨產品改版而變化，因此本文刻意不給一份「永久有效」的黑名單式列表，而是提供可遷移的判斷方式。
當你看到主控台某個區塊空白，請優先到 Clash 的連線紀錄找出失敗或極慢的目標，再回頭補規則。
對大多數情境，從 amazonaws.com、aws.amazon.com 這類後缀下手，能先接住最大量的控制台與文件請求；若你的組織帳戶額外導向特定身分解析服務或聯盟登入網址，也要一併納入規則，否則會出現「已登入但 STS 交換卡住」的中繼失敗。
撰寫規則時請注意政策組的頻寬與延遲：管理主控台會同時開很多並行連線，若你把整包後缀指到一个過載的節點，畫面不一定報錯，但會讓你誤以為雲端服務故障。 較務實的做法是讓「瀏覽器流量」走延遲穩定的出口，把高頻實驗或大量下載放到另一組政策組；這在企業網路與家用網路切換時尤其有感。 若你使用公司提供的分裂 DNS，也要同步檢查 Clash 的 DNS 設定是否與內網解析衝突，避免解析到對外公開位址後又被防火牆擋回。
四、系統代理與 TUN：什麼時候要開哪一個
系統代理的好處是設定直覺：瀏覽器與部分應用程式會自動遵從作業系統的 HTTP 代理設定。 對於只在 Chrome 或 Edge 操作 AWS 管理主控台的使用者，系統代理常常就夠用，只要你在 Clash Verge Rev 裡確認系統代理開關與埠號一致即可。 然而許多開發者工具並不會自動繼承系統代理：AWS CLI、某些語言執行緒啟動的子行程、或容器內的請求，都可能在「瀏覽器已通、終端機仍斷」的狀態下讓你困惑。
TUN 模式則透過虛擬網路卡把系統層流量交給 Clash 判斷，對「不吃系統代理」的行程覆蓋率較高，也比較容易讓本機多個工具在同一份規則下行為一致。 代價是需要驅動與較高權限，部分企筆電或受管理裝置會限制安裝；若你先前在 Windows 教學 已為 Wintun 與第一次啟動踩過權限流程，延續到 Agent 情境通常較順。 實務上我會建議先系統代理驗證規則命中，再在 CLI 仍逾時時啟用 TUN 作為第二道手段，而不是一開始就全部依賴 TUN。
五、HTTP_PROXY、HTTPS_PROXY 與 NO_PROXY 的實務配置
就算 TUN 開著，有些工具仍會對代理行為有特殊設定；為終端機顯式指定 HTTPS_PROXY 與 HTTP_PROXY 仍是 AWS 開發者最常備的逃生梯。
請以 Clash Verge Rev 介面顯示的本機埠為準，常見寫法是将代理指到 127.0.0.1 加上對應埠號，協定需與你的工具支援一致。
若你使用需要身份驗證的上游，請另外遵循你的網路管理政策；本機 Clash 多數情境是無帳密的本機埠。
NO_PROXY 的重要性常被低估：一旦你把整機流量導向代理，但某個 MCP 伺服器或區域檢查端點其實應該直連內網，就會出現雙重代理或無效閘道。
建議你把本機回呼位址、內網網段、公司內部網域名列入排除，並在切換網路環境時重新檢查這份清單。
Windows 與其他系統對環境變數大小寫與逗號格式的細節略有差異，若你是在整合式終端機與系統終端機之間切換，也要確認兩邊載入的設定檔一致。
# Example only — replace port with your Clash Verge Rev mixed/HTTP port
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,169.254.169.254上面片段僅示意結構，真正可用的埠號請你在應用程式內核對；不同版本預設可能不同，照抄網路文章數字是逾時排查裡最常見的冤枉路。
六、MCP 連線穩定：Host、TLS 與逾時的檢查清單
MCP 作為編輯器與外部工具之間的協定，連線問題往往呈現為外掛面板上的逾時或中斷，但根因可能落在四個彼此不相干的層次：DNS、TCP、TLS、或應用層重新導向。 在 Clash 分流已啟用的前提下，我建議你固定用以下順序自我掃描。 第一，確認外掛設定的 MCP Host 是否真的應該走代理：若 Host 指向本機服務，規則卻把它送到遠端節點，延遲會不合理地放大。 第二，檢視該 Host 的解析結果是否與預期區域一致，會不會被公司 DNS 劫持到錯誤入口。 第三，在 Clash 記錄觀察該連線是否反複重試、RST、或握手逾時，並對照你是否最近換了出口節點。 第四，才考慮在工具端調整逾時時間；若根因是規則誤匹配，把逾時調再大也只是把失敗變慢而已。
對 AWS Agent Toolkit 這類會密集呼叫雲端 API 的流程，也請留意節流與退避：雲端端的限速有時會表現得像網路不穩，若你同時在瀏覽器開多重主控台分頁又跑批次指令，觀察到的錯誤訊息可能混雜多種來源。 把代理出口穩定下來後，若仍遇到可重現的錯誤代碼，再回頭查詢對應服務配額與區域狀態，会比盲目更換規則有效。
七、把「可觀測」變成習慣：除錯不露死角
成熟的排錯流程其實只有一句話：每一次變更都要能對應到一條紀錄或一個度量。 當你為 AWS Agent Toolkit 新增一條規則，請同步在 Clash 端確認新規則的優先順序不會被更寬鬆的規則蓋過；當你為編輯器更新 MCP 設定，請在終端機用最小指令驗證網路仍可達，而不是只靠外掛重新整理。 若你與同事共用一份訂閱備份，也要約定「誰的版本負責接住哪些開發網域」，避免兩份規則各自漏寫一半，整合時才爆發問題。
最後補一點與心態有關的現實：雲端與代理鏈路都是會變動的系統，今天能用的規則明天可能因產品改版而需要補一行網域。 把本文的地圖思維保留下來，比儲存一份靜態 YAML 更有長期價值。 當你能清楚描述「哪個行程、對哪個主機、在什麼模式下應該命中哪條規則」，AWS Agent Toolkit 的試用過程就不會被連線噪音淹沒，你也更容易把注意力放回代理邏輯與實際業務價值。
八、常見問題（精簡版）
Q：為什麼主控台能開，但 Agent 相關指令仍失敗？
瀏覽器與終端機常走不同代理路徑；請檢查環境變數、TUN、以及該指令是否使用自己的 Proxy 設定覆寫。 也可在 Clash 記錄確認該 API 主機名是否誤判為 DIRECT。
Q：我應該把所有 amazonaws 子網域都指到同一節點嗎？
不一定。過度集中可能拖慢介面載入；較務實是讓管理主控台走穩定出口，再依服務敏感度拆分。 關鍵仍是觀察記錄並避免慢節點成為單一故障點。
Q：MCP 連線一定要啟用 TUN 嗎？
不一定。若 MCP 客戶端已正確使用系統代理或環境變數，系統代理可能就夠。 TUN 是在「工具不吃代理」時提高覆蓋率的手段，而不是儀式開關。
Q：公司網路攔截 HTTPS 時怎麼辦？
企業中間盒會導致 TLS 錯誤或憑證不信任，這與 Clash 規則是否命中無關。 需要依公司 IT 指引安裝信任鏈或改用核准的出口，並避免在不可信網路繞過安全控制。
九、可複製帶走的檢查清單
- 列出台管理主控台、API、MCP Host 三類流量並確認各自由哪個行程發起。
- 規則採「已知具體網域先、廣域後綴後」，並保留連線紀錄以便補洞。
- 先用系統代理驗證瀏覽器，再用環境變數或 TUN 覆蓋 CLI／背景工具。
- 設定 HTTP_PROXY／HTTPS_PROXY 時同步維護 NO_PROXY，避免內網誤送。
- MCP 逾時依 DNS、TLS、規則命中順序排查，避免先調大逾時閾值。
- 在測試帳戶與最小權限下試用 AWS Agent Toolkit，憑證與金鑰勿入公開設定檔。
當你把 AWS Agent Toolkit、AWS 管理主控台與 MCP 放在同一張流量地圖上，Clash Verge Rev 就不再只是「能連上網的開關」，而是讓開發反覆實測仍可預期的基礎設施。 把規則、模式與環境變數三劍合在一齊，你就能把時間花在代理邏輯與雲端能力本身，而不是連線表層的無限重試。
