為什麼 Copilot CLI 比 Copilot 網頁版更容易「看起來壞掉」
多數使用者的第一個錯覺，是把 Copilot 想成單一網域服務：實際上終端機工具鏈幾乎永遠是多跳並行的。npm 會去抓 packument、tarball，並在 lockfile 與不同 registry 鏡像策略下產生新的主機別名；GitHub 相關資源又常落在 cdn 與物件儲存後端，這些名稱會隨發佈路徑漂移。GitHub API（例如讀寫議題、PR、codespace 或與 Copilot 互動的後端路由）與「純粹下載套件 tarball」並不是同一條 TCP 會話，卻可能在錯誤的規則順序下被一刀切直連或誤入不匹配的策略組，最後在 CLI 只顯示泛用逾時。
第二個錯覺是「開了系統代理就等於終端也走代理」。在 macOS 或 Windows 上，瀏覽器往往完整承接系統的 HTTP／HTTPS 代理；但 Node 生態預設只會在你明確設了 HTTPS_PROXY 等變數、工具內建 proxy、或像 mihomo 以 TUN 在路由層接管時，才让整條命令列父子行程比較一致地進入同一張策略表面。Copilot Agent 又會讓問題更「吵」：除安裝期外，實際工作階段會維持更多長連線與重試；任何一段在弱出口環境中被誤判成 DIRECT，都可能被使用者解讀成「Agent 掛了」，但根因仍在分流粒度與解析視圖。
因此本篇的方法論很單調但可靠：先用可重現的連線紀錄取得你的環境當下真實 Host／SNI，再談加規則與開 TUN。請避免一開始就複製來路不明的「完整域名表」：別人的 GEO 與 CDN 切換時間軸與你不同；你自己的 Mihomo 日誌才是最好的第一手證據。
1先復現：用連線紀錄對齊 npm 與 GitHub 的真實主機
準備好官方文件要求的 Node 版本後，請用你現場卡住的那條指令原封不動重跑：例如全域安裝會用到 npm install -g @github/copilot；若習慣單次執行則可能是 npx @github/copilot 類指令。並行打開 Clash／Mihomo 前端的連線清單或等價紀錄檢視，把逾時發生前後出現的名字抄下來。常見會入鏡的片語包含：registry.npmjs.org、鏡像（若你曾鎖過 registry.npmmirror.com 或其他企業源）、github.com、api.github.com、objects.githubusercontent.com、codeload.github.com，以及你版本中可能出現的授權／SSO 跳轉子網域。
請務必區分慢與逾時：前者可能只是節點頻寬、對端限速或 CDN 擁塞；後者常伴隨 TLS 握手卡住、路由黑洞、或被規則早送到錯的策略組。若你在同一台機器上用瀏覽器下載測速正常，也不要直接否定網路——那只是證明「瀏覽器那条路徑」暫時可用，並不等價於 npm 走的 SNI 也被同樣對待。對 WSL2／容器而言，請把宿主與容器的 DNS／代理視為兩個獨立空間；可先讀 WSL2、Git、npm 與 Windows Clash，再把本文的紀錄方法映射過去。
實務建議：同一次復現請固定「只看一種出口策略」：先選擇 export 代理變數或先選擇 TUN，避免同時疊兩套路由卻以為規則沒生效。
2TUN、系統代理與環境變數：先決定「誰在幫終端出外網」
當連線紀錄顯示大量應走代理的主機仍標成 DIRECT，你只有兩條成本不同的主軸：在當前 shell 匯出標準代理環境變數，或啟用 TUN 讓不讀變數的行程仍落入核心的轉發決策。mihomo 系的 mixed／HTTP 入站埠請與你的 HTTPS_PROXY／ALL_PROXY 協定一致，並以 NO_PROXY 排除 localhost、內網段與公司 SCM，避免把內部 Git 也硬送进跨境節點。
TUN 的副作用包含與公司全隧道 VPN、系統防火牆、以及 macOS 權限模型的互動；長開前建議讀 Clash Verge Rev TUN 模式教學，理解「誰持有預設路由」。若你只想完成安裝而不是全機長駐，亦可開一個子 shell，暫時 export 變數跑完 npm 流程後關閉，降低與其他 VPN 的競態。Copilot Agent 的工作階段通常更需要穩定長連線；此時若你反覆看到子行程漏代理，TUN 往往比「手動幫每個工具各寫一組設定」更省事，但請仍以紀錄命中驗收，而不是只觀察「感覺有開」。
3npm：@github/copilot、registry 與 .npmrc 企業 TLS
對 scoped package 而言，錯誤的 .npmrc 可能把取用導向不合規的鏡像或過期的快取中介層，表現成像「永遠拉不到正確 tarball」。請先以連線紀錄確認 registry.npmjs.org（或你實際使用的 registry 主機）是否命中預期的策略組，再去檢查鏡像與永遠線。企業 HTTPS 檢查（middlebox）若沒有把中介 CA 正確匯入 Node 信任鍊，錯誤訊息常縮寫成泛用 TLS 失敗；這與「純路由慢」完全不同，盲目調大逾時只會讓你在同個錯誤上等更久。
除非你完全理解風險，否則不要優先把 strict-ssl=false 當解方：那會讓真正的憑證／路徑問題被掩蓋。另一方面，若你確定公司環境必須走指定代理埠，也要避免 .npmrc 的 proxy 指向已下線的本地轉發，而 Clash 實際監聽的是另一埠——這類「設定打架」在連線紀錄中會呈現短暫連得上與長時間無回應交錯，容易被誤判成節點不佳。
下方 YAML 僅示意規則骨架：請把 PROXY 換成你檔案中真實存在的策略組名稱，並依連線紀錄增刪；註解維持英文以符合設定檔慣例。MATCH 最後一跳請與日常習慣一致，並確保沒有更前面的 GEOIP 規則早把 registry 吃掉。
# Example only — replace PROXY; extend hostnames from your logs
rules:
- DOMAIN-SUFFIX,npmjs.org,PROXY
- DOMAIN-SUFFIX,npm.community,PROXY
- DOMAIN-KEYWORD,github,PROXY
# GitHub API often appears as api.github.com in logs — prefer exact domains you see:
# - DOMAIN,api.github.com,PROXY
- MATCH,DIRECT4GitHub API、Copilot 互動與「不是 npm 的逾時」
當 @github/copilot 已安裝完成，卻在登入、初始化或 Copilot Agent 工具迴圈中卡住，請把懷疑從「registry 壞了」移轉到「GitHub API／授權／長連線端點沒進預期策略組」。實務上你會在紀錄裡看到 api.github.com 與其他 REST／GraphQL 相關主機，也可能看到隨產品演進而變化的子網域；請以紀錄為準，不要死背別人上個月的靜態列表。此時若你的規則集習慣性把所有 GitHub 丟直連，往往會在弱出口地區把「CLI Agent」表現成間歇性不可用。
另一個隱形坑是規則順序：早期匹配到的 GEOIP 或寬鬆 DOMAIN-KEYWORD 可能把實際該走代理的 API 路徑送去錯組；請用連線紀錄反向驗證「命中規則列」與「你以為的策略」一致。HTTP/3／QUIC 相關行為會讓某些邊界設備更敏感；若節點或本地網路對 UDP 相容不佳，則可能出現「瀏覽器退回 HTTP/2 可用、某些 CLI 路徑卻卡在 QUIC」的表象，這時可配合節點能力做對照，但根因仍應回到具體失敗主機與策略命中。
5DNS、Fake‑IP 與規則解析一致性
TUN 並不能替代 DNS 調校：若你觀察到「同一條指令早上失敗、下午又自行恢復」，優先懷疑 fallback DNS 競態、fake-ip-filter 漏項目、或路由器與桌面端雙層劫持。建議對照 Meta／Mihomo DNS 防洩漏指南，將 npm、GitHub 與你在紀錄中看到的 API 名稱一起放入「要監測一致性」的清單，而不是只盯著瀏覽器常用的幾個網站。
當 fake-ip 與某些內網／本機服務互動時，若規則與解析視圖不一致，容易出現「連線紀錄看似命中、應用卻報連不到」的假性故障；此時請用小範圍的 curl -v 對照，並確認你的 nameserver-policy 是否對特定後綴指定了不合適的 upstream。對開發者而言，最浪費時間的路線是：不停更換節點、却从未让 DNS 與規則在同一視圖下被檢視。
提醒：公司 HTTPS inspection 會改寫終端對 CA 的信任鍊；請先依資訊安全流程處理，不要用關閉校驗取代治理。
與站內其他「終端 CLI × Clash」文章怎麼分工
若你關心的是 IDE 與 GitHub／npm 同步分流，可讀 Cursor／GitHub／npm 分流，再把 IDE 與本機 shell 的出口對齊到同一組 mihomo inbound，可比較不心累。OpenAI Codex CLI 的同套路排查在 Codex CLI 與 TUN／DNS；與 Python／Node 混合型安裝鏈接壤的節奏則可參考 Google Agents CLI 與 npm／uv。每篇文章都刻意不重複 write-up 細節，但方法論共享：紀錄先行、規則粒度跟著證據走。
6驗收清單：把「感覺好了」變成可回放的操作手冊
- 以單一出口策略（TUN 或 export）復現後，確認 registry 與 api.github.com 類主機在紀錄中長時間維持預期策略組，而非在 DIRECT 與代理間來回抖動。
- 重跑安裝：對照是否仍能穩定完成
npm install -g @github/copilot（或你實際使用的等價流程），並觀察是否有被快取遮蔽的假成功。 - 進入 Copilot Agent 實際工作一段時間：留意長連線段是否仍出現非預期直連；若有，回到規則順序補洞而不是先換地區。
- 若網路路徑已對齊但錯誤訊息轉為身分、權限或訂閱類敘述，請改走官方帳務／授權排查，避免把商業限制誤修成路由問題。
常見問題（以連線紀錄閱讀）
.registry 明明可 ping／curl，為何 npm 仍失敗？ICMP 或單次 GET 與 packument／tarball 完整握手不等價，且 DNS 可能分流到不同解析視图。Agent 模式只修 API 規則夠嗎？通常還要覆蓋安裝與更新鏈路。TUN 會不會影響公司 VPN？會，需理解路由優先序與 split tunnel 政策。
開源、授權與本站下載
mihomo 與各圖形前端的授權條款請直接查 upstream 倉庫；@github/copilot 則以 GitHub 官方發佈與條款為準。日常安裝與更新建議優先使用本站 下載區 與 設定說明總覽，先釐清系統代理、mixed 與 TUN 的差異，再落盤到你的長期備份設定；本文不重製上游 release note。
結語
GitHub Copilot CLI 與 Copilot Agent 把「套件階段」和「長時間與 GitHub／模型後端互動」壓在同一個終端故事線裡：任何一段落在錯誤的對外視圖，都會被使用者放大成整體不可用。把 Clash／Mihomo 連線紀錄當唯一真相來源，先對齊 npm registry 與 GitHub API 的 hostname 粒度，再談 TUN 與 DNS，可以顯著降低無效換節點與盲調逾時的時間成本。
與只提供「一鍵翻牆」概念、但欠缺主機級觀測面的工具相比，Clash 生态把策略命中細節留在工程師可閱讀的介面上：你能看到 registry.npmjs.org 是否真的走了代理，也能看到 api.github.com 長連線有沒有在對話中途被規則送去直連。對需要長期維護團隊開發機影像的人來說，這種可回放性本身就是營運資產。
若你想把本文流程變成固定 runbook：建議先備份現有設定，再以小步驗證把 npm、GitHub、Copilot Agent 相关域名寫成可版本化的 rule-providers 片段，並記錄每次事故對應的連線截圖或文字紀錄，讓下次排查不必從零猜主機。你也可以免費下載 Clash，用本文順序對照邊界環境快速收斂問題範圍。