這篇寫給誰？與「只設定 IDE 代理」哪裡不一樣

如果你在搜尋Cursor SDK、AI Agent、CI 或模型 API怎麼穩定連線，多半已經遇過類似畫面：在本機用圖形介面跟模型對話大致正常，一旦改成用程式觸發長時間工具迴圈、或把同一段腳本丟進流水線，就出現讀取停滯、整包請求被客戶端判定逾時、或只有某幾個步驟間歇失敗。這類問題很少是「模型忽然變笨」，而是網路路徑拆分沒對齊：Cursor 後端、各家模型 API、以及 MCP 伺服器對外連線，各自偏好的出口與 DNS 解析並不相同。

站內已有從使用者介面談 Cursor 連線與從 AWS 工具鏈談 Bedrock 分流的姊妹篇；本篇刻意把焦點放在官方 SDK 與自動化 Agent上，並用Clash的分流規則與策略組把不同網域送往你信賴的節點。你會拿到一條可重複的操作主線：先讓執行 SDK 的行程真的「看得到」代理，再把規則寫到能解釋日誌為止，最後在本機與 CI 用同一套驗證方式收斂。

為什麼自動化 Agent 特別容易「看起來像逾時」

人類在 IDE 裡閒聊時，單次請求通常短、重試成本低；AI Agent則常把「多輪對話＋工具呼叫＋檔案讀寫」串成很長的鏈結。只要鏈結中任一 HTTP 連線在錯誤的國際路由上抖動、被中間設備重設、或在自動選節點時切換了出口，上層 SDK 往往只收到一個籠統的逾時或網路錯誤，很難一眼看出是 Cursor 後端、OpenAI／Anthropic／其它供應商，還是某個 MCP 延伸出去的下載點出問題。

另一個現實是：模型 API與帳號驗證端點可能位於不同網域， CDN 與後端也可能分開；若你的規則只覆蓋了其中一段，就會出現「token 拿得到、長串流卻斷」這種非常混淆的狀態。還有一些工具鏈會在背景開新行程呼叫 git、套件索引或雲端儲存，這些都不一定會繼承你在 shell 裡以為已設好的環境。若不在Clash日誌裡逐條對照實際主機名，很容易把問題誤判成模型品質或 SDK 版本。

先把流量分類：Cursor、模型供應商、MCP 與一般網路

實務上建議在心中畫四條線。第一類是Cursor 自家後端與同步相關的 HTTPS 目標，負責工作區上下文、帳戶狀態與 IDE 生態系耦合的功能；這類網域應穩定、延遲變異小，且不宜與高頻下載混用同一個容易自動切換的策略組。第二類是模型供應商 API，可能是單一廠商，也可能是你透過 OpenAI 相容介面轉接的託管服務；此類連線常為長持續時間與較大封包，對抖動敏感。

第三類是MCP與其依賴：文件檢索、瀏覽器外掛、資料庫查詢或私訓工具，往往會連到完全不同的一批網域；若你把這類流量與模型長連線硬塞在同一個「萬用 PROXY 組」，一旦節點策略是故障轉移或自動最低延遲，就很容易在 MCP 長任務進行到一半時換線。第四類則是明確該直連的目標，例如公司內部套件庫、區網 registry、或必須走內維線路的審計服務；這些應在規則靠前處標成 DIRECT，避免被廣義关键字規則誤傷。

小結：良好分流的起點不是「找一條最強節點」，而是讓每一種業務流量有可預測的出口；自動化 Agent 的失敗模式會把「不可預測」放大成整段逾時。

Clash 側該準備什麼：策略組、規則順序與手動出口

若你已熟悉 Clash，可把本文當檢查清單；若剛從純 IDE 設定轉來，記得三件事。第一是策略組要分得夠細：至少把「Cursor」「模型」「MCP／工具」「直連」拆開，並在長任務時把關鍵組設為手動選擇，避免自動組在請求中途切換出口。第二是規則順序：越具體、越相信的目標越要靠前；過寬的 MATCH 或巨大第三方規則集若太早把 API 網域掃進不適合的組，後面再補救也來不及。

