為什麼「Cursor SDK／雲端 Agent」比在 IDE 裡更容易撞到逾時

2026 年許多開發者會把工作流延伸到程式化代理人（programmatic agents）：用 Cursor SDK、自動化排程或在 CI／本機 Wrapper 腳本裡觸發雲端 Agent，並透過Agent API與線上協調／計費閘道交換資料。這類請求往往不是單次的簡短 REST：可能包含長連線、多輪的工具回呼、身分權杖更新，以及對第三方服務的串接。MCP（Model Context Protocol）則常被用來為助理掛載額外能力；其中一部分對話發生在本機程序之間（例如 stdio），但只要工具鏈需要抓遠端設定、存取雲端儲存、或呼叫另一個 HTTPS 服務，就仍然會出現「和一般 API 一樣」的出口選路問題。

當你在 Cursor 圖形介面裡一切順利，卻在終端機或背景服務看到連線逾時、TLS交握卡住，或偶發的502／503，第一個該懷疑的通常不是「雲端壞了」，而是流量沒有穩定走過你預期的代理路徑：Clash 的規則分流把某個子網域匹配到 DIRECT（直連），導致長連線在錯誤出口上擺盪；或是執行 SDK 的那段行程根本沒有讀到系統 Proxy，也沒帶 HTTPS_PROXY，於是請求直接撞向區域路由不友善的線路。與僅在瀏覽器操作相比，終端代理脈絡更碎：有的 HTTP 堆疊讀 macOS／Windows 系統設定，有的只看環境變數，還有的完全內建略過 Proxy。這就是為什麼同一台機器會出現「IDE 沒事、腳本有事」的落差。

接下來我會用可複現順序說明：如何以 Clash Verge Rev（Mihomo／Clash.Meta系核心）從連線紀錄抓到真實目的地、如何調整 YAML 的規則順序，以及 HTTPS_PROXY／ALL_PROXY該寫進哪些啟動來源。你在搜尋「Cursor SDK 代理」「雲端 Agent 逾時」「MCP Proxy」時看到的片段答案，多半會收斂到同一組旋钮：規則、系統代理模式、環境變數所在的 shell 脈絡。

規則分流與全域 TUN：雲端 Agent 場景怎麼選

先把兩件事分開：規則分流決定「這個網域走哪個策略群組」；系統代理／TUN決定「有多少流量會先被送進 Clash」。在 Clash Verge Rev 裡，常見起手式是開啟系統代理，讓支援系統設定的程式把 HTTP(S) 導向本機 mixed-port。若你已確認規則正確、連線紀錄卻仍偶發漏網，或某些子行程始終略過系統設定，再把TUN 模式當成驗證與覆蓋手段，而不是預設的日常工作模式——否則易與公司 VPN、其他加速軟體搶路由，反而更難收斂。

模式 優點 風險／成本 較適合的訊號
規則分流＋系統代理 精準分流 API、內網與套件倉庫；團隊可版控共用片段 須維護網域清單與順序；不吃系統 Proxy 的行程要另補環境變數 連線紀錄看得到請求，但策略欄顯示 DIRECT
全域 TUN 可涵蓋更多未宣告走系統 Proxy 的堆疊 路由複雜時易衝突；除錯訊號變多 規則看似正確但特定子行程仍對外直連
僅手動環境變數 對單一專案能快速試錯 在多個終端機、容器與排程間易漂移 你確認只有某一條 SDK 指令需要明確 Proxy

實務上建議用「連線紀錄是否出現該請求」當分界：完全沒出現，優先檢查系統代理開關與埠號是否對齊 mixed-port；有出現但策略錯誤，優先調規則集順序與 DNS；有出現且策略正確仍延遲偏高，再往節點品質、HTTP／2、IPv6 或本機時間同步方向查——後者常常被誤判成「代理商不穩」。

小提示：Verge Rev 各版本的「連線」「Connections」「日誌」標籤可能略有差異，請以可排序目的地網域或行程名稱的即時清單為準；若截圖教學與你的介面不同，可用設定內搜尋鎖定關鍵字。

開始改 YAML 前先對齊的三個事實

這份檢查清單能把「感覺改了很多卻完全沒生效」的比率壓低：

  • 目前正在生效的是哪一份設定檔？介面上可能同時存在訂閱合併結果、草稿與「使用中」檔案；請確認已套用且熱載入的是你正在編輯的那份。
  • mixed-port 是否仍舊：HTTPS_PROXY若指向升級後已變更的埠號，會變成規則正確但請求送往空埠的假象。
  • 是否有第二套路由在改封包：公司資安代理、另一套 VPN 或透明解密，可能讓 Clash 連線紀錄看似正常、實際卻在另一層被改寫；排錯期建議暫時只保留單一路徑。

