一、先對齊現象：「網站能開」不代表 Copilot／Models 全鏈路都通
GitHub Copilot 代理相關問題在社群討論裡常被概括成「被擋」或「節點不好」，但工程上更值得先記錄的是哪一個環節失敗：是 OAuth／SSO 登入頁打不開，還是登入完成後 IDE 仍無法取得權杖；是 api.github.com 回應慢，還是補全串流在特定 CDN 上斷開；是 GitHub Models 的網頁資源載入失敗，還是實際呼叫模型 API 時才逾時。由於微軟與 GitHub 的基礎設施會把身分驗證、產品前端、後端 API、靜態資產與二進位下發拆到不同主機名稱，Clash 若只寫一條寬鬆規則，常出現「其中一段走代理、另一段直連」的組合，對使用者而言就是間歇性失敗。
建議您在復現問題時，同時觀察兩個維度：應用程式類型（瀏覽器、VS Code、JetBrains、GitHub Mobile 等）與錯誤發生階段（登入、索引套件、補全、Chat、Models 試用）。這會直接決定您要在連線日誌裡搜尋的關鍵字，例如 microsoftonline、live.com、github、githubusercontent、models.github、azureedge 等（實際清單請以您本機日誌為準，勿盲抄過期清單）。若尚未把機場訂閱匯入為可編輯設定，可先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教學》，確保策略群組名稱與規則檔結構清楚，再進行下列網域級調整。
二、推薦排查順序：先路徑與規則，再換節點
下列順序刻意把「換節點」往後放，因為 Copilot／Models 的斷線有很高比例來自規則命中不一致或DNS 與 fake-ip 脫鉤，而不是單純延遲。
- 確認 Clash 正在執行，並釐清您使用的是系統代理或TUN；若 IDE 或系統元件未走系統 Proxy，必要時改以 TUN 統一接管（見下文）。
- 在連線日誌中依時間軸過濾上述關鍵字，檢查每一條連線命中的策略群組是否與預期一致，特別留意是否出現
DIRECT與REJECT。 - 檢視 DNS 模式（是否
fake-ip）、以及海外網域解析是否走可信上游；必要時為特定後綴設定nameserver-policy或等效欄位（欄位名稱依核心版本文件為準）。 - 將微軟登入、GitHub 主站／API、Copilot／Models 相關後綴、GitHub 資產與常見 CDN拆成多條規則，並確認更具體的 DOMAIN／DOMAIN-SUFFIX 寫在寬鬆 MATCH 之前。
- 在規則已正確命中的前提下，再為長連線與 TLS 工作階段挑選掉包少、抖動低的節點，並避免過於頻繁的自動切換打斷 HTTP／2 或 WebSocket。
連線埠占用、訂閱更新失敗等通用議題，仍請對照《Clash 常見報錯解決方案》；本文聚焦 GitHub 與微軟交錯的多網域場景。
三、為什麼一定要拆開「微軟登入」與「GitHub 本體」
許多開發者使用 Microsoft 帳號或企業 Entra ID 與 GitHub 綁定，登入流程會經過 login.microsoftonline.com、login.live.com 這類微軟登入 CDN與身分端點；而日常操作程式碼、Issue、PR 則主要落在 github.com 與 api.github.com。兩者在證書、SNI、解析結果與路由策略上都可能不同。若您的規則只覆蓋 GitHub 後綴，卻讓微軟登入相關網域落到錯誤策略（例如誤直連導致 TLS 握手異常、或誤走延遲很高的繞路），就會出現「登入視窗打不開／授權回呼失敗」而誤判為 Copilot 壞掉。
反過來，也有人為了「能登入微軟」而把整段 microsoft.com 相關後綴一股腦塞進代理，卻忽略企業環境下某些微軟端點應直連或走內網；這屬於組織政策範疇，本文不替您決定直連／代理，但提醒您：登入鏈路必須與 GitHub API 鏈路一併納入觀察，並以日誌驗證，而不是憑印象調整。若您主要在 Windows 上使用 Microsoft Store 或 UWP 類應用，亦可延伸閱讀《Windows 應用商店下載失敗？用 Clash 為 UWP 開啟回環代理》，理解微軟生態應用與本機代理埠之間的隔離行為，避免與 IDE 內 Copilot 流量混淆排查。
四、流量分桶：帳號、主站、API、Copilot、Models 與 CDN
要把GitHub Copilot 代理問題落到可維護的設定，建議先在心智上把流量分桶。實際主機名稱會隨產品改版與區域調度而變動，下表僅列常見方向，請務必以您本機連線日誌與開發者工具「網路」面板為準。
| 類型 | 常見方向（範例） | Clash 設定提示 |
|---|---|---|
| 微軟身分與登入 | login.microsoftonline.com、login.live.com（示例） | 與 GitHub 規則分開觀察；確認 TLS 與 DNS 一致命中。 |
| GitHub 主站與 API | github.com、api.github.com、gist.github.com | API 常為長連線；避免與靜態 CDN 混在同一個過寬規則末端被覆蓋。 |
| GitHub 資產與附件 | githubusercontent.com、objects.githubusercontent.com | 大檔下載與 Release 資產；節點需穩定，逾時閾值過短易失敗。 |
| Copilot／Models 相關 | 產品文件與日誌中的 copilot、models.github 類後綴（示例） | 與一般瀏覽 GitHub 分開測試；推論與試用頁可能走不同子域。 |
| Azure／CDN 邊緣 | blob.core.windows.net、azureedge.net 等（示例） | 常與套件、延伸模組或靜態資源並行；勿只代理主域而漏 CDN。 |
GitHub Models 這類功能除了前端頁面，還會在背後觸發多段 API 與授權檢查；若您只看到 models.github.ai 其中一條請求成功，但後續推論請求落到另一個後綴並被誤判為直連，體感仍會是「偶爾能用、常常轉圈」。因此分桶的核心不是背誦網域，而是建立可重現的觀測習慣：每次調整規則後，用同一組操作路徑重播，並對照日誌是否整條鏈路策略一致。
五、DNS、fake-ip 與「看起來解析成功卻傳輸失敗」
開發者工具鏈高度依賴 HTTPS 與 SNI；當 Clash 使用 fake-ip 時，若 DNS 上游、規則匹配與實際連線目標三者未對齊，可能出現解析顯示成功但在 TLS 或內容傳輸階段異常的情況。對 Copilot 這類會建立多條並行連線、且可能混用 HTTP／2 與 WebSocket 的服務，症狀常表現為外掛狀態不穩定或第一次成功、重啟 IDE 後失敗。
實務上可以分三步收斂：第一，確認用於解析海外網域的 DNS 上游可信且可達；第二，檢查是否需對特定後綴指定 DoH／DoT，降低汙染與劫持造成的偶發失敗；第三，在調整 DNS 後清快取並重啟相關程序（瀏覽器、IDE、Clash 核心），避免舊的 fake-ip 對照殘留。若您希望系統層流量更一致，可評估依《Clash TUN 模式開啟方法》啟用 TUN，讓未正確繼承系統代理的元件也納入同一套路由與 DNS 邏輯。
六、分流規則範例：思路展示（請替換為您的策略群組名稱）
下列 YAML 片段僅示意思路：將微軟登入、GitHub 與資產網域、以及常見Azure／CDN 後綴顯式指向代理群組。請將 PROXY 換成您訂閱中實際存在的策略群組名稱，並確保細則順序符合「越具體越靠前」的原則。實際生產環境中，Copilot 與 Models 可能使用額外子域，請以連線日誌補齊 DOMAIN-SUFFIX 項目。
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,microsoftonline.com,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,github.io,PROXY
- DOMAIN-SUFFIX,githubassets.com,PROXY
- DOMAIN-SUFFIX,github.dev,PROXY
- DOMAIN-SUFFIX,models.github.ai,PROXY
- DOMAIN-SUFFIX,azureedge.net,PROXY
- DOMAIN-SUFFIX,blob.core.windows.net,PROXY若您希望「大檔下載／CDN」與「低延遲 API」分流到不同出口，可定義 PROXY_DL 與 PROXY_API 兩個策略群組，將物件儲存與邊緣網域指向前者、api.github.com 與推論類端點指向後者。請注意：過度拆分若未同步調整規則順序，反而可能造成同一主機名稱在不同時間命中不同群組，表現為更難排查的間歇故障。
七、IDE 外掛與瀏覽器：代理繼承方式不同
在 Visual Studio Code 或 JetBrains 系列中，Copilot 外掛的網路堆疊未必與您用 Chrome 測試的結果一致。部分環境僅讀取系統代理，部分則在自有執行緒中發起連線；若您只為瀏覽器設定了 Proxy Helper，而 IDE 未跟隨，便會出現「網頁能試用 Models、IDE 裡卻登入失敗」的落差。此時除了檢查 IDE 內是否有獨立代理設定外，TUN 模式往往是把多程序行為對齊的最短路徑之一。
另一個常見誤區是把問題歸因於「Copilot 帳號方案」而急著重裝外掛。建議在重裝前，先用同一台機器、同一個 Clash 設定，分別在瀏覽器與 IDE 完成一次最小復現，並保存日誌片段；若兩者失敗階段不同，幾乎可以直接鎖定為網路路徑或 DNS而非帳號本身。若您同時使用其他 AI 編輯器與 VS Code 市集，亦可對照《Cursor 擴充功能市集打不開？用 Clash 分流穩住 AI 補全與外掛下載》中關於 Electron、市集與 CDN 分流的段落，理解不同產品之間的差異，避免把 Cursor 的網域表直接套到 Copilot 上。
八、節點與長連線：穩定比測速榜第一名更重要
Copilot 補全與 GitHub Models 推論都屬於互動式、低容忍斷線的工作負載；測速延遲最低但抖動大的節點，可能讓 TLS 工作階段或 HTTP／2 連線頻繁重建，外掛端只看到無限重試。較務實的做法是：為已確認命中的相關網域規則選用一段時間內穩定的出口，適度關閉過於激進的自動切換，或在用戶端限制同一連線的故障轉移頻率。
若您使用的機場對「高併發長連線」有限制，也可能在高峰時段出現看似隨機的失敗；此時可嘗試切換至標榜適合開發者流量或限制較寬鬆的節點組，但請仍以日誌證據為準，而不是盲目更換訂閱。整體原則是：規則正確命中後，再談線路品質；順序顛倒只會讓您在不穩定的節點上反覆驗證錯誤的假設。
九、圖形用戶端裡如何少踩坑
在 Clash Verge Rev 等桌面客戶端中，建議同時開啟連線日誌與（若介面提供）DNS 相關檢視，邊操作「登入 GitHub／啟用 Copilot／開啟 Models 頁面／觸發一次補全」邊觀察網域名稱命中。若您看到特定後綴長期落在 DIRECT，請回頭檢查是否被訂閱內建的 GEOIP 或過寬規則覆蓋，以及本地自訂規則是否放在正確順序。
新手若尚未完成基礎安裝與訂閱匯入，可先依《Clash Verge Rev 完整配置教程》建立乾淨基線，再回到本文做網域級細化；這能避免同時調整過多變因，導致無法判斷是哪一項設定生效。
十、小結：把間歇性斷線拆成可驗證的鏈路
GitHub Copilot 與 GitHub Models 的體驗問題，在大多數情況下都可以還原成微軟登入 CDN、GitHub 主站／API、資產與 CDN 下發、以及產品專屬子域是否在同一套 Clash 邏輯下被穩定覆蓋。透過系統代理或 TUN 先確保 IDE 與系統行為一致，再用 DNS 與 fake-ip 對齊解析鏈路，最後以規則順序與日誌驗證每一次命中，您可以把「偶發」變成「可重現」，把排查時間從試錯換成有證據的調整。相較於只談單一聊天產品的文章，本篇刻意鎖定 GitHub 官方 AI 程式助手與 Models 試用鏈路，方便您在 2026 年持續依實際日誌擴充自己的分流表。
當您希望把連線可視化、規則編輯與核心升級集中在同一套維護良好的桌面體驗時，透過本站途徑取得客戶端並搭配 Mihomo 核心，通常比四處拼湊設定檔更省心。→ 立即免費下載 Clash，開啟流暢上網新體驗