第三是驗證方式：請養成同時看 UI 延遲與連線日誌的習慣。延遲測試只能剔除明顯壞節點，無法保證長連線與上傳穩定；Agent 任務的真實裁判永遠是「同樣腳本能不能連續跑完」。當你為 Cursor 生態調規則時，與其一次寫死十幾條猜測網域，不如先讓一次真實任務跑過，再從日誌抄實際命中主機名回寫到設定檔，這和本站AWS Agent Toolkit 分流教學裡強調的「由日誌驅動規則」是同一套邏輯。

本機執行 SDK：環境變數、終端繼承與 NO_PROXY

多數語言與 Node／Python 生態的 HTTP 客戶端會讀取 HTTPS_PROXY、HTTP_PROXY，部分還認 ALL_PROXY。在啟動會呼叫 Cursor SDK 的指令前，請在同一個 shell 會話內匯出這些變數，指到你本機 Clash 暴露的混合埠或明文代理埠；若你混用訂閱與公司內網，請一併設好 NO_PROXY，把 127.0.0.1、內部網段與必要的本機 MCP 位址排除在外，避免工具誤把該直連的目標再繞一圈。

如果你選擇 TUN 或系統級接管，仍建議用日誌確認 SDK 行程沒有因細粒度路由而「看起來該走代理、實際繞過」。有些本機防護軟體或分開的 VPN 也會插入路由表，造成 only-CLI 異常；這時不要急著調模型參數，先把網路堆疊簡化成「單一 Clash 出口＋可解釋的規則」，問題定位會快很多。

# Example: point CLI tools at local Clash mixed port (adjust 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,internal.company.corp

網域層級規則怎麼寫才不踩雷

具體網域會隨產品更新而改動，因此本文刻意不給一份「永久有效」的清單，而是強調方法：在分流規則中優先使用你在日誌裡看過的完整主機名，能用 DOMAIN 就不要先上過寬的 KEYWORD；若供應商大量使用同一後綴，再以 DOMAIN-SUFFIX 收斂。對於明顯屬於 CDN 或通用託管的前綴，要警覺規則過寬帶來的副作用——它可能把無關流量也鎖進慢速節點，側面拉高整體逾時率。

寫規則時請同步檢查 DNS 模式：fake-ip 能提升命中效率，但在長鏈路除錯時容易造成「我以為走了 B 節點，其實客戶端仍握著舊解析」的錯覺。當你在調 Agent 相關設定時，短期改用較可觀測的解析路徑、或在客戶端側清快取，往往比狂切節點有效。

注意：請勿把公司或第三方的私密 API 金鑰、Runner token、訂閱網址貼到公開頻道；範例中的主機名與埠號僅示意，實際請以你環境為準。

MCP 與子程序：繼承代理與「半套代理」陷阱

MCP常見部署型態是父程序啟一個或多個子服務，再由子服務對外連線。若只有父進程繼承了 HTTPS_PROXY，而子進程由 systemd、背景啟動器或以乾淨環境拉起，就會形成半套代理：對話主循環可走出口，工具一伸出來就掉到直連或錯誤路由上。解法一側是統一由同一個 shell profile 或程序管理器注入環境；另一側則是在Clash規則中，把工具實際連到的網域補齊，讓無論直連或代理都「可預測」。

對會主動回撥或使用長輪詢的 MCP，請把它們與一般短連線分組；避免與需要大包上行的模型串流共用「自動選最快」組。自動組適合瀏覽網頁，不適合當程式化任務的主力出口。

CI／Runner 場景：沒有桌面時的同一套思路

在 CI 中跑 Cursor SDK 或外圍自動化時，沒有選單列小圖示可點，環境反而更該明確：在 job 最前面匯出代理變數、確認 Runner 能連到本機監聽埠（若在容器內跑 Clash 核心便要調整 namespace）、再用最短腳本驗證每一次重點 API。若組織政策禁止長駐代理行程，可退而求其次使用允許的上遊 HTTP 代理，但仍應保留「集中出站＋可看日誌」兩個性質，否則間歇性逾時會在流水線上被放大成 flaky job。