第一步：用連線紀錄定位「雲端 Agent／Agent API 走錯了哪條路」

開啟 Clash Verge Rev 的即時連線檢視，在另一個終端機視窗重現會觸發 Cursor SDK或雲端 Agent的指令（例如建立雲端執行、輪詢狀態、或會拉遠端設定的初始化流程）。錯誤剛發生時，於清單內過濾關鍵字：

  • 常見種子詞：cursor、api、agent、registry、cdn；實際子網域會隨產品調整與 CDN 換邊而變動，請以你在列表反覆看到的 FQDN為準。
  • 若條目顯示 DIRECT，但目的地顯然屬於海外雲服務閘道，應將該後網域寫成精確規則，並上移到大範圍「直連／地區」集合之前。
  • 若列表中完全沒有相關條目，代表請求未進入 Clash：回到系統代理是否開啟、或該 SDK 子行程是否內建忽略系統 Proxy。

比起直接複製他人貼的「完整網域表」，以自己的連線紀錄當真實來源更可靠：你的訂閱規則集、DNS 模式與區域網路條件都和他人不同；一旦辨識出穩定出現的 FQDN，再在團隊內共享 YAML 片段，維護成本會低很多。

MCP 要不要管？先分「本機 stdio」與「外向 HTTPS」

MCP常見的架構是編輯器或助理行程透過 stdio 與本機工具伺服器溝通，這一段通常不經過 HTTP 代理。但若你的工具需要下載模型索引、存取遠端儲存、或呼叫供應商提供的 HTTP API，那些連線就會出現在 Clash 的連線紀錄裡，與一般 Agent API沒有本質差別。排錯策略仍是：先過濾實際主機名，再決定是否要把某個 DOMAIN-SUFFIX接到正確的策略群組，而不是假設「掛了 MCP 就不用管代理」。

若你同時在跑多個雲端工具（例如第三方 IDE 外掛市場、其他模型供應商的 CLI），也建議在連線清單裡用行程名稱或啟動埠輔助過濾，避免把不同產品的流量混在同一個「感覺逾時」的桶子裡一起猜。

第二步：把辨識出的後網域接到實際存在的策略群組

下方片段僅為結構示意，請將 PROXY-GROUP-YOU-USE替換為設定檔內確實存在的策略群組名稱（例如自動選線或手動選擇群組）；並把整段置於會把所有「國內直連」「大型 CDN 直連」一口吃掉的規則集之前。

# Example — replace PROXY-GROUP-YOU-USE; keep above broad DIRECT / GEOIP / CN rule-sets
# Append only hostnames YOU observed in Verge Rev connection logs
DOMAIN-SUFFIX,cursor.sh,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,cursor.com,PROXY-GROUP-YOU-USE

若你大量使用上游維護的 RULE-SET，請特別留心其中是否存在「把一整包雲端後網域導向 DIRECT」的路徑；Agent API與身分驗證主機最常栽在這種過於粗略的規則。解法通常是上移精確 DOMAIN／DOMAIN-SUFFIX，而不是一刀切停用整包集合。

使用 fake-ip 或分流 DNS 時，若解析結果與預期區域不一致，TLS 仍可能在錯誤 IP 上擺動；此時應同步檢查 nameserver 分流是否把特定網域送入易被污染的解析路徑，而不是只看到「連線紀錄有出現就以為結束」。遇到 IPv6／雙棧環境時，也值得暫時觀察是否只有某一條位址族的線路異常。

合規提醒：請在遵守所在地法規、網路使用政策以及 Cursor／相關雲端供應方服務條款的前提下使用本文方法；下文僅描述常見網路排錯流程，不包含規避監管或濫用 API 的意圖。

第三步：HTTPS_PROXY／ALL_PROXY該寫進哪些啟動脈絡

「環境變數放哪」等同在問：到底是哪個父行程開了執行 Cursor SDK／雲端 Agent 的那個 shell？常見落差如下：

  • macOS／Linux 互動式 zsh／bash：將 export HTTPS_PROXY=http://127.0.0.1:<mixed-port>（與對應的 HTTP_PROXY）寫進會被載入的 ~/.zshrc、~/.bashrc或由 source引入的拆分檔；終端機多工器請在修改後重開視窗確認。
  • IDE 外部終端與內建終端：有些整合式終端繼承 GUI 行程環境而非登入 shell；可在 IDE 設定加入啟動前指令，或以外層 wrapper 先 export再啟動子行程。
  • Windows PowerShell／cmd：可先用 $env:HTTPS_PROXY="http://127.0.0.1:埠"做單次工作階段驗證，再決定是否寫入使用者環境變數；留意服務帳戶與互動使用者隔離。
  • 排程與背景服務：launchd、systemd user unit、或工作排程器預設不一定載入互動式 shell 設定檔；請在單元檔內顯式宣告 Environment=或在腳本最上方 export。

