GitHub Copilot 連線逾時怎麼辦？Clash 設定排解指南

先確認逾時發生在哪一層

GitHub Copilot 突然無法登入、VS Code 顯示連線逾時，或程式碼建議長時間停在載入狀態時，不必先重裝編輯器。Copilot 的請求通常會經過編輯器、擴充功能、作業系統代理設定、Clash 或 mihomo 核心、DNS 解析，以及代理節點等多個環節。任何一層沒有正確接手，都可能在介面上被簡化成同一個 ETIMEDOUT、ECONNRESET 或「Unable to connect」錯誤。

排查前先記錄四項資訊：使用的作業系統、編輯器名稱與版本、Clash 客戶端及核心版本，以及錯誤發生的時間。也要分清楚是「登入頁面無法開啟」、「已登入但建議不出現」，還是「聊天功能可以使用但程式碼補全逾時」。這三種現象不一定走相同的請求路徑，不能只更換節點後就認定問題已經解決。

現象	優先檢查位置	常見原因
登入頁面載入失敗	瀏覽器、系統代理、DNS	網域無法解析、代理未接管或節點無法建立 TLS
登入成功但建議不出現	編輯器擴充功能與輸出記錄	擴充功能未啟用、請求被規則直連或連線在背景逾時
聊天可用、補全逾時	不同請求的分流與節點品質	特定 API 網域規則不一致、節點對長連線或串流支援不穩
所有服務同時失效	Clash 核心、系統代理與本機連接埠	核心停止、連接埠變更、TUN 或系統代理未啟用

確認 Clash 核心與代理模式

Clash 客戶端視窗能夠正常開啟，不代表 mihomo 核心正在運作，也不代表 Copilot 的連線已經通過核心。先查看 FlClash 或其他客戶端的核心狀態、目前模式與監聽連接埠。常見的混合代理連接埠是 7890，但實際數值應以目前設定中的 mixed-port 為準。控制介面常見為 9090，它只供客戶端管理核心，不是給 VS Code 填入的代理連接埠。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

在只使用系統代理伺服器的情況下，支援系統代理的瀏覽器與編輯器通常會將 HTTP、HTTPS 請求送到 127.0.0.1:7890。若 Copilot 使用的程序沒有讀取系統代理，則需要在編輯器或作業系統環境變數中明確指定代理。TUN 模式可以接管更多不遵循系統代理的流量，但它需要網路權限、虛擬介面與路由設定；啟用 TUN 並不會自動修正錯誤的規則。

檢查系統代理與連接埠

在 Clash 客戶端確認核心狀態為執行中，並記下 mixed-port 的實際值。
確認系統代理已開啟，且 HTTP 與 HTTPS 代理指向同一個本機混合連接埠。
不要把 external-controller 的 9090 填入編輯器代理設定。
若同時啟動兩個 Clash 客戶端，先關閉其中一個，避免連接埠與系統代理互相覆蓋。
修改代理或模式後，完全重新啟動編輯器，再觀察新的連線記錄。

如果使用 TUN，建議先暫時切換到系統代理模式進行對照。系統代理模式可以縮小問題範圍；若系統代理下 Copilot 正常、TUN 下逾時，通常應檢查 TUN 的自動路由、DNS 劫持、排除清單與防火牆，而不是立刻更換整份訂閱。

修正規則分流與 DNS 解析

Copilot 相關服務可能使用多個網域，登入、授權、程式碼建議、聊天與遙測請求也可能由不同端點處理。只將某一個熟悉的網域加入代理規則，不能保證整個登入或建議流程都會走代理。當規則模式下部分請求直連、部分請求走代理時，最常見的結果就是登入頁偶爾成功，但背景請求逾時或不斷重新驗證。

先在 Clash 日誌中尋找編輯器啟動與產生建議時的網域，觀察每個請求最後套用的規則與策略組。測試期間可以將相關服務暫時放入同一個可靠的代理策略組，確認問題是否由分流造成；測試完成後，再根據日誌縮小規則範圍，不建議長期使用過度寬泛的全域代理規則。