對多倉或多矩陣構建，建議把代理相關變數與NO_PROXY收斂成共用模板，避免每個 yaml 各自拼貼造成某些步驟漏設。並請注意：私密 registry 往往必須直連，這類規則應排在命中雲端 API 的規則之前，以免被誤送到外網節點。

逾時、重試與 SDK 參數：網路穩了再談

當分流規則仍亂序時，把 SDK 的逾時秒數盲目加長，只會讓流水線更慢、資源更塞。合理順序是：先在Clash日誌中確認關鍵網域命中同一策略、節點在任務期間沒有自動切換，再調整客戶端重試。對於可冪等的步驟，適度重試能掩蓋短暫抖動；對長串流或大型上傳，則應優先確保單一路徑穩定，而不是堆疊重試次數。

若你同時啟用公司 VPN 與本機 Clash，請畫一張簡單的流量圖確認「誰是最後的出口」；雙重 NAT 與重複 TLS 中繼層常會製造看似隨機的失敗。把所有自動化輸入收成單一路徑，再在該路徑上調規則，會省大量爭論模型版本的時間。

驗證劇本：從一次性成功到可重複成功

建議準備四步驗證。第一步，用最小 curl 或語言內建 client 對 Cursor 後端與模型端點各做一次簡短 HTTPS 請求，確認證書鏈與代理皆正常。第二步，跑一個固定 seed 的最小 Agent 任務（例如只讀檔不做工具），把 baseline 延遲記錄下來。第三步，逐步打開 MCP 與工具權限，每加一項就對照連線日誌有沒有新網域出現並命中錯組。第四步，把同一劇本在 CI 重跑兩輪，若第二輪才失敗，優先懷疑節點自動變更與 DNS 快取，而不是懷疑上游限流。

這套劇本的好處是把「不可重現」變成「可定位」：你知道新增的是哪一類網域、應該進哪個策略組，而不是被籠統的 Agent 逾時訊息嚇到以為整個 SDK 壞掉。

常見問題

IDE 正常、SDK 異常，第一件事要看什麼？

先看執行 SDK 的行程是否與 IDE 使用同一組代理設定與 DNS；再看Clash日誌中實際連線主機名是否完整落在你的規則覆蓋內。大多數案例在核對環境後就會縮小範圍。

真的需要為 Cursor 與模型拆兩組節點嗎？

不一定，但若你觀察到長串流與短 API 對丟包敏感度不同，或某節點對特定 CDN 路徑特別差，拆分策略組能用最低成本換來穩定性。關鍵是「可預測」，而不是「越多越好」。

網路政策因地區與合約而異，請自行遵循適用法律與服務條款；本文僅討論在已允許的網路環境下，如何用Clash讓開發工具流量更可預測。

結語

相較只在 IDE 裡勾選「使用系統代理」這種單點設定，自動化 Agent與Cursor SDK要求你把 Cursor 後端、各家模型 API與MCP工具鏈放在同一張可觀測的地圖上；只要任何一條支線在錯誤出口上抖動，上層就會把問題折疊成令人沮喪的整包逾時。Clash的價值在於用清晰的分流規則把這些支線分開治理，再用手動策略組鎖定長任務的出口，最後用日誌讓每一次調整都可驗證，而不是靠運氣重試。

市面上一部分臨時腳本式代理或來源不明的修改版工具，常常缺乏細粒度規則與可操作的連線紀錄，遇到 SDK 這類多網域、長連線場景時，只能一再加長逾時或手動重跑。Clash 系客戶端則把規則順序、策略組與日誌驗證變成標準動作，長期維護成本通常更低。若要為桌機環境一次整理安裝入口與相容說明，也可前往Clash 用戶端下載頁帶回適用的官方發行版本，再與本文的分流思路搭配使用。