實務上可同時設定 HTTPS_PROXY與 ALL_PROXY（若工具鏈讀後者），並以 NO_PROXY保留 127.0.0.1,localhost,::1與公司內網網段，避免把內部 Git、私有 PyPI／npm 鏡像誤送進海外節點。對長時間開著代理寫程式的情境，這種「對外走穩定出口、對內維持直連」的切分，往往比全域硬轉更省心。

瀏覽 Clash／Mihomo 各桌面用戶端下載聚合

第四步：用 curl 與實際 SDK／CLI 做最短驗證迴圈

改完規則與環境變數後，建議依序執行：

  1. 以 curl -v並搭配 --proxy http://127.0.0.1:<mixed-port>對你在連線紀錄中看到的主機做探測，先確認本機代理鏈與憑證鏈正常。
  2. 撤除 --proxy，在平常實際用來跑 SDK的同一段 shell 重跑；若僅在有明式 Proxy 時成功，問題就在規則未命中或未讀環境變數，而非單一線路瞬斷。
  3. 最後再執行會觸發雲端 Agent或會間接拉出 MCP 外延請求的完整指令流程，同時盯住 Verge Rev 連線清單的策略欄；若策略正確但延遲仍偏高，優先換節點或檢查長連線相容性。

這個迴圈能把「抽象的不穩」切成可描述的幾種分支：代理鏈故障、規則漏網、環境脈絡錯誤，或上游限流與區域路由波動——每一種對應的修法都不同，混在一起只會越改越灰心。

第五步：節點型態如何把「總逾時」放大成真實痛感

即便規則與環境變數都正確，下列因素仍會讓程式化Agent API在體感上像是「常常在等超時」：

  • 長連線與多段工具呼叫：雲端代理人在單次操作背後往往觸發多個請求；若出口對長連線、特定 TLS 指紋或不常見 HTTP／2 行為不友善，錯誤常以逾時而非立即 RST 呈現。
  • IPv6 與雙棧：部分網路讓 AAAA 記錄走不同出口；若只在 IPv4 側檢視規則，仍可能錯過 IPv6 的旁路問題。
  • 時間不同步：憑證驗證失敗常被誤解成線路問題；虛擬機與多重開機環境尤應先校時。

仍未收斂時可再對照的快速清單

  • 連線紀錄完全沒有 Cursor／雲端相關網域：檢查系統代理開關、埠占用、SDK 是否內建略過 Proxy。
  • 規則已加卻仍 DIRECT：往上檢視是否有更高優先權的 rule-set／GEOIP 先匹配。
  • MCP「本機通了、雲端偶爛」：在連線紀錄找工具實際打出去的主機，而不是只看 IDE 側錯誤訊息。
  • 同桌機他人正常只有你異常：檢查本機 SSL 解密、公司資安代理或額外套件注入的根憑證。

為什麼在自動化／SDK 場景下，Clash 生態較封閉加速器更好收斂

坊間許多封閉加速器把應用清單綁在二進位裡：雲端供應商一旦新增Agent API子網域或 CDN 換邊，使用者只能等新版本，對需要長期跑程式化Cursor SDK與零散 MCP 外延連線的工程師而言，這類黑箱特別棘手。Clash搭配 Clash Verge Rev與 Mihomo核心，允許你用可版控的 YAML 在「看得到連線紀錄」的前提下迭代代理分流，並以 HTTPS_PROXY精準補齊終端／排程這類容易漏掉的脈絡；當雲端產品的出口或區域線路再變動時，多半只要調幾行規則與環境變數即可跟上。

相較把一切押在全域 TUN或單一不透明旋钮，強調規則與環境變數實測並用的作法，對需要同時對外調模型、對內拉私有 Git 的情境通常更省力：對外走穩定出口，內網與本機測試維持直連，出事時也更容易用連線紀錄還原真實路徑。Clash Verge Rev提供的圖形介面只是把這件事變得可視——底層仍是你能理解、也能在團隊內共享的網路設定流程。

立即免費下載 Clash，為 SDK、雲端 Agent 與 MCP 建立可複製的代理設定 →