GitHub Copilot 登入失敗，先把症狀分清楚

使用 GitHub Copilot 時，如果 VS Code、JetBrains IDE 或其他編輯器突然顯示「登入失敗」「無法連線」或「Copilot 暫時無法使用」，不一定代表 GitHub 帳號本身有問題。當 Clash 開啟後，瀏覽器可能可以正常瀏覽 GitHub，但 IDE 裡的 Copilot 仍然持續轉圈、驗證碼頁面打不開，甚至出現 ETIMEDOUT、ECONNRESET、socket hang up 或 Failed to connect。

這類問題的關鍵，在於 Copilot 並不是單純開啟 github.com 網頁。登入流程通常會經過 GitHub OAuth、裝置驗證、Copilot API、編輯器擴充功能服務，以及模型回應端點。不同階段可能由瀏覽器、Node.js 子程序、Electron 網路層或 JetBrains 自己的 HTTP 客戶端發出請求，因此「瀏覽器能開 GitHub」只能證明其中一條路徑可用，不能直接推論 Copilot 的完整鏈路正常。

如果你搜尋的是「GitHub Copilot Clash 登入失敗」、「VS Code Copilot 連線逾時」或「Copilot 開了代理仍不能用」，建議先將現象分成三類，再依序排查：

  • 登入頁面打不開：通常與瀏覽器代理、GitHub OAuth 網域、DNS 解析或系統代理未生效有關。
  • 瀏覽器登入成功，但 IDE 顯示未登入：常見原因是 IDE 子程序沒有繼承代理，或本機回呼埠被防火牆、其他軟體或錯誤規則阻擋。
  • 已登入但補全逾時：多半涉及 Copilot API、內容服務網域、規則組選錯、節點不穩定，或 TUN／系統代理只接管了一部分流量。

合規提醒：Clash／mihomo 是本機代理與規則管理工具，不會提供 GitHub 帳號、Copilot 授權或第三方節點。請使用你本人合法取得的 GitHub Copilot 方案，並不要在公開討論區貼出 OAuth 回呼網址、存取權杖或完整連線日誌。

第一輪檢查：模式、混合埠與節點是否真的可用

不要一開始就修改大量 YAML 規則。最有效率的做法，是先確認 Clash 核心正在執行、目前設定檔已啟用，而且你選用的節點可以完成基本 HTTPS 連線。若核心沒有正常啟動，或設定檔雖然匯入但沒有切換到啟用狀態，後面所有 IDE 設定都不會產生效果。

  1. 確認設定檔已生效：在 Clash Verge Rev、Mihomo Party 或其他相容客戶端中，進入 Profiles／設定檔頁面，確認目前使用的檔案不是只存在清單裡，而是已被切換為當前設定。
  2. 確認混合埠：記下 Clash 的 mixed-port，例如 7890。混合埠通常同時接受 HTTP 與 SOCKS5 請求，比只設定單一 HTTP 埠更方便測試不同的開發工具。
  3. 確認代理模式：先使用 Rule 模式，不要一開始就用 Global 或 Direct。Rule 模式可以在連線紀錄中觀察 GitHub 及 Copilot 網域究竟命中了哪一條規則。
  4. 固定一個節點測試：暫時不要使用會自動切換的 url-test 或負載均衡組。先選一個延遲合理、近期穩定的節點，確保測試期間出口不會自行改變。
  5. 檢查本機埠是否被占用：若 Clash 顯示混合埠啟動失敗，請查看日誌並更換埠號；同一個埠被其他代理工具占用時，介面有時只會顯示核心啟動不完整。

接著可以用終端機做一個不涉及帳號的連通性測試。以下命令中的埠號要換成你實際使用的混合埠：

Shellcurl -I -x http://127.0.0.1:7890 https://github.com
curl -I -x http://127.0.0.1:7890 https://api.github.com

如果第一條成功、第二條失敗，不要立刻認定節點完全不可用；兩個主機可能命中不同規則或解析到不同的服務端點。反過來，如果兩條都逾時，應先處理 Clash 核心、節點、DNS 或本機防火牆，而不是繼續改 Copilot 擴充功能設定。

測試原則：每次只改一個變數。先固定節點，再切換規則；先測試瀏覽器，再測試終端機；最後才處理 VS Code 或 JetBrains。這樣才能知道是哪一層修正了問題。

第二輪檢查：GitHub 與 Copilot 網域不要只寫一條規則

很多人只加入 DOMAIN-SUFFIX,github.com，以為 GitHub Copilot 所有流量都會被涵蓋。這種寫法有時可以讓登入頁面載入，卻不代表 Copilot 的 API 請求也會走同一個代理群組。實際網域會隨編輯器版本、Copilot 擴充功能版本、登入方式與服務架構調整，因此最可靠的依據仍是 Clash 的 Connections 或日誌，而不是直接複製一份多年未更新的網域清單。

