GitHub 連線逾時不一定是節點壞掉

使用 Clash 開啟 GitHub 時，如果瀏覽器長時間顯示「無法連線」、git clone 卡在 Receiving objects，或從 Release 頁面下載檔案時反覆出現 connection timed out，先不要直接判定代理節點失效。GitHub 的網路請求通常不只涉及一個主機：網頁介面可能連到 github.com，登入與 API 會使用 api.github.com，圖片、腳本與部分資源可能來自 githubassets.com，Release 下載則常會跳轉到物件儲存或 CDN 網域。只要其中一個網域被錯誤分流，整個操作就可能看起來像 GitHub 完全無法使用。

這類問題最常見的根因，大致可分成四層。第一層是代理本身，例如節點已過期、出口延遲過高、TLS 握手不穩定，或策略群組目前選到不可用的伺服器。第二層是Clash 規則，例如 GitHub 主站走代理，但 api.github.com 或下載跳轉網域被 DIRECT 接手。第三層是DNS，本機解析到不可達的 IP、DNS 被其他 VPN 改寫，或 Fake-IP 與某些程式的連線方式互相衝突。第四層則是應用程式沒有真正使用 Clash：瀏覽器讀取系統 Proxy，不代表 Git、SSH、Docker 或 IDE 內嵌終端也會自動讀取同一設定。

因此，排查時要先回答三個問題：目前請求有沒有出現在 Clash 的連線紀錄？它套用了哪一條規則與哪個策略？發生錯誤的程式是否真的經過系統 Proxy 或 TUN？只有按照這個順序逐層縮小範圍，才能避免不斷換節點，卻沒有處理真正的分流衝突。

先依症狀分辨：網頁、Git 與下載可能是不同問題

同樣是「GitHub 連不上」，不同操作所經過的網路路徑並不完全相同。建議先用瀏覽器、Git HTTPS、Git SSH 與 Release 下載各做一次測試，並記下失敗發生在哪個階段。下面的對照表可用來建立初步方向；它不是絕對規則，但能幫你避免把所有故障都歸咎於同一個節點。

症狀 優先檢查項目 常見原因
github.com 完全打不開 Clash 連線紀錄、系統 Proxy、節點可用性 請求直連失敗、代理未啟用或節點無法完成 TLS
網頁能開，但 API 或登入卡住 api.github.com 與相關登入網域 子網域被 DIRECT、規則順序被後續 GEOIP 規則覆蓋
git clone HTTPS 逾時 Git 的 http.proxy、Shell 環境變數 Git 沒有繼承系統 Proxy，或使用了過期的本機埠
SSH clone 卡在連線階段 github.com:22、SSH ProxyCommand TCP 22 被網路封鎖，且 SSH 沒有走 Clash 的代理轉接
Release 頁面正常，資產下載失敗 重新導向後的實際網域 CDN 或物件儲存網域沒有加入適當分流，或大檔長連線不穩
偶爾成功、偶爾逾時 策略群組、DNS 模式、節點延遲與丟包 自動選擇到不穩定節點，或不同 IP 的可達性差異很大

如果瀏覽器與 Git 同時失敗，先處理 Clash 核心、系統 Proxy 與節點；如果只有 Git 失敗，則不要急著修改整份訂閱規則，應先確認 Git 使用的是 HTTPS 還是 SSH，以及目前終端機是否讀到了正確的代理位址。

動手排查：從連線紀錄到 DNS 逐項驗證

以下流程適用於 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX，以及使用 Mihomo 核心的其他圖形客戶端。不同版本的選單名稱可能略有差異，但你要找的功能通常包括「連線」「日誌」「設定檔」「系統 Proxy」「TUN」與 DNS 設定。

  1. 先確認 Clash 核心真的在運作。

    打開客戶端的連線或日誌頁面，確認核心狀態是執行中，並查看目前使用的設定檔是否為已啟用版本。若介面裡同時存在遠端訂閱、本機 YAML 與合併後設定，請以標示為目前生效的組態為準。接著確認 mixed port 或 HTTP port 的數字，因為 Git 的環境變數若仍指向舊埠，後續所有測試都會得到誤導性的失敗結果。

  2. 用瀏覽器測試主站，再觀察連線紀錄。

    開啟 https://github.com，同時在 Clash 連線列表搜尋 github。理想情況下，你應看到目的地、規則名稱、策略群組與實際節點。如果完全沒有任何 GitHub 請求，通常表示系統 Proxy 沒有開啟、瀏覽器使用了自己的代理設定，或請求被其他 VPN／安全軟體接管。若看得到請求但策略是 DIRECT，則問題集中在規則順序與策略選擇，而不是單純的節點品質。

  3. 把 GitHub 相關網域放在明確規則之前。

    在自訂規則或覆寫規則中，可先針對主要網域建立清楚的分流。策略名稱請替換成你設定檔內實際存在的代理群組，不能直接照抄不存在的名稱。

    rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,githubassets.com,PROXY
  - DOMAIN,api.github.com,PROXY
  - MATCH,DIRECT

    規則順序非常重要。若上方已有較寬泛的 GEOIP、DOMAIN-SET 或其他規則，GitHub 專用規則必須放在能提前命中的位置。修改後重新載入設定檔，再清除舊連線並重試，不要只切換策略群組卻保留原本的連線狀態。

  4. 確認 Git HTTPS 是否使用同一個代理。

    Git 不一定會跟隨作業系統的 Proxy。你可以先查看目前設定：

    git config --global --get http.proxy
