開啟 Clash 後，GitHub Copilot 卻無法登入、程式碼補全沒有反應，或 VS Code 一直顯示「Connecting to GitHub Copilot」並最終逾時，通常不代表 Copilot 帳號失效。這類問題更常見的原因是代理模式沒有接管開發工具、GitHub 相關域名被錯誤分流、DNS 解析異常，或目前節點無法穩定建立長連線。本文以 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 與 Mihomo 為例，按照由簡到難的順序，逐步排查 GitHub Copilot 的連線逾時問題。

先確認問題範圍與實際錯誤

排查之前，先不要急著修改大量 YAML 設定。Copilot 的登入、授權、補全與聊天功能可能使用不同的網域和連線流程，因此「GitHub 網頁可以開啟」並不一定代表 Copilot 已經能正常工作。你可以先將問題分成幾種情況：

症狀常見原因優先檢查項目
GitHub 可以開啟，但 Copilot 無法登入登入授權域名未走代理、瀏覽器與編輯器使用不同代理檢查規則命中與編輯器代理設定
登入成功，但補全一直轉圈Copilot API 或長連線被直連、節點不穩定檢查 api.githubcopilot.com 與節點狀態
偶爾可以補全，稍後又逾時URL-Test 頻繁切換、DNS 快取錯誤或網路丟包固定節點測試，重新整理 DNS
VS Code 正常，JetBrains 無法使用兩個 IDE 的代理環境變數或 TLS 設定不同分別檢查 IDE 的 HTTP Proxy 選項
所有 GitHub 服務都無法連線Clash 核心未啟動、系統代理失效或節點不可用先測試 Clash 控制面板及其他代理網站

在 VS Code 中，可以開啟「檢視 → 輸出」，再於右上角的下拉選單選擇 GitHub Copilot 或 GitHub Copilot Chat，查看實際錯誤。若看到 ETIMEDOUT、ECONNRESET、Proxy Authentication Required、certificate 或 socket hang up，通常可以直接對應到代理、憑證或節點問題。JetBrains 使用者則可從「Help → Show Log in Explorer/Finder」開啟 IDE 日誌，搜尋 copilot、proxy 或 timeout。

先做一個對照測試：暫時退出 Clash，直接用目前網路登入 GitHub；再重新啟用 Clash，測試同一個帳號與同一個 IDE。若只有啟用 Clash 後才失敗，問題大多位於規則分流、DNS、系統代理或節點，而不是 Copilot 訂閱本身。

檢查 Clash 模式與編輯器代理

GitHub Copilot 的請求是由 VS Code 或 JetBrains 背景程序發出，不一定會完全遵循瀏覽器的代理設定。Clash Verge 等桌面客戶端即使顯示「已連線」，也可能只是核心正在執行，尚未正確接管系統流量。首先確認系統代理已開啟，HTTP 與 SOCKS 監聽埠也沒有被其他程式佔用。

在一般桌面環境中，建議先使用 規則（Rule）模式，而不是直接長期使用全域模式。規則模式比較容易保留國內服務的直連效能，也能透過控制面板確認 Copilot 請求實際命中的策略組。如果規則尚未整理好，可以暫時切換到全域模式測試：全域模式可以使用時，便表示核心和節點大致正常，故障集中在規則分流或 DNS。

VS Code 還可能受到自身設定或作業系統環境變數影響。開啟設定，搜尋 proxy，檢查 Http: Proxy、Http: Proxy Support 與憑證相關選項。若 Clash 已經開啟系統代理，通常不需要在 VS Code 內再填一組不同的代理地址，否則可能出現「代理套代理」或錯誤埠號。若你的 Clash HTTP 代理埠是 7890，可使用下列設定作為測試，但請依客戶端實際顯示的埠號調整：

VS Code 暫時代理設定
{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": true
}

如果這組設定無效，先刪除 http.proxy，再完全關閉 VS Code 並重新開啟，讓它重新讀取系統代理。某些版本的 VS Code 會保留已建立的網路連線，單純切換 Clash 節點不一定會立即讓舊連線恢復。JetBrains 使用者則可進入「Settings → Appearance & Behavior → System Settings → HTTP Proxy」，在「No proxy」「Auto-detect」與「Manual proxy configuration」之間逐一測試。若 Clash 接管的是系統代理，優先選擇自動偵測；若自動偵測不穩，再手動輸入 Clash 的 HTTP 埠。

動手檢查規則分流與節點

這一節是最重要的實作步驟。不要只在瀏覽器開啟 github.com，而要在 Clash 的「連線（Connections）」頁面觀察 Copilot 真正使用的域名。不同版本的 Copilot 可能使用 GitHub 登入服務、Copilot API、代理下載服務及內容分發網域，實際清單會隨版本更新，因此應以連線紀錄為準。

  1. 開啟 Clash Verge、Clash Verge Rev 或 Mihomo Dashboard，確認核心狀態為執行中，並記下目前的 HTTP/SOCKS 監聽埠。
  2. 將模式切換為「規則」，選擇一個延遲穩定的節點，不要一開始就使用會頻繁自動切換的策略組。
  3. 完全關閉 VS Code 或 JetBrains，重新啟動 IDE，等待 GitHub Copilot 擴充功能載入。
  4. 開啟 Clash 的連線列表，搜尋 github、copilot 或 githubusercontent，記錄每個域名命中的規則與代理組。
  5. 若相關請求顯示為 DIRECT，先將它們加入代理規則或使用能覆蓋域名的規則集，再重新測試補全。
  6. 若請求顯示為 REJECT，檢查廣告攔截、隱私規則或第三方 Rule Provider 是否誤封了 Copilot API。
  7. 在同一個 IDE 中連續輸入幾段不同程式碼，觀察連線是否能維持，而不是只看一次登入結果。