排查時可先觀察以下幾類主機，並依你的連線紀錄增刪：

  • github.com、api.github.com：GitHub 網頁、帳號狀態與 API 請求常會涉及。
  • githubusercontent.com：部分原始檔、設定或資源請求可能使用此網域。
  • copilot.github.com：部分 Copilot 登入或服務流程可能出現，實際狀況要以當下日誌為準。
  • api.githubcopilot.com：某些 Copilot 客戶端與擴充功能可能使用的服務端點，若日誌出現，應確保它沒有被錯誤送往 DIRECT。
  • vscode.dev 或 Microsoft 登入相關網域：VS Code 登入流程可能因版本與帳號狀態而涉及其他服務，不能只盯著 GitHub 網域。

規則優先順序同樣重要。若設定檔前面已有 DOMAIN,api.github.com,DIRECT，即使你在檔案後面新增代理規則，也可能永遠不會命中。建議把 Copilot 相關的明確規則放在 GEOIP、MATCH 或寬泛的關鍵字規則之前，並使用獨立的策略組，例如：

YAMLrules:
  - DOMAIN,api.github.com,Developer
  - DOMAIN-SUFFIX,github.com,Developer
  - DOMAIN-SUFFIX,githubusercontent.com,Developer
  - DOMAIN-SUFFIX,githubcopilot.com,Developer
  - MATCH,DIRECT

這只是排查用骨架，不代表所有環境都應直接照抄。若訂閱服務已經提供同名規則集，手動追加可能造成重複或策略組名稱不存在。請先確認 Developer 是否真的存在；若不存在，Clash 可能在載入設定檔時報錯，或將該規則視為無效。更重要的是，登入流程中的本機回呼，例如 127.0.0.1、localhost 或本機隨機埠，通常應保持 DIRECT，不要把本機回呼送進遠端代理。

VS Code 與 JetBrains：瀏覽器代理不等於 IDE 代理

登入成功後仍然無法使用 Copilot，最常見的誤區是把「瀏覽器已經能走 Clash」當成「所有應用程式都會走 Clash」。Windows 與 macOS 的系統代理設定，主要服務遵循系統代理規範的程式；某些 Node.js 子程序、Java 應用程式、內嵌 WebView 或自帶網路堆疊的外掛，可能不會完整繼承同一組設定。

VS Code 的檢查方向

在 VS Code 中，先確認 Copilot 擴充功能沒有被停用，並查看帳號選單是否真的顯示已登入的 GitHub 帳號。接著開啟輸出面板，選擇 GitHub Copilot 或相關擴充功能的日誌頻道，記下失敗時間、錯誤代碼與主機名稱。不要只截取最後一行「network error」，因為前面通常會透露是 DNS 失敗、TLS 逾時、代理拒絕，還是伺服器回傳 401／403。

如果 VS Code 使用系統代理時行為不穩定，可以在設定中搜尋 http.proxy，檢查是否殘留舊代理地址；空白值、錯誤埠號與過時的 SOCKS URL 都可能造成擴充功能走向一條不存在的路徑。若你使用 TUN 模式，應避免同時保留互相衝突的手動代理設定，否則可能出現瀏覽器走 TUN、VS Code 走舊 HTTP 代理的分裂狀態。

JetBrains IDE 的檢查方向

IntelliJ IDEA、PyCharm、WebStorm 等 JetBrains IDE 通常有自己的 HTTP Proxy 設定。請到設定頁搜尋 HTTP Proxy，在「No proxy for」或排除清單中確認沒有誤加入 GitHub、Copilot 服務網域。若設定為手動代理，主機應填 127.0.0.1，埠號則與 Clash 混合埠一致；若你改用 TUN 接管整個系統，則可先暫時關閉 IDE 的手動代理，避免雙重代理。

JetBrains 的登入視窗有時會由內嵌瀏覽器完成，但 Copilot 外掛的實際請求可能由 IDE 背景程序發出。這會造成「登入頁面已完成、程式補全仍逾時」的現象。此時請同時觀察 IDE 的代理測試結果與 Clash 連線列表：如果點擊測試後 Clash 完全沒有新連線，代表請求尚未進入核心，應優先處理 IDE 代理繼承問題。

不要混用多套代理：系統代理、瀏覽器擴充功能、IDE 手動代理與 Clash TUN 同時啟用時，最容易出現迴路、重複認證與連線忽快忽慢。排障期間建議只保留一條清楚的路徑，測試完成後再恢復日常配置。

TUN、DNS 與節點逾時：最後處理流量接管問題