git config --global --get https.proxy

    若需要以本機 HTTP 代理測試，可暫時設定與 Clash mixed port 相同的位址。以下僅示範格式，埠號請依你的客戶端實際設定替換：

    git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

    測試完成後，若你不希望所有 Git 專案永久共用該代理，也可以移除全域設定，改用單次指令或專案層級設定。特別要注意，若命令列報告連線到 127.0.0.1:7890 被拒絕，這通常表示埠號錯誤或 Clash 沒有監聽該介面，不代表 GitHub 本身拒絕你的連線。

  5. 分開檢查 SSH 與 HTTPS。

    很多人看到「GitHub clone 失敗」就反覆測試同一條 SSH 指令，但 SSH 使用 TCP 22，並不會自動讀取 HTTP Proxy。若你的網路環境不允許直連 22，HTTPS clone 往往更容易先完成驗證；若專案必須使用 SSH，則要依 SSH 客戶端支援方式設定 ProxyCommand 或透過本機 SOCKS 端口轉接。不要把 https.proxy 的設定誤認為可以代理所有 SSH 連線。

  6. 最後才處理 DNS 與 TUN。

    如果連線紀錄顯示請求已進入 Clash、規則也命中代理，但仍然間歇性逾時，可再比較系統 DNS、Clash DNS 與 TUN 模式的差異。先關閉其他 VPN，避免兩套虛擬網卡同時修改路由；再重新啟用 Clash 的 DNS 功能或切換到另一種解析模式做 A／B 測試。TUN 適合用來驗證那些不讀系統 Proxy 的程式，但它也可能與公司零信任軟體、校園 VPN、Docker 網路或本機防火牆衝突，因此不建議把「開 TUN」當成所有問題的固定解法。

小提示：每次只改一個變數，並記錄「節點、規則、DNS 模式、程式與錯誤訊息」。例如先固定節點，只切換 DIRECT 與 PROXY；再固定規則，只更換節點。這樣才能判斷故障究竟來自出口品質、路由決策，還是應用程式代理設定。

仍然逾時時：節點、長連線與安全設定的進一步判斷

完成基本分流後，如果 GitHub 網頁已可正常開啟，但大檔下載或複製大型儲存庫仍會失敗，問題可能轉移到長連線穩定性。部分節點在小型 HTTPS 請求上表現正常，遇到數百 MB 的 Release 資產、Git packfile 或長時間保持的 API 連線時，卻會出現吞吐下降、重傳增加或連線被中途重置。這時應先在同一策略群組中手動切換兩至三個節點，觀察 GitHub 連線紀錄的延遲與斷線時間，而不是立刻調整大量核心參數。

若只有某個儲存庫失敗，先檢查遠端 URL、權限與憑證。私人儲存庫需要有效的帳號授權或 Personal Access Token；代理正常只能代表封包送達，不能代替 GitHub 的身分驗證。若錯誤訊息是 403、401 或 repository not found，方向應放在權限與遠端位址，不要繼續更換節點。相反地，Could not resolve host 比較接近 DNS 或本機解析問題，而 Failed to connect、Operation timed out 則需要回到路由、端口與出口連通性。

另外，請避免為了「讓 GitHub 一定走代理」而刪除所有安全規則、關閉憑證驗證，或在不理解用途的情況下加入全域 allow-lan。這些設定與 GitHub 逾時沒有直接等號關係，卻可能把本機代理暴露給區域網路，或讓中間人攻擊更難被發現。可靠的排錯方式是保留 TLS 憑證驗證、只開啟必要的代理介面，並以連線紀錄與單一命令測試來確認每一層是否正常。

從實務角度看，Clash 的優勢不只是「把所有流量送出去」，而是可以把 GitHub 主站、API、資產下載與其他服務分開觀察，讓你知道哪個目的地命中了哪條規則；相較於只提供一個總開關的簡單代理工具，後者常在網頁偶爾能開、Git 卻無法 clone 時缺少可追蹤資訊，也較難處理 DNS、SSH 與 TUN 之間的差異。如果你希望依本文流程檢查規則、系統代理與節點狀態，使用具備連線紀錄與分流控制的 Clash 用戶端會更容易把問題定位清楚。

立即免費下載 Clash，開啟流暢上網新體驗 →