規則的排列順序非常重要。Clash 通常採用自上而下的首次匹配原則；如果前面已有寬泛的 GEOIP,CN,DIRECT、DOMAIN-KEYWORD,github,DIRECT 或某個拒絕規則，後面新增的 GitHub 代理規則可能永遠不會被使用。較安全的做法是把明確的域名規則放在寬泛規則之前：

GitHub Copilot 分流範例
rules:
  - DOMAIN-SUFFIX,github.com,Copilot
  - DOMAIN-SUFFIX,githubusercontent.com,Copilot
  - DOMAIN-SUFFIX,githubassets.com,Copilot
  - DOMAIN-SUFFIX,githubcopilot.com,Copilot
  - DOMAIN-KEYWORD,copilot,Copilot
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

proxy-groups:
  - name: Copilot
    type: select
    proxies:
      - 自動選優
      - 香港節點
      - 日本節點
      - DIRECT

上面的網域是常見參考，不代表所有版本都必須固定加入。若連線紀錄顯示其他官方域名，也應按實際結果補充。不要把整個 github.com 無條件設為拒絕或直連，因為 GitHub 登入、擴充功能更新、程式碼同步及 Copilot API 的網路需求可能不同。測試時也建議先把 Copilot 策略組固定在單一節點，確認穩定後再改回 url-test 或 fallback。

不要只用延遲數值判斷節點：節點對測速網址回應很快，不代表它能穩定處理 Copilot 的 TLS、長連線與 API 請求。若補全仍會逾時，請直接在連線列表觀察 Copilot 請求是否被重置、切換或長時間沒有回應。

DNS、TUN 與 TLS 問題排查

如果規則命中正確但仍然逾時，下一步應檢查 DNS。當編輯器先透過本地 DNS 解析出錯誤 IP，再把連線交給 Clash 時，可能出現 GitHub 網頁偶爾能開、Copilot API 卻持續失敗的情況。Mihomo 使用 fake-ip 時，規則可以在域名層面匹配，通常比單純的 redir-host 更適合需要多個 HTTPS API 的應用。

在 Clash 客戶端中，先確認 DNS 功能沒有被其他 VPN、瀏覽器安全 DNS 或公司網路策略攔截。若使用 TUN 模式，DNS 劫持、路由設定與系統網卡順序都可能影響結果。可以依序進行以下測試：

  • 關閉 TUN，只保留系統代理，重新測試 VS Code；若恢復正常，問題多半在 TUN 路由或 DNS 劫持設定。
  • 保留 TUN，但暫時關閉其他 VPN、AdGuard、Proxifier 或企業安全軟體，避免多個虛擬網卡同時攔截。
  • 重新啟動 Clash 核心與 IDE，清除舊的連線及 DNS 對映；切換 fake-ip 與 redir-host 後必須重新測試，不能只看介面狀態。
  • 確認系統時間、時區與日期正確。TLS 憑證驗證對時間非常敏感，時間偏差可能讓登入和 API 握手直接失敗。

若日誌出現憑證錯誤，不建議直接把 skip-cert-verify 設為 true 作為永久解決方案。這會降低 TLS 驗證安全性，而且不能修復節點本身的域名、SNI 或中間人憑證問題。應先檢查節點的伺服器名稱、SNI、TLS 設定與系統時間；在公司或校園網路中，還要確認是否存在 HTTPS 檢查代理，以及其根憑證是否已正確安裝。

針對不同客戶端的最後處理

Clash Verge 與 Clash Verge Rev 通常可以直接從代理、連線、日誌頁面完成大部分排查。若修改訂閱產生的設定檔，請先確認客戶端實際啟用的是哪一份配置；只修改本地檔案而沒有重新載入，並不會改變目前執行中的規則。Clash for Windows 使用者要特別留意「系統代理」與「混合代理」開關，並確認 Windows 的系統代理沒有被其他工具覆寫。

ClashX 使用者可檢查 macOS「系統設定 → 網路 → 詳細資料 → 代理伺服器」，避免 ClashX 與其他網路工具設定不同。macOS 的權限、公司 MDM 與防火牆也可能阻止 IDE 建立背景連線。若你使用的是 Mihomo，則應以核心日誌與 Dashboard 連線詳情為準，不要只依賴桌面客戶端顯示的節點延遲。

完成修改後，建議按照「固定節點 → 規則模式 → 系統代理 → IDE 重啟 → 連線紀錄」的順序驗證。只有在單一節點連續補全穩定後，才恢復自動選優、TUN 或複雜的 Rule Provider。這樣可以避免多個變數同時改變，讓問題再次出現時難以定位。

立即開始

用 Clash 掌控您的流量

支援 Windows、macOS、Linux、Android 與 iOS，靈活規則，開箱即用。

免費下載 查看設定指南 →