如果 VS Code 與 JetBrains 都沒有穩定結果，且連線紀錄顯示 Copilot 網域偶爾出現、偶爾消失，就要檢查 TUN 與 DNS。系統代理只對願意讀取系統設定的程式有效；TUN 則在網路層攔截流量，適合處理不支援 HTTP／SOCKS 代理的程式。但 TUN 並不是開啟後就一定更好，錯誤的 DNS 模式、路由排除或虛擬介面優先級，都可能讓 IDE 仍然走錯誤出口。

建議依以下順序測試：

  1. 先關閉 TUN，只開系統代理：確認瀏覽器與 IDE 是否能正常登入及取得補全。這一步用來判斷問題是否由虛擬網卡或路由造成。
  2. 再關閉系統代理，單獨開啟 TUN：確保 TUN 已取得管理員權限，且客戶端顯示核心正在接管流量。若此時瀏覽器與 IDE 都恢復，代表原本的系統代理路徑可能與應用程式設定衝突。
  3. 檢查 DNS 模式：若日誌顯示網域解析失敗、解析速度極慢或解析結果在不同出口間跳動，先嘗試穩定的 fake-ip 或 redir-host 配置，並確認 DNS 請求沒有被錯誤直連。
  4. 排除本機與區域網路：在公司網路、校園網路或公共 Wi-Fi 中，防火牆可能限制未知 DNS、長連線或非標準代理埠。可使用允許測試的其他網路做一次 AB 對照。
  5. 最後再換節點：若同一規則下只有特定節點逾時，問題更可能是節點出口、TLS 相容性或線路壅塞，而不是 Copilot 帳號。

對於「登入成功但補全不出現」，可以特別觀察連線是否在請求後立刻被重置。Copilot 的請求不一定像普通網頁那樣短而獨立，節點若對長連線、HTTP/2 或頻繁小請求處理不佳，就可能表面上可以登入，實際補全卻一直等待。排障時固定節點比使用自動測速組更有意義，因為自動切換可能讓每次請求走不同出口，難以比較結果。

現象 優先檢查 常見處理方向
GitHub 登入頁打不開 系統代理、DNS、GitHub 規則 確認請求進入 Clash，固定節點並檢查命中規則
瀏覽器登入成功，IDE 未登入 IDE 代理繼承、本機回呼 檢查 VS Code 或 JetBrains 的獨立代理設定
已登入但補全逾時 Copilot API 網域、節點穩定性 從連線紀錄補齊網域，固定節點做測試
開啟 TUN 後所有連線變慢 DNS、路由與雙重代理 關閉系統代理或手動代理，重新測試單一路徑

常見問題：Copilot 登入與 Clash 排障

為什麼 GitHub 網頁能開，Copilot 還是顯示離線？

因為 GitHub 網頁與 Copilot API 不一定使用同一組主機、連線協定或應用程式代理設定。請查看 IDE 的 Copilot 日誌，並在 Clash Connections 中確認相關主機是否出現；若沒有連線紀錄，通常是 IDE 沒有使用 Clash，而不是節點單純逾時。

重新登入 GitHub 後，為什麼一直卡在瀏覽器回呼？

OAuth 回呼通常會返回本機位址，例如 127.0.0.1 加上臨時埠號。請確認瀏覽器沒有把本機位址送往遠端代理，並檢查防火牆是否阻止 IDE 接收回呼。若本機已有其他登入程序占用狀態，也可以完整關閉 IDE 後重新啟動，再進行一次授權。

使用 TUN 後，還需要開啟系統代理嗎？

通常不建議在排障期間同時開啟兩者。TUN 已能在網路層接管多數流量，系統代理再疊加可能造成迴路或判斷錯誤。不過不同客戶端與作業系統的實作存在差異，應以實際連線紀錄與應用程式行為為準，先單獨測試，再決定日常配置。

如何判斷是帳號問題，而不是 Clash 問題？

可以先在允許使用的正常網路環境中登入 GitHub，確認 Copilot 方案狀態與組織授權是否有效；同時查看 GitHub 官方狀態頁是否有服務異常。若其他網路可以正常使用，而同一台電腦在 Clash 開啟時失敗，才較能確定問題集中在代理、DNS、規則或節點層。

相比之下，部分只提供瀏覽器切換代理的同類工具，遇到 VS Code、JetBrains 這種由多個背景程序組成的開發環境時，往往缺少清楚的連線紀錄、規則命中資訊與 TUN／系統代理切換提示，使用者只能反覆重登入。Clash 官網 的優勢在於把混合埠、策略組、連線觀測與 TUN 排查放在同一套可理解的流程裡，方便你按照本文先固定節點、再確認規則、最後驗證 IDE 流量；如果你正好需要一個能細查 GitHub Copilot 登入與連線逾時問題的 Clash 客戶端，不妨前往下載 Clash 官網試試，從最小配置開始建立一條穩定、可觀察的開發代理路徑。