GitHub Copilot 為何會顯示連線逾時
GitHub Copilot 的「沒有反應」「登入失敗」或「Request timed out」不一定代表節點失效。一次完整的 Copilot 操作，通常同時涉及 GitHub 登入與授權、Copilot 服務端點、編輯器外掛的版本檢查、模型請求，以及少量靜態資源與遙測連線。這些請求不一定使用同一個網域，也不一定在同一時間建立連線。只要其中一條連線被錯誤地直連、送到延遲過高的節點，或在 DNS 與 TUN 接管之間發生不一致，最後就可能被 VS Code、JetBrains 或其他 IDE 統一顯示成「Copilot 逾時」。
Clash 使用者最容易遇到的誤判，是看到瀏覽器可以開啟 GitHub，就認為 Copilot 必然能工作。事實上，瀏覽器可能已經使用系統代理，而 IDE 的 Electron、Java 或原生網路模組可能讀取另一組代理設定；即使 IDE 讀到了系統代理，Copilot 外掛建立的 WebSocket、HTTP/2 或背景服務連線，也可能因規則命中不同而走另一條路。換句話說，GitHub 網頁可用只能證明其中一部分流量正常，不能直接證明 Copilot 的授權、補全與模型請求都已經通過。
2026 年的排障重點，不是盲目更換節點，而是先把問題拆成「本機代理是否生效」「Copilot 相關主機是否命中正確策略」「DNS 是否正常解析」「節點是否能維持長連線」四個層次。建議每次只修改一項設定，並在同一個 IDE、同一個檔案與同一個帳戶狀態下重試，否則多個變數同時變動，很難知道真正有效的是規則、節點，還是重新登入本身。
先區分登入、補全與聊天功能
排障前請先記錄具體症狀。若你在 IDE 中按下「Sign in」後瀏覽器沒有開啟，或瀏覽器完成授權後 IDE 一直停留在等待畫面，問題通常靠近登入回呼、瀏覽器與 IDE 之間的交接，不應一開始就修改模型路由。若帳戶已顯示登入成功，但輸入程式碼後右側沒有補全建議，則應檢查 Copilot 外掛是否啟用、目前檔案語言是否支援，以及補全請求是否被代理規則阻擋。若補全偶爾出現、長回答或 Copilot Chat 特別容易逾時，則更像是長連線穩定性、節點出口品質或模型服務端的問題。
| 現象 | 優先檢查方向 | 不要先做的事 |
|---|---|---|
| 登入按鈕沒有反應 | IDE 外掛狀態、瀏覽器回呼、本機防火牆 | 不要先大量新增 GitHub 規則 |
| 登入完成但補全無回應 | 外掛是否啟用、代理模式、連線日誌 | 不要只測 github.com 首頁 |
| 補全偶爾成功、聊天頻繁逾時 | 節點穩定性、長連線、DNS 與 TLS | 不要只用一次延遲數字選節點 |
| 所有 IDE 都無法使用 | Clash 核心、系統代理、TUN、節點服務 | 不要把問題歸咎於單一外掛版本 |
如果只有某一個 IDE 出問題，請先把範圍縮小到該 IDE 的網路設定與外掛環境。例如 VS Code 可能受使用者設定檔、企業政策或啟動參數影響；JetBrains 系列則可能有獨立的 HTTP Proxy 設定。若瀏覽器、Git 命令列和兩個不同 IDE 都同時逾時，才更值得回頭檢查 Clash 的模式、節點與 DNS。這種由小到大的測試順序，比直接重裝所有軟體更容易保留可用線索。
Clash 代理模式、系統代理與 TUN 排查
先確認 Clash 客戶端本身正在運行，而且目前使用的是你以為的那份設定檔。常見桌面客戶端包括 Clash Verge、Clash Verge Rev、Mihomo Party 與其他 Mihomo 圖形介面；它們的選單名稱可能不同，但核心核對項目大致相同：目前模式是規則、全域還是直連，混合埠是否正在監聽，系統代理是否已開啟，以及實際使用的策略組是否有可用節點。
最簡單的隔離方法，是在短時間內將模式切換成全域代理，再重新啟動一次 Copilot 補全。若全域模式下立刻恢復，通常表示規則模式沒有涵蓋某個必要主機，或該主機被更前面的規則送往直連。這個結果只代表「規則可能有問題」，不代表全域模式適合長期使用。確認方向後，應回到規則模式，用連線日誌找出實際命中的網域，再建立範圍較小、意圖清楚的分流規則。
若全域模式仍然逾時，接著檢查系統代理與 TUN 是否重複接管。系統代理通常只影響會主動讀取作業系統代理設定的應用程式；TUN 則可能把未讀取代理設定的原生程式也納入虛擬網卡路由。兩者同時存在並非一定錯誤，但在排障時會增加路徑數量。可以先保留一種接管方式做測試：桌面 IDE 先使用系統代理，確認結果後再關閉系統代理、改由 TUN 接管，分別比較登入與補全行為。
也要檢查本機埠是否被其他代理軟體佔用。Clash 常見的 mixed-port、HTTP 代理與 SOCKS 代理可能使用不同埠號；如果舊版 Clash、VPN、加速器或容器服務仍佔用相同埠，介面看似啟動，實際上新核心可能沒有成功監聽。遇到這種情況，請查看核心日誌中的 bind、address already in use 或「埠已被使用」訊息，不要只依賴托盤圖示判斷。
安全的測試順序：先確認 Clash 核心運作，再用全域模式做一次隔離測試，接著檢查系統代理或 TUN 的單一路徑，最後才回到規則模式微調網域。每次測試都要記下「模式、節點、IDE、結果」四項資料。
從連線日誌找規則命中與 DNS 問題
打開 Clash 的連線或日誌頁面，在 Copilot 重新觸發補全時觀察新增項目。不要只搜尋 github.com，因為登入、授權、API 請求、內容服務與靜態資源可能分散在不同主機。你需要關注的是：請求是否出現、命中的規則名稱是什麼、最後交給哪個策略組、連線是否在 TLS 握手階段中斷，以及同一個操作是否反覆切換多個網域。若某一項請求根本沒有出現在 Clash 日誌，代表它可能走了另一個代理、被 TUN 路由到不同介面，或在本機階段就被防火牆攔截。
規則設計上，應優先使用官方文件或實際日誌確認過的主機名稱，不要把整個網際網路的寬泛後綴都交給同一節點。過寬的 DOMAIN-SUFFIX 規則雖然看似省事，卻可能把不需要代理的 GitHub 資源、公司內部服務或其他開發工具一併送到高延遲出口。更穩妥的做法是先建立一個專用策略組，例如 COPILOT，讓已確認的登入與服務端點共用該組；測試穩定後，再決定哪些公共 GitHub 資源可以直連。
DNS 是另一個容易被忽略的環節。若你啟用 fake-ip，卻讓某些請求由系統 DNS 解析、另一些請求由 Clash 的 DNS 模組解析，可能造成 IP 映射、SNI 與規則判斷不一致。當日誌顯示「規則看起來正確」，但 TLS 長時間停在連線中，請比較 redir-host 與 fake-ip 模式下的結果，並確認遠端 DNS、fallback DNS 和代理解析設定沒有互相矛盾。修改 DNS 後需要清除 IDE 或作業系統的 DNS 快取，否則舊解析結果可能讓測試結果失真。
對開發者而言，還應檢查環境變數是否偷偷覆蓋了 Clash 的設定。終端執行 env | grep -i proxy 或在 Windows PowerShell 查看相關環境變數時，若發現 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 指向另一個埠號，Git、外掛更新器或 IDE 子行程可能會完全繞過目前的系統代理。若曾經設定過公司代理或舊 VPN，也要檢查 NO_PROXY 是否包含不該繞過的主機，並在完成測試後恢復符合工作環境的值。
節點穩定性、IDE 設定與修復流程
Copilot 的補全請求通常很短，但短請求不代表對節點要求低。IDE 可能同時維持多個 HTTPS 連線，背景服務還會進行授權刷新、版本檢查與狀態同步。某個節點在瀏覽器開網頁很快，不代表它能穩定維持大量短連線或長時間閒置後重新使用的連線。測試時不要只看延遲排行榜，還要觀察連續十次請求是否有失敗、TLS 建立時間是否忽高忽低，以及切換網路後是否需要重新登入。
建議先選一個出口位置相對穩定、負載不高的節點，將它固定在 COPILOT 策略組中測試。若使用 url-test，請注意探針網址的可達性與 Copilot 實際服務並不相同；探針只適合協助排除明顯失效的節點，不代表測出的最低延遲就是最佳節點。若多個節點都在相同時間失敗，應優先懷疑規則、DNS、帳戶狀態或服務端，而不是繼續更換更多節點。
IDE 端則要確認 Copilot 外掛已更新到與目前編輯器相容的版本，並檢查是否被工作區設定停用。重新載入視窗、登出後重新登入、清除失效的授權快取，通常比直接刪除整個使用者設定更安全。若 IDE 提供獨立的 HTTP Proxy 選單，請選擇「使用系統代理」或填入目前 Clash 的正確埠號，但不要同時讓它指向舊 VPN 代理。完成修改後，重新啟動 IDE，因為部分網路設定只在程序啟動時讀取。
- 確認核心：查看 Clash 是否有有效設定檔、策略組與正在監聽的代理埠。
- 隔離模式：短暫使用全域模式測試，判斷是否為規則命中問題。
- 查看日誌：在一次登入或補全操作中記錄主機、規則、策略組與錯誤階段。
- 固定節點：選一個穩定節點建立專用策略組，避免自動切換干擾判斷。
- 檢查 IDE：確認外掛啟用、代理來源一致，並重新載入或登入。
- 逐項回復：先恢復規則模式，再測試 TUN、DNS 或自動選節點，保留有效變更。
如果公司、學校或安全軟體攔截了未知的 IDE 網路連線，Clash 規則再正確也無法替代本機授權。請檢查防火牆是否允許 IDE 與外掛程序建立出站連線，並留意 TLS 檢查、端點防護或強制 PAC 是否改寫了代理路徑。涉及企業帳戶時，也要確認組織政策是否允許 GitHub Copilot，以及帳戶授權是否已通過；不要把政策拒絕、帳戶權限不足誤判成節點逾時。
相較於只提供單一系統代理開關的簡易 VPN，Clash Verge、Clash Verge Rev 或其他 Mihomo 客戶端能透過規則、連線日誌、策略組與 TUN 模式，把 GitHub Copilot 的登入鏈和補全鏈分開觀察；但某些舊式客戶端介面簡化了日誌與 DNS 控制，遇到 IDE 長連線時往往只能反覆重連。若你希望把本文的排障流程落實為可保存的設定、清楚的節點切換與跨應用程式代理管理，Clash V.CORE 會提供更完整的核心能力與持續更新的使用體驗；確認自己的系統與服務需求後，可前往下載頁取得適合的平台版本。