測試方式	可判斷的問題	注意事項
切換至 Global	判斷是否為規則分流錯誤	只作短時間測試，完成後恢復 Rule
在 Rule 模式查看日誌	確認實際網域與命中的策略	不要只根據瀏覽器網址列猜測
更換同一策略組中的節點	判斷單一節點或出口 IP 問題	每次只更換一個節點並重試
暫時停用 TUN	判斷虛擬網卡與路由是否造成中斷	停用後應確認系統代理仍處於預期狀態

避免 DNS 與代理出口互相矛盾

DNS 污染或解析結果不一致，可能使編輯器連到錯誤的 IP，進而表現為 TLS 錯誤或連線逾時。使用 mihomo 時，應檢查 DNS 是否啟用、fake-ip 或 redir-host 模式是否與目前的 TUN 方案相容，以及是否存在將相關網域指定到不可用解析器的 nameserver-policy。

若啟用了代理 DNS 或 fake-ip，請不要同時讓系統、瀏覽器與 TUN 各自接管解析，否則可能出現「瀏覽器正常、編輯器失敗」的差異。可以先保留一套明確的 DNS 路徑，清除本機 DNS 快取後重新啟動 Clash 核心，再觀察日誌中的解析結果。修改 DNS 後若錯誤由逾時變成憑證錯誤，表示請求已經前進到 TLS 階段，排查方向也應隨之改變。

檢查編輯器代理設定與節點品質

VS Code、JetBrains IDE 與其他編輯器對代理的處理方式不完全相同。有些版本會沿用作業系統代理，有些擴充功能則依賴 Node.js 的網路層或編輯器提供的代理設定。若 Clash 已經開啟系統代理，但編輯器仍無法連線，應檢查編輯器設定中的 HTTP Proxy、Proxy Support、Strict SSL 與代理授權選項。

以 VS Code 為例，搜尋設定中的 http.proxy、http.proxySupport 與 http.proxyStrictSSL。本機 Clash 代理若沒有額外帳號密碼，可使用類似以下的代理位址；連接埠必須替換成實際的 mixed-port：

http://127.0.0.1:7890

通常不應在沒有憑證問題證據時關閉嚴格 TLS 驗證。將 http.proxyStrictSSL 設為 false 可能暫時掩蓋企業憑證、攔截代理或系統信任鏈問題，卻無法修復節點連線。若公司網路使用自訂根憑證，應依組織政策將憑證正確加入受信任存放區，而不是長期關閉驗證。

用日誌分辨節點與編輯器問題

TCP connect timeout：通常表示節點出口、路由或防火牆無法在時限內建立連線。
TLS handshake timeout：可能與節點品質、系統時間、SNI、憑證鏈或中間攔截有關。
ECONNRESET：遠端或中間設備主動重設連線，可用另一節點與不同網路交叉測試。
407 Proxy Authentication Required：編輯器使用了需要帳密的代理，但設定未提供正確認證資訊。
401 或 403：請求已抵達服務端，應檢查登入狀態、帳戶權限、出口 IP 或組織政策。
沒有任何 Clash 日誌：請求可能沒有經過 Clash，應先檢查編輯器代理設定、環境變數與 TUN 接管狀態。

節點測速結果只能反映某個測試網址的延遲，不能完全代表 Copilot 的長連線、TLS 或串流請求品質。建議選擇延遲穩定、封包遺失較少的節點，連續測試三次以上，再讓編輯器重新登入。若只有某一節點逾時，而其他節點正常，應保留規則不變，只替換策略組中的節點，這樣最容易確認根因。

若完成上述步驟後仍然逾時，可以在不公開權杖與帳戶資訊的前提下整理診斷資料：錯誤時間、錯誤碼、使用的核心版本、命中的規則、節點所在地區，以及是否能在另一個網路環境重現。這些資料比單純提供「Copilot 不能用」更能協助定位問題。確認 Clash 與編輯器都使用正確代理後，再檢查帳戶登入、組織授權與服務端狀態，避免把服務端故障誤判為本機設定錯誤。