MCP 工具拉取總逾時？用 Clash 分流 npm 與 GitHub 穩住 Model Context 生態（2026）

1. 為什麼 MCP 特別依賴 npm 與 GitHub

MCP 把「工具能力」抽象成伺服器；許多參考實作與社群套件以 Node.js發布，安裝路徑往往是 npx -y <package>或指定版本的 tarball。套件本體從 registry.npmjs.org（或企業鏡像／Verdaccio）下載；若伺服器原始碼託管在 GitHub，還會觸發 codeload.github.com、objects.githubusercontent.com、raw.githubusercontent.com等邊緣主機。與「只開瀏覽器看說明文件」不同，這些連線多由 IDE 子行程、終端機或背景安裝程式發起，若未統一走 TUN或一致的HTTP(S) 代理環境變數，很容易出現瀏覽器正常、工具鏈卻間歇逾時的割裂感。

Clash能做的是把上述主機名的流量對齊到選定的策略組，並用日誌確認規則命中；它無法修復上游 registry 故障、GitHub 速率限制或專案本身的相容性問題。把期待放在正確層級，排查會快很多：先確認「請求有沒有進隧道、主機名有沒有在規則前段被接住」，再談節點品質與頻寬。

2. 常見現象：安裝、npx 與 IDE 內建逾時

你可能在設定檔或圖形介面中新增 MCP 伺服器後，看到長時間連線中、無法啟動，或錯誤訊息含 ETIMEDOUT、ECONNRESET、fetch failed。同一台機器上，手動在終端機執行 npm view或 git ls-remote有時成功、有時失敗，也很符合出口漂移（例如 url-test頻繁換節點）或部分行程未走代理。另一種典型是：公司內網把 registry.npmmirror.org等鏡像設為預設，但 MCP 安裝腳本仍硬編碼官方 registry，導致規則與你的心理模型不一致——此時應以實際日誌中的主機名為準，而不是憑印象寫規則。

若錯誤發生在OAuth 或 GitHub App 授權階段，除了網路路徑，也要檢查瀏覽器與本機回呼埠是否被防火牆攔截；本篇主軸仍是套件與 API 主機的 Clash 分流，授權流程需另對照工具官方文件。

3. 建議優先覆蓋的網域與 registry

下列清單為 2026 年常見起點，請務必與你本機 Clash 日誌、IDE Network 面板交叉驗證後再合併到訂閱規則前段。企業環境若使用私有 registry，請把實際 FQDN 一併列入，避免只放行官方網域却漏掉內部鏡像。

• npm 公開 registry：registry.npmjs.org；若使用鏡像，另加對應後綴。
• GitHub API 與網頁 API：api.github.com、github.com（視日誌精簡，避免過度寬泛影響其他 Git 操作）。
• GitHub 下載與物件儲存：codeload.github.com、objects.githubusercontent.com、raw.githubusercontent.com。
• 可選：套件完整性／簽章驗證：若日誌出現 registry.npmjs.org以外的 *.npmjs.org子域，再逐一補上。

4. DNS、Fake-IP 與規則順序

當 Fake-IP與域名規則並用時，若出現「解析看起來正確、連線却走錯策略組」，請先核對 DNS 模式、nameserver-policy與規則順序是否一致；整體觀念可從 高級規則分流指南建立。對 MCP 場景，另一個隱形變因是 HTTP/3（QUIC）走 UDP：若 TUN 對 UDP 與 TCP 處理不一致，CLI 或內嵌執行環境可能表現為間歇逾時；可暫時關閉 QUIC 做對照測試。

Windows 上若僅開系統代理而終端機未繼承環境變數，npm 仍可能直連；可交叉閱讀 Windows 上 npm／pnpm 與 Clash一文，將 HTTP_PROXY／HTTPS_PROXY與 NO_PROXY對齊本機 mixed-port，並避免把內網 registry 誤送入隧道。

5. mihomo 規則與策略組範例

以下片段示範如何為 MCP／套件鏈建立獨立策略組，並在 rules前段加入可讀條目。請將策略組名稱、節點名稱替換為你環境中的實際字串；註解使用英文以利版本控管。

proxy-groups:
  - name: 🔌 MCP & Registry
    type: select
    proxies:
      - LOW-LATENCY-A
      - LOW-LATENCY-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,registry.npmjs.org,🔌 MCP & Registry
  - DOMAIN-SUFFIX,api.github.com,🔌 MCP & Registry
  - DOMAIN-SUFFIX,codeload.github.com,🔌 MCP & Registry
  - DOMAIN-SUFFIX,objects.githubusercontent.com,🔌 MCP & Registry
  - DOMAIN-SUFFIX,raw.githubusercontent.com,🔌 MCP & Registry
  # Optional: only if logs show tarball/installer hits this host
  - DOMAIN-SUFFIX,github.com,🔌 MCP & Registry
  # ... GEOIP DIRECT and MATCH below

6. 與「只寫 IDE 網域」專文如何分工

站內 Cursor 與開發者網域專文以 IDE 本體、延伸模組與常見 API 路徑為主軸，並已點名 npm 與 GitHub 作為工具鏈一環。本篇則把鏡頭拉近到 MCP：假設你已理解 IDE 分流，但仍卡在伺服器安裝與 registry 拉取，則應優先核對本節與第 3 節的主機名是否在日誌中出現、是否命中 🔌 MCP & Registry（或你自訂的同名策略組）。兩篇並讀時，建議以日誌中的實際 SNI／Host為唯一真相來源，避免重複堆砌類似規則却漏掉 objects.githubusercontent.com這類下載節點。

若你在容器或 CI 內建 MCP 相依，亦可參考 Docker 容器走主機 Clash一文，將 HTTP_PROXY指向宿主 mixed-port，並與本篇網域規則對齊，避免「宿主已代理、容器仍直連」的落差。

7. 驗證清單與責任邊界

完成設定後，建議依序確認：① 安裝 MCP 時日誌是否出現預期的 registry 與 GitHub 主機名；② 命中規則名稱是否與預期策略組一致；③ 終端機與 IDE 子行程是否共用 TUN 或一致的代理環境變數；④ 暫停 QUIC 後問題是否仍可重現。若仍逾時，請先排除上游服務狀態與專案版本相容，再調整節點。