一、為何遠端 MCP 容易「像代理壞掉」
MCP 的本質是讓模型與工具透過結構化協定互動；當 MCP Server 架在遠端（雲端、內網穿透或第三方託管）時，IDE 外掛與後端之間往往維持持續連線或頻繁往返：WebSocket Secure（WSS）、HTTP 長輪詢、Server-Sent Events（SSE） 等。這類流量對延遲抖動與中途換出口特別敏感：若你的 Clash 把同一策略組設成自動測速輪換，或與大量下載、串流共用壅塞節點，就很容易出現逾時、重連或工具呼叫半套成功，錯誤訊息卻只寫「connection reset」「failed to fetch」之類泛用文字。
另一個高頻根因是規則分流不完整：設定檔只把常見網站丟進代理，但你在 MCP 設定裡填的自訂主機名（例如 *.example.com、自訂埠或路徑）從未出現在 rules: 裡，導致請求落在 DIRECT、MATCH 的預設出口，或與其他規則分裂路由。再加上 DNS 若由瀏覽器 DoH 或系統繞過 Clash 解析，就會出現「解析看起來合理、實際握手卻怪」的現象，與 fake-ip 與 DNS 排查 所述情境相通。
二、與 Cursor／GitHub 逾時文如何互補
站內 Cursor 與 GitHub 分流與逾時專文 已涵蓋 github.com、githubusercontent.com、Cursor 品牌網域與 IDE 延伸模組常見逾時路徑，重心在「開發者日常與版控／API」。本文則聚焦你在 MCP 設定中額外指定的遠端主機：這些名稱通常不會出現在通用訂閱規則或 GitHub 段落裡，必須另開規則區塊或獨立策略組，才能把長連線與一般網頁流量拆開。
兩篇並用時的實務順序可以是：先用 Cursor／GitHub 文確認 IDE 基底連線與訂閱規則無大洞，再依本文把 MCP 專用主機加入較前段的 DOMAIN-SUFFIX／DOMAIN 規則，並指派到延遲穩定的策略組。這樣可避免把問題誤判成「GitHub 又掛了」，實際卻是自訂 MCP 網域漏寫。
| 面向 | Cursor／GitHub 專文 | MCP 遠端主機（本文） |
|---|---|---|
| 主要痛點 | 克隆、API、Release、IDE 同步逾時 | 工具列表閃斷、WSS 重連、遠端 MCP 握手不穩 |
| 網域來源 | 相對固定的 GitHub／Cursor 命名空間 | 使用者自訂或團隊提供的 MCP 主機名 |
| 調校重點 | 覆蓋版控與 CDN 後綴、調策略組 | 長連線綁低抖動節點、避免與大檔下載共用出口 |
三、MCP 傳輸型態與流量特徵
本機 stdio
許多教學以本機指令啟動 MCP，透過 標準輸入輸出（stdio） 與 IDE 通訊；此時沒有你可寫的「遠端網域」，Clash 看到的是本機程序。但若該程序內部再去連雲端 API，仍會產生對外連線，需從連線日誌辨識主機名。
HTTP、SSE 與 WSS
遠端託管常見HTTPS 端點或 WSS（在 TLS 內的 WebSocket）。這類連線往往比單次 REST 請求更長壽，對代理逾時、節點輪換與中間設備（公司 SSL 檢查、防毒 HTTPS 掃描）更敏感。若你把 MCP 與一般「開網頁」流量塞進同一個壅塞或頻繁自動切換的策略組，體感就會像「MCP 一直重連」。
自訂埠與路徑
設定檔可能出現 https://host:8443/path 等形式。Clash 多以網域與 IP做規則匹配，埠通常由應用程式與傳輸層處理；重點仍是完整主機名要進規則，並確保該主機在TLS 下的 SNI 與出口一致，必要時可對照 TLS Handshake Timeout 與 SNI 排查專文。
四、從日誌與 IDE 找出實際主機名
在撰寫任何 DOMAIN-SUFFIX 之前，請先列出真實連線使用的完整主機名。建議做法包含：
- Clash 連線日誌／即時連線：於 MCP 重現問題的時段，搜尋失敗或反覆建立的 TCP 連線，記錄
Server Name或目標網域。 - IDE 開發者工具或 MCP 外掛日誌：部分外掛會列出正在連線的 URL；注意
wss://與https://可能對應不同子網域。 - 系統層封包或 Proxy 輔助工具（進階）：若合法且在你環境允許，亦可輔助確認是否有繞過系統代理的程序。
取得清單後，優先以 DOMAIN-SUFFIX 覆蓋你控制的後綴；對第三方單一主機可暫用 DOMAIN，再視情況收斂。切勿過度使用寬鬆的 DOMAIN-KEYWORD，以免與無關服務衝突。
五、分流規則示例（替換策略組名）
以下示例以常見 Mihomo／Clash 規則格式撰寫，MCP_PROXY 請替換為你設定檔中的策略組名稱（專門給 MCP／低延遲互動使用）。example.com 請改為你的遠端 MCP 網域或團隊提供的後綴。
若訂閱內建「全域」或「開發者」規則包，仍請檢查順序：較早的 GEOIP、DIRECT 或過寬的 MATCH 可能讓 MCP 相關請求提前匹配完畢。將明確的 MCP 網域放在較前段，通常比事後調單一節點更有效。
撰寫或匯入規則前，亦可先閱讀本站 設定說明，確認 rules 與 proxy-groups 名稱與你的訂閱一致。
六、策略組與長連線節點選擇
為 MCP 單獨建立策略組的目的，是讓長連線不要與大檔下載、串流或自動測速過於激進的線路綁在一起。實務上可考慮：
- url-test／fallback：適度拉長測速間隔，避免因頻繁切換節點而打斷 WSS；若仍不穩，可暫改手動選擇單一節點對照。
- 延遲與丟包：互動工具往往重視抖動與連線保持，而非僅看 ping；可觀察同時段其他服務是否正常，以區分「節點品質」與「規則漏網」。
- 與下載分流：大型 git clone、容器映像或模型檔下載應盡量走另一策略組，避免與 MCP 搶佔同一出口頻寬。
部分進階使用者會在核心支援的前提下結合規則與程序名稱（視客戶端與平台而定）做更細分流；若你發現僅 IDE 程序異常，可再對照 終端機代理與環境變數 與 TUN 模式文，確認沒有分裂路徑。
七、DNS、fake-ip 與 TUN／系統代理
完成分流規則後，若 MCP 仍偶發失敗，請依序檢查：
- fake-ip：確認 MCP 相關網域的解析與實際連線、規則命中一致；必要時參考 fake-ip 與 DNS 排查專文。
- DoH／系統 DNS：若瀏覽器或系統繞過 Clash 查詢，可能導致「規則寫了卻仍怪」的現象。
- 系統代理與 TUN：少數 IDE 子程序可能不遵循系統代理；若懷疑流量未進核心，可在合規前提下評估 TUN 模式，並對照 Clash TUN 與 Windows 路由／防火牆排查（其他平台亦有類似路由層考量）。
整體原則是：讓DNS 解析鏈、規則命中與實際出站三者敘述同一件事；任一角不一致，長連線服務都容易以「隨機掉線」呈現。
八、症狀與優先調整對照
| 現象 | 優先調整（網路層） |
|---|---|
| 工具列得出現、一呼叫就逾時 | 查日誌是否仍有子網域漏網；將 MCP 網域規則前移；檢查 SNI／TLS |
| 同一節點下，一般網頁正常、MCP 一直重連 | 為 MCP 建獨立策略組，減少自動輪換；避免與下載共用 |
| 僅特定時段失敗 | 對照節點負載與測速排程；暫改手動節點驗證是否為出口跳動 |
| 公司網路或 SSL 檢查環境 | 與 IT 確認憑證與攔截政策；錯誤常偽裝成逾時 |
九、RULE 順序與維護習慣
規則列表由上而下匹配，請將明確的 MCP 網域置於寬鬆規則（如 GEOIP、全域 MATCH）之前，並在設定檔中以註解（建議英文註解以利工具相容）標註年份與來源，避免半年後忘記為何新增某條後綴。
第三方 MCP 供應商若更換閘道主機名，你的規則也需跟進；這比單純更換訂閱更常見。建議每季或在升級 IDE／外掛後，重跑一次「日誌抓主機名」流程，維持規則與現實連線同步。
十、小結
面對 IDE 外掛連線遠端 MCP（Model Context Protocol）Server時的掉線、工具呼叫失敗或長連線不穩，請先辨識傳輸型態與實際主機名，再以 Clash 分流規則將這些網域從泛用 PROXY 中拆出，綁到低延遲、少切換的策略組，並對齊 DNS、fake-ip 與系統代理／TUN 行為。與 Cursor／GitHub 逾時專文並用時，前者處理版控與 IDE 基底生態，本文補上自訂 MCP 主機與長連線維運視角，較能完整覆蓋 2025–2026 年常見的「MCP 代理／連線失敗」排查路徑。
相比只能切換少數開關的工具，Clash 生態在規則可視化、核心替換與多平台客戶端上，更利於長期維護；把 MCP 相關網域與策略組整理清楚後，日常多半只需微調節點即可。
若你尚未安裝或希望換用更易管理的客戶端，可從本站取得安裝包並匯入訂閱，再依本文為遠端 MCP 補上規則與策略組。