一、為何 Copilot 在 VS Code 特別容易「斷一下又好」
GitHub Copilot在編輯器內不是「只打一支 API」：帳號與授權會碰 github.com／api.github.com；編輯器功能與資產常經 githubusercontent.com 上的代理或靜態路徑（實務上可見 copilot-proxy.githubusercontent.com 這類主機名，實際以你當下日誌為準）；模型與助理則會依訂閱分流到 githubcopilot.com 樹狀下的不同 API；若你啟用 GitHub Models，還會另走 models.github.ai。當其中任意一條路徑落在 DIRECT、被錯誤的 GEOIP 規則提前命中、或與其他下載流量共用壅塞節點，體感就會像「新特性特別容易掉線」——其實是並行鏈路裡最慢的那一段在拖。
2026 年春季起的更新讓 Agent 路徑更倚賴背景工具、終端機與較長的工作階段；若你的環境仍沿用「只代理瀏覽器」或「只寫兩三條 GitHub 規則」的舊設定，最容易出現半套成功：左側聊天能打開，右側工具呼叫或模型切換卻在轉圈後失敗。此時若直接全局切換節點，問題可能暫緩但根因仍在，更新一版 VS Code 又復發。
二、和 Cursor／GitHub 文、泛 MCP 文差在哪
站上《Cursor 與 GitHub 經常逾時》仍以另一款編輯器及其常見品牌網域為主，和微軟維度的 VS Code Marketplace、GitHub Copilot 服務邊界不完全重合；實務上兩篇並用時，請把本文視為「Copilot × VS Code 官方線路補丁」，不要假設 Cursor 規則必然涵蓋 Copilot 全平面。
《MCP 遠端工具總掉線》則聚焦你自訂的遠端工具與長連線，題材上容易和 Agent「工具化」混淆；但 MCP 的主機名清單通常來自你的設定檔與供應商，與 GitHub 官方的 githubcopilot.com／models.github.ai 仍應分區維護，避免一條寬鬆 DOMAIN-KEYWORD 互相誤傷。
三、三個平面：帳號、Copilot 服務、模型推理
帳號與 Git 平台平面
登入、授權與權杖刷新高度依賴 github.com 與 api.github.com。若此平面走代理，Copilot 面板卻直連，常見徵兆是「剛開機能、幾分鐘後要重登」。請一併檢查 OAuth 相關重新導向是否在瀏覽器與編輯器之間被打斷。
Copilot 服務平面（githubcopilot.com）
官方文件與變更公告顯示，企業與個人方案會使用不同的 API 主機後綴（例如 api.business.githubcopilot.com、api.enterprise.githubcopilot.com、api.individual.githubcopilot.com）；仍可能存在過渡期主機或舊匯流排。實務上最穩妥的維護方式是先以 DOMAIN-SUFFIX,githubcopilot.com 收斂，再在日誌中精簡。
代理與靜態平面（githubusercontent.com）
Copilot 在編輯器內載入資源或經代理轉發時，日誌常出現帶 copilot 子域的主機名；若只寫 github.com 而讓 githubusercontent.com 走不同出口，易出現資源載入半截、或 TLS 重試。請以實際連線蒐集為準，再決定是否用較寬鬆後綴一次覆蓋。
GitHub Models 平面（models.github.ai）
GitHub Models推理與型錄請求集中在 models.github.ai（官方文件與型錄路徑以此為基準；實際 URL 仍以當期文件為準）。若 Copilot 走 A 出口、Models 走 B 出口，錯誤訊息常難以判讀；建議先在同一策略組内完成驗收。
四、VS Code 延伸模組與市集流量
Visual Studio Code本體更新、延伸模組市集與 CDN 仍大量依賴 marketplace.visualstudio.com、*.vo.msecnd.net、*.microsoft.com 等命名空間。當你升級 VS Code 後首次同步 Copilot 延伸，若市集相關主機仍在 DIRECT 或命中錯誤規則，會表現為「安裝完但服務啟不起來」或版本檢查失敗。做法是：在 開發者規則區塊裡為市集／更新頻道保留獨立註解段，並避免與大型檔案下載共用同一節點。
五、規則範例（請替換 PROXY 名稱）
下列片段示範常見 Mihomo／Clash 風格規則；請將 PROXY 改成你設定中既有的策略組名稱，並依日誌增刪。註解語言維持英文以利版本控管。
若你必須最小放行，請勿長期停留在「只抄範例」狀態：以 Clash 日誌匯出實際主機名，把真的能涵蓋的 DOMAIN-SUFFIX 留下，其餘關鍵字規則應隨時間清掉，以免誤傷不相關流量。
六、策略組：互動流量與下載分開
Agents與對話屬於高互動、低容錯；大型儲存庫索引或附檔下載則偏頻寬與突發尖峰。兩者塞進同一個自動輪詢節點，常讓你在 UI 看到「模型應答慢」或請求被取消。實務建議：
- 為
githubcopilot.com／models.github.ai建立獨立url-test或fallback策略組，容忍度與測速間隔略保守，避免頻繁跳線。 - 先手動指定一條延遲穩定、丟包低的節點完成登入與功能驗證，再恢復自動。
- 背景
git、容器映像或 CI 日誌拉取，盡量不要與 Copilot 共用會頻繁切換出口的負載平衡組。
| 現象 | 優先檢查 |
|---|---|
| 登入成功、幾分鐘後 Copilot 全灰 | api.github.com 與 githubcopilot.com 是否同一策略組；OAuth 回呼是否在瀏覽器側被攔截 |
| 聊天可用、Agent 工具或終端機步驟失敗 | 是否仍有 githubusercontent.com 子域直連；必要時開 TUN 統一承接非 HTTP 代理行程 |
| GitHub Models 偶發 429／TLS 錯誤 | models.github.ai 是否與帳號平面分裂；節點是否在高並行下被供應商限速 |
七、DNS、fake-ip、系統代理與 TUN
Copilot 相關主機在 fake-ip 模式下若未納入 fake-ip-filter 或與應用程式內建 DoH 並行，可能出現「解析看起來正確、實際連線目標不一致」的怪異逾時。請固定一套你熟悉的組合：要嘛讓 Clash 核心統一解析，要嘛確保應用程式未繞過核心直連真實 IP。
僅開系統代理時，部分子行程或嵌入式執行檔可能不讀取系統 HTTP 代理；若你已確認規則無誤仍掉線，可評估 TUN 模式（注意路由與防火牆成本）。Windows 讀者可並行參考 TUN 與路由防火牆排查。
八、VS Code 代理與企業開發者注意事項
官方文件說明可在 VS Code 設定或環境變數中配置 HTTP(S) 代理，部分企業閘道另需基本驗證。請避免把帳密明文寫進可被同步的公用設定檔；若必須使用，請限制在個人設定範圍並定期轮换密鑰。更多細節請以 GitHub Docs · Copilot 網路設定（VS Code）為準。
若組織使用私有連線或 Split Tunnel，請優先遵循管理員提供的允許清單；本文之規則範例僅供本機 Clash 用戶在合法合規前提下排錯，不等同企業政策替代品。
九、可復現排查順序
- 固定變因：暫停會自動輪播節點的外掛或腳本，先在單一節點上重試。
- 收集主機名：從 Clash 日誌與 VS Code「網路」面板匯出失敗列，標註 TLS／HTTP2／重試行為。
- 核對規則順序：確認沒有更早的
DIRECT或寬鬆GEOIP提前結束匹配。 - 合併平面：暫時讓 github.com、githubcopilot.com、githubusercontent.com、models.github.ai 走同一策略組驗收。
- 恢復自動：驗收通過後，再按延遲與預算拆組，並記錄改動日期與來源公告連結。
十、合規與官方文件
請遵守 GitHub 服務條款、Copilot 授權範圍、公司資安政策與所在地法規。本文不協助規避帳戶限制、地理位置政策或供應商風控；若錯誤來自官方限流、模型下線或服務端故障，應以 GitHub 狀態與支援管道為主。涉及敏感程式碼或憑證時，請先在測試環境驗證規則變更。
十一、小結
面對 GitHub Copilot VS Code 在 2026 年更快的產品節奏，本機側最該先穩定的不是「再多裝一款外掛」，而是把帳號、Copilot API、usercontent 代理鏈路與 GitHub Models（models.github.ai）放進同一套可觀測、可維護的 Clash 規則與策略組。相較只提供粗粒度切換、可觀測性不足的封閉用戶端，Clash／Mihomo 生態在規則透明度、日誌對照與跨平台一致性上更利於長期迭代；把平面理清後，多數「新功能特別容易掉線」會收斂成單純的線路品質或官方限流問題。
若你希望一次取得可稽核的安裝包並延續本站教學結構，可由下載頁匯入訂閱後，再將本文區塊貼入你的 rules 註解段。