GitHub clone 或 Actions 總逾時？2026 年以 Clash 分流儲存庫與 CDN 實測步驟

為什麼「網頁能打開 GitHub」，clone 或 Actions 仍容易卡住？

搜尋GitHub clone 逾時或GitHub Actions 失敗的人，多半已經不是「完全不能連線」，而是遇到長時間無回應、斷在物件下載、或 API 速率相關錯誤這類斷續問題。與單一網頁請求相比，git與 Actions 會在背景對多個主機名建立連線：從 HTML 與 REST API、到 LFS 與 release 資產、再到raw.githubusercontent.com這類靜態原始檔路徑。若你的Clash 分流只在github.com一條規則上生效，其他子網域卻被寬鬆的GEOIP或下載清單提前命中，就會出現「首頁載入正常、克隆拉到一半停住」的典型現象。

另一個常見誤區是以為開了瀏覽器擴充套件或系統 Proxy，終端機就自動跟著走。實務上，shell 內的git會讀取環境變數、git config --global http.proxy、以及 SSH 透過 jump 的不同路徑；IDE 內嵌終端機又可能繼承另一套設定。只要任一環節繞過 Clash 或走錯策略，整條鏈路的穩定度就會被最弱的一段拉低。若你才剛匯入訂閱，建議先完成 訂閱匯入教學，避免proxy-groups名稱與規則不一致造成載入失敗，再回來細修本文的Clash 規則。

合規提示：Clash／Mihomo 為本機轉送與規則工具，不提供第三方節點。請在法令與所屬組織政策允許的範圍內設定；企業環境應優先遵循資訊安全與稽核要求，而非將敏感儲存庫流量繞過公司閘道。

GitHub 相關流量大致分成哪幾類？

撰寫DOMAIN-SUFFIX或細粒度DOMAIN規則前，先把「誰在跟誰講話」拆開，日後對照連線紀錄才不會只靠關鍵字猜測。

網頁、GraphQL 與 REST API

瀏覽器存取倉庫首頁、Issues、Pull Request 介面時，除了github.com本體，還經常觸發api.github.com與相關子網域的 JSON 請求。若 API 端點被誤判為應直連而實際線路不穩，畫面可能局部載入失敗；在 Actions 或gh CLI 場景則會直接以錯誤碼結束。

Git 智慧 HTTP、SSH 與後端承載

HTTPS clone 預設會與 GitHub 的 git 承載主機協商；大檔案或淺克隆若走錯路由，容易在傳輸層出現重試。SSH則連到ssh.github.com（或你自訂的替代位址），路徑與 HTTPS 完全不同，需要在連線紀錄分開確認是否命中預期策略。

raw 與 githubusercontent 家族

教學腳本、相依清單安裝、或 CI 內curl某個分支上的檔案時，常會命中raw.githubusercontent.com。這類主機與一般 HTML 入口分流邏輯不同；若只放行github.com而沒有覆蓋githubusercontent.com下屬網域，就容易在「下載安裝腳本」這一步逾時——這也是許多使用者會單獨搜尋raw.githubusercontent.com分流的原因。

Release、LFS 與大型物件

Release 資產與部分附件可能落在物件儲存或 CDN 名稱之後；Git LFS還會再拆出一條批次物件請求鏈路。若你只看到「clone 基本歷史成功、checkout 某支提交失敗」，很可能卡在 LFS 或子模組所指向的網域，而不是主倉庫 HTML 主機。

GitHub Actions 與本機差在哪裡？

GitHub 託管的 Runner執行在供應商網路內，無法在該 VM 上安裝你的 Clash 用戶端來「本機分流」。若工作流程在託管 Runner 上逾時，通常要從動作設計（快取、並行、重試、避免巨型單次 checkout）、或該平台的暫時性網路限制來排查。

自架 Runner則與開發機類似：只要組織允許，你可以在 Runner 宿主或閘道上部署 Mihomo／Clash，並讓git與建立連線的步驟走同一出口。關鍵是systemd 服務帳號是否繼承http_proxy、是否啟用 TUN 覆蓋該行程、以及 Docker 內建的 job 是否又繞過宿主規則。若工作流程會在容器內拉 original image，請一併對照 Docker Desktop 分流專文，把「宿主 Runner」與「job 容器」兩層視角分開除錯。

規則順序：為什麼貼了 YAML 仍像沒命中？

在mode: Rule下，rules自上而下匹配，命中即停止。若巨大的 RULE-SET 或 GEOIP 出現在你想微調的 GitHub 細節之前，後面補上的 DOMAIN 規則永遠輪不到比對。整體骨架可對照 規則分流深度文；本文只聚焦「開發者與 Git」這一段應插在什麼位置。若你啟用 TUN 模式，請確認逾時發生時連線紀錄裡策略欄位實際顯示為何，避免把問題一概歸咎於節點品質。

教學用規則骨架（請替換群組名並依日誌精修）

下列片段為骨架示意：proxy-groups須改成你訂閱內真實存在的節點名稱；rules頂段請放在任何會提早結束比對的規則集之前。實際環境裡若還需要ghcr.io（Container registry）或公司 SSO 網域，請用連線紀錄再補，勿盲目DOMAIN-KEYWORD,github拉太寬。

YAMLproxy-groups:
  - name: "GITHUB_DEV_PROXY"
    type: select
    proxies:
      - "GITHUB_LOW_LATENCY"
      - "Your-Node-SJC"
      - DIRECT
  - name: "GITHUB_LOW_LATENCY"
    type: url-test
    proxies:
      # paste from subscription
    url: "https://api.github.com/zen"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # prepend before broad GEOIP / RULE-SET
  - DOMAIN-SUFFIX,github.com,GITHUB_DEV_PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB_DEV_PROXY
  - DOMAIN-SUFFIX,githubassets.com,GITHUB_DEV_PROXY
  - DOMAIN-SUFFIX,github.io,GITHUB_DEV_PROXY
  # optional registry / API variants observed in logs
  # - DOMAIN,ghcr.io,GITHUB_DEV_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

粒度提醒：若日誌出現企業內部鏡像、私有 Git 主機、或與 GitHub 無關的下載網域，請分開策略群組，不要將GITHUB_DEV_PROXY擴張成「所有開發站都同一桶」，以免除錯困難與法遵風險。

實測步驟：建議依序做一次

  1. 在本機或 Runner 上執行最小復現：例如淺克隆單一分支、或只跑會觸發actions/checkout與依賴安裝的工作流量，並暫停其他併發下載。
  2. 打開 Clash／Mihomo 的連線紀錄，記錄git clone或 workflow 期間出現的完整主機名與命中的規則／策略名稱。
  3. 將涉及api.github.com、raw.githubusercontent.com、LFS、release CDN 的主機，逐條對照骨架中的DOMAIN-SUFFIX是否已置前覆蓋；未涵蓋者以日誌為準補上。
  4. 在GITHUB_DEV_PROXY內用select暫時鎖定單一節點，排除「自動測速頻繁切線」造成的假性逾時；若鎖線後仍失敗，轉查 DNS、MTU、或上游 API 節流訊息。
  5. 清理 shell 與 git 的全域 Proxy 殘值（http.proxy、HTTPS_PROXY、NO_PROXY），確認與 TUN／mixed-port 的設計一致後再重試完整 clone 或 workflow。

對照徵兆：你可以先粗分問題落在哪一段

  • 倉庫歷史能下、大型檔案失敗：優先檢視 LFS 與 release 網域是否在日誌裡走了 DIRECT 或錯誤群組。
  • 腳本安裝卡在 curl bash：對齊是否命中raw.githubusercontent.com子網域，而非僅github.com。
  • CLI 或 Actions 報 API 相關錯誤：把api.github.com與 GraphQL 端點獨立拉出來對照節流與認證，而不是只調整瀏覽器用戶端。
  • 僅 SSH 失敗、HTTPS 正常：檢查ssh.github.com連線與金鑰流程，規則上與 HTTPS 分開處理。

常見問題

我已經把 GitHub 填進規則，為什麼還是逾時？多數情況是規則順序或子網域未覆蓋：請用連線紀錄確認實際主機名，而不是只檢查設定檔裡是否出現字串「github」。

能不能乾脆整段 MATCH 全部走代理？可以，但會失去細分國內鏡像與內網直連的能力，也可能讓不相關流量過度集中同一節點；實務上仍以「日誌驅動的置前規則」較可維護。

與 npm、Docker 分流文有什麼關係？同一台機器常同時需要拉 npm tarball、Docker image、與 GitHub 原始碼；可平行閱讀本站 npm 逾時分流等文章，把不同生態的主機名集合分別維護在註解區塊中，避免互相覆寫。

結語

2026 年軟體交付高度依賴 Git 與託管平台上游；與其只在社群收集「換 DNS」或「多試幾次」這類口訣，不如先把GitHub clone 逾時與GitHub Actions 失敗還原成可觀測的主機名與策略命中，再用 Clash／Mihomo 把github.com、raw.githubusercontent.com與 API／CDN 鏈路收斂到可切換的開發者群組。當規則順序、TUN 或系統 Proxy、以及環境變數彼此對齊後，多數情境可以在不更動業務程式的前提下顯著降低長尾逾時。

市面上不少通用加速器或單一 VPN 方案較難細分終端實際連到的子網域，也不便與團隊共享可稽核的 YAML，在本機與自架 Runner 並存時往往要反覆試誤。ClashSource延續本站 npm、Docker、MCP 等主題的寫法，把Clash 規則與連線紀錄對照流程寫在同一套脈絡下，利於你依據真實日誌擴充而不破壞整體架構。若你正在整理長期可用的開發網路設定，不妨在合規前提下 免費下載 ClashSource，再依 教學文件把規則固化成團隊可以審閱的版本。