npm install 總逾時？2026 Clash 分流 registry.npmjs.org 與 tarball CDN 實測步驟

為什麼「明明有開代理」，npm、pnpm、yarn 仍常一直轉圈？

許多開發者代理場景的挫折感並不是「終端機完全無法上網」，而是套件管理工具在抓取公開註冊表資料與套件封裝 tarball 這兩段鏈路上的體驗割裂：瀏覽器能上 GitHub README，但pnpm install卻在解析某個依賴的 metadata 後停在某個/-/格式的下載連結；或是錯誤訊息明確指向ECONNRESET／ETIMEDOUT對齊registry.npmjs.org這類上游 registry主機名。

與只看影片或聊天室頁面的流量不同，Node 套件生態會把請求切成多種「主機名不連續」的細步驟：先向註冊表取得套件版本對照與tarball URL欄位，再依這個網址去拉檔（在不少預設設定下仍以npmjs名下主機為主，但也可能因企業私服、CDN 規則、或離線套件快取而改到其他網域）。若分流規則只覆蓋其中之一，另一端被提前命中到錯的策略，就會出現「進度百分比偶爾走一走、過一陣整條卡住」的假性成功。

合規提示：Clash／Mihomo 為本機規則與轉送工具，不提供公開節點。請在合法合規與組織政策允許的情境下調整HTTPS_PROXY與公司套件倉策略，並避免將訂閱連結對外公開。

若你才剛開始匯入訂閱與對照前端顯示名稱，建議先把 訂閱匯入教學跑完，再回到本文細修規則，避免rules裡的策略群組名稱與訂閱不符而整段載入失敗。

registry.npmjs.org 與「tarball CDN」實際上各管什麼？

先把心智模型對齊，之後撰寫DOMAIN-SUFFIX規則時才不會只靠關鍵字硬撞。

metadata：版本樹狀資料與依賴圖前半段

當你執行npm install lodash或讓套件管理器重建node_modules時，第一道流量通常是對註冊表發出的 HTTP(S)請求：/pkg或含版本區間的相容查詢。公開 npm 的官方端點在大多數環境對應到registry.npmjs.org或同集團的npmjs.*別名。若這一台被國際出口抖動或被誤規則帶進不穩線路，依賴圖往往在「還沒開始下載大檔」前就失敗。

tarball：依賴圖對應的實際位元組載點

metadata 會回報要拉哪個.tgz：pnpm-lock.yaml與package-lock.json也常把對應的網址寫進鎖檔。若你只放行了 metadata 主機而把 tarball hostname 暴露在寬鬆的RULE-SET之後仍未命中Proxy，就會變成「解析成功、下載卻卡住」。實務上只要用 Clash 日誌觀察一輪pnpm add，通常就能一次蒐齊這條鎖鏈上要放行的主機名集合。

國內鏡像為什麼要刻意維持直連？

常見cnpm／npmmirror／企業內 Nexus離開使用者較近的機房，對延遲與吞吐量往往比「國外節點再繞一圈」來得穩。若你把GEOIP CN DIRECT或第三方「全站直連表」放得過寬又不檢視例外，會出現國內 registry 仍可走國際出口或相反「該進代理的官方網域名被規則卡死在不存在的鏡像路徑」兩種反例。本稿建議將「國內鏡像」「企業私服」與「npm 官方公開註冊表鏈」拆成可分別調整的策略群組，再以日誌驗證。

pnpm、yarn、Corepack 與環境變數會如何改寫請求鏈路？

Yarn Berry可能透過.yarnrc.yml把npmRegistryServer指到相容端點；pnpm預設仍沿用你能以pnpm config list與npm config list檢視的registry。NODE_OPTIONS、HTTPS_PROXY／ALL_PROXY／NO_PROXY若在 shell profile 曾殘留測試值，也常讓請求半途改走Corporate HTTP proxy而繞過本機規則層。最穩的除錯路徑是：先將 Node 側代理殘渣清到預設、固定單一 Clash／Mihomo 出口，再打開日誌重現問題。

若在容器或 WSL 還要疊 Gateway，請把 Docker Desktop 分流專文對照宿主與套件管理器視角一起讀；容器內的daemon.json或 BuildKitmirror若又改指向不同 registry，請另建規則而不是假設宿主與子系統完全一致。

對 AI 編碼外掛同時會拉 MCP 套件鏈的情境，可把 MCP 工具鏈分流文當並行參考：該稿偏 Model Context Protocol 與市集外掛，本篇則鎖定在套件 tarball 載點／registry.npmjs.org這條更可泛化的底座。

規則順序：為什麼複製 YAML 片段後看似仍像沒命中？

mode: Rule下rules自上而下匹配，命中即結束。若巨大的RULE-SET或GEOIP出現在任何「你希望微調的官方 npm 細節」之前，您後補的DOMAIN-SUFFIX規則便根本輪不到比對。整站分流骨架可對照 規則分流深度文；本篇只補強其中「開發者套件管理」那一段要插入的位置與粒度。

若你已啟用 TUN 模式請分兩題查：其一是「請求是否真的進 Mihomo」，其二是「進來後規則顯示出哪個策略」，避免把問題誤會成節點品質。TUN／系統 Proxy／IDE 嵌入式終端三套入口若不同步，也常造成「終端卡住、瀏覽器順」的假信號。

可直接貼上用再依日誌精修的規則骨架

下列片段為教學級骨架請替換顯示名稱並依訂閱實際內容補proxies:條目；將NPM_REGISTRY_PROXY相關規則放在所有會提早結束比對的大型規則集之前。

YAMLproxy-groups:
  - name: "NPM_REGISTRY_PROXY"
    type: select
    proxies:
      - "NPM_STABLE"
      - "Your-Node-US-West"
      - DIRECT
  - name: "NPM_STABLE"
    type: url-test
    proxies:
      # paste real proxies from subscription
    url: "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # official npm hostname bundle (prepend before broad GEOIP/RULE-SET)
  - DOMAIN-SUFFIX,npmjs.org,NPM_REGISTRY_PROXY
  - DOMAIN-SUFFIX,npmjs.com,NPM_REGISTRY_PROXY
  # corporate Verdaccio / registry mirror overrides (examples)
  # - DOMAIN,registry.company.lan,DIRECT
  # - DOMAIN-SUFFIX,npm.taobao.org,DIRECT # legacy naming, replace when needed
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

粒度提醒：若日誌出現npm install期間對gitlab.com、github.com、物件儲存子網域或企業 SSO 的流量，請額外用DOMAIN級別補規則，而不是盲目擴張NPM_REGISTRY_PROXY到過寬DOMAIN-KEYWORD以免造成除錯與資料外洩風險。

實測與除錯劇本：建議照這個順序收斂

  1. 最小復現套件：挑一個體積適中的公開套件並暫時關閉額外延遲請求來源（例如並行數個pnpm dlx）。
  2. 單機模式：在NPM_REGISTRY_PROXY中用select強制鎖一枚低抖動線路對照自動測速群組。ETIMEDOUT 若鎖線後仍存在，問題多半已不是節點而是 DNS、鎖檔或由離線套件快取／私服策略造成的路徑分裂。
  3. 檢視實際主機集合：依序記錄 metadata 請求、tgz 請求是否在相同策略組；如遇 tarball 對不同 hostname，立刻補對應DOMAIN或細化的RULE-SET。
  4. 清理 Node 級代理：.npmrc／shell／CI 內建的proxy與環境變數需成套檢視；僅重裝 Node 並不會自動還原錯誤的NO_PROXY。
  5. 核對企業政策：若公司要求所有公開 registry 必須經內部代理，請把內部代理主機名與證書信任鏈一併納入計畫，而不是只覆寫 npmjs。

常見問題速答

我只把瀏覽器走 Clash，為什麼終端機仍逾時？因為npm子行程讀的是系統路由與 Node 自己的 proxy 設定；若系統層沒把該行程導入 Clash 或NO_PROXY誤把registry.npmjs.org排除，日誌裡會看到請求DIRECT到國際 BGP 並抖動。TUN／透明代理對全域行程覆蓋度較高，但仍請核對規則命中。

我已經把鏡像寫進.npmrc，還會碰到官方 tarball 逾時嗎？若鎖檔回溯到套件本身仍宣告官方網址，或離線套件快取與私服策略未完整鏡射，請求仍有機會對官方載點；此時請用日誌確認實際 URL 而不是猜測。

pnpm 的workspace與 Turborepo 會讓問題變複雜嗎？是的，並行請求會放大抖動並讓自動測速群組更早切換；除錯期先將並行降到最低，並讓.npmrc、pnpm-workspace.yaml指向的registry／store-dir策略彼此一致。

結語

2026 年前端與基礎設施專案高度依賴npm生態，與其只在社群貼「換 registry」或「重裝 Node」兩句口訣，不如先掌握metadata 與 tarball 兩段式流量，再用 Clash／Mihomo 把registry.npmjs.org及日誌中出現的 tarball 主機收斂到可觀測、可切換的開發者代理策略裡，同時讓國內鏡像與企業私服維持合理直連。當規則順序、DNS、Fake-IP 與 Node 環境變數彼此對齊時，多數npm install 逾時案例可在不改動套件版本的前提下收尾。

相較於零散加速器指令或只靠作業系統級 VPN「整台一把抓」，市面不少作法往往摸不清終端實際命中的主機名，也少有可複審、可分享的 YAML，多成員團隊在 CI 與本機對齊時容易反覆陷入同樣的卡頓。ClashSource把規則敘述與 Docker／WSL／TUN／IDE 差異打包在同一套文件脈絡底下，對照連線紀錄就能把「卡在 registry 還是 tarball」、「該直通鏡像還是統一走開發者代理」說清楚。若你想把本篇步驟穩定下來，不妨先在合法合規前提下 免費下載 ClashSource，再依 教學文件將規則收斂成團隊能審核的版本。