Clash 開發環境代理規則實戰：改善 GitHub、npm 與 Docker 連線逾時

先分清問題在哪一層：代理、工具設定與網域規則

GitHub、npm 或 Docker 連線逾時，不一定是「Clash 沒有代理」。終端工具可能沒有讀取 macOS 系統代理；工具雖然連上本機代理，規則也可能將流量送到直連；即使選中代理策略，節點、DNS 或遠端服務仍可能無法完成連線。排查時應先確認工具是否把請求交給 Clash，再確認命中的規則、策略與實際出口。

Clash 常見圖形用戶端通常以 mihomo 或相容核心處理規則，但不同版本對設定覆寫、規則集格式和 TUN 的支援可能不同。以下以 mihomo 常見的 YAML 寫法示範；套用前請確認目前用戶端的核心版本支援 rule-providers、behavior 與 format 欄位。若使用的是舊核心，先用內嵌 rules 驗證，再參考該核心版本文件調整。

請求未進入 Clash：檢查終端環境變數、npm 設定或 Docker Desktop 的代理設定；系統代理開啟不代表每個命令列程式都會採用它。
請求進入 Clash，但走錯出口：查看連線記錄中的網域、匹配規則與策略群組，確認它沒有命中較前面的 DIRECT 或其他規則。
規則與出口正確仍逾時：檢查代理節點連通性、DNS 解析、TLS 錯誤與服務端狀態；更改規則不能修復無效節點或失效憑證。

整理 GitHub、npm 與 Docker Hub 的實際網域

分流規則應按網域而非按「開發工具」名稱建立：同一個工具可能連到多個服務，且服務端可能使用 CDN 或物件儲存網域。GitHub 的程式碼頁、原始檔與大型下載不一定由同一個網域提供；npm 安裝套件時可能連到套件登錄站，也可能因相依套件來源而連到程式碼代管平台；Docker 拉取映像檔則可能依序連線至認證服務、Registry 和映像層儲存端點。

GitHub：可先觀察 github.com、githubusercontent.com、githubassets.com 及 codeload.github.com。實際下載流程若仍逾時，請以連線記錄顯示的完整網域補充，不要直接把所有未知網域都改走代理。
npm：常見套件登錄網域為 registry.npmjs.org。若套件來自程式碼代管平台，還可能需要相應的原始碼或封存下載網域；先用單一套件重現並查看記錄。
Docker Hub：可先觀察 auth.docker.io 與 registry-1.docker.io。映像層下載可能轉往其他 CDN 或儲存網域，應根據實際連線記錄逐項處理，避免用過寬的規則誤代理不相關流量。

網域後綴規則通常會涵蓋該網域及其子網域。例如 DOMAIN-SUFFIX,github.com 可匹配 github.com 和 api.github.com；若只希望匹配一個確切主機，使用 DOMAIN。規則依序比對，較具體的例外應放在較廣泛的規則之前，否則前面已經匹配的規則會先決定策略。

rules:
  - DOMAIN,registry.npmjs.org,開發代理
  - DOMAIN,auth.docker.io,開發代理
  - DOMAIN,registry-1.docker.io,開發代理
  - DOMAIN-SUFFIX,github.com,開發代理
  - DOMAIN-SUFFIX,githubusercontent.com,開發代理
  - DOMAIN-SUFFIX,githubassets.com,開發代理
  - DOMAIN-SUFFIX,codeload.github.com,開發代理
  - MATCH,原有預設策略

這段是規則示例，不是可直接取代訂閱的完整 YAML。開發代理與原有預設策略必須替換成設定中已存在的策略群組名稱；若群組名稱包含冒號、逗號等特殊字元，請依 YAML 字串規則加上引號。也要保留原本的其他規則與最後的兜底規則，避免意外改變所有未匹配流量的出口。

使用 rule-providers 管理規則集，避免主設定愈加愈長

自訂的少量網域可直接寫在 rules；清單較長或需要分開更新時，則可使用 rule-providers。規則提供器保存規則資料，主設定再以 RULE-SET 引用。它和 proxy-providers 不同：前者提供網域或 IP 規則，後者提供代理節點；更新規則提供器不會替你更新整份訂閱，也不會自動建立代理策略群組。

以下示範 HTTP 規則提供器的結構。rules.example.net 是文件用途的佔位網域，並非可直接使用的規則服務；請改成你自行維護、可由裝置取得的 HTTPS 規則檔網址。規則來源若放在目前正要排查的服務上，連線故障時便可能連規則檔也無法更新。可改用穩定且受信任的來源，或先採用內嵌規則確認分流邏輯。

rule-providers:
  dev-github:
    type: http
    behavior: domain
    format: yaml
    url: "https://rules.example.net/dev/github.yaml"
    path: ./ruleset/dev-github.yaml
    interval: 86400

  dev-package:
    type: http
    behavior: domain
    format: yaml
    url: "https://rules.example.net/dev/packages.yaml"
    path: ./ruleset/dev-package.yaml
    interval: 86400

rules:
  - RULE-SET,dev-github,開發代理
  - RULE-SET,dev-package,開發代理
  - MATCH,原有預設策略

使用 behavior: domain 和 format: yaml 時，規則檔可採用以下結構。每個網域各占一行；避免在清單內加入完整網址、路徑或埠號，因為這些不是網域規則的匹配範圍。

payload:
  - "+.github.com"
  - "+.githubusercontent.com"
  - "+.githubassets.com"
  - "+.codeload.github.com"

type: http：從設定的網址取得規則檔。檢查網址能否在目前網路環境下載，並確認回應不是登入頁、HTML 錯誤頁或空檔案。
path：指定核心儲存下載內容的位置。實際可寫入位置會受到用戶端與核心執行環境限制；若載入錯誤與檔案權限有關，請查看核心日誌及用戶端的設定目錄。
interval: 86400：表示按秒設定更新間隔，這裡是 24 小時。它不是載入成功的保證；更新失敗時仍應檢查記錄與檔案內容。
RULE-SET：引用上方提供器名稱，名稱必須完全一致。規則中的策略群組也必須存在，且要安排在會提前匹配的廣泛規則之前。

動手操作：從最小規則開始測試終端工具

實作時先用少量內嵌規則排除提供器下載和 YAML 檔案兩個變因。以下步驟以本機混合代理埠 7890 為例；請先在 Clash 用戶端確認實際埠號，若設定為其他數值，將指令中的埠號一併替換。混合埠通常同時接受 HTTP 與 SOCKS 請求，但各核心和用戶端設定可能不同。

備份並確認策略群組：複製目前設定或匯出設定檔，確認存在一個可用的代理策略群組。先在用戶端選定可連線的節點，測試一般網站，再把該群組名稱填入規則。
加入少量規則：先只加入正在測試的服務網域，並放在預設規則之前。檢查縮排與群組名稱，套用設定後確認核心沒有 YAML 或未知規則錯誤。
明確設定終端代理：為目前終端工作階段設定環境變數，測試結束後可關閉終端或清除變數。這有助於區分「命令列工具沒用代理」和「Clash 規則走錯策略」。
逐項測試並查看連線記錄：每次只測一個服務，記錄命中的網域、規則、策略群組及連線結果。確認可用後，再擴充網域或改用規則提供器。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://github.com
npm ping --registry=https://registry.npmjs.org
docker pull hello-world

HTTPS_PROXY 的值常以 http:// 指向本機 HTTP 代理，HTTPS 請求再透過 CONNECT 建立隧道；不要只因目標網址是 HTTPS，就把本機代理地址改寫成 https://。若混合埠不接受 SOCKS，移除 ALL_PROXY 或改用用戶端實際設定的 SOCKS 埠。不同工具對環境變數的優先順序也可能不同，因此測試結果應與連線記錄一併判讀。

Docker Desktop 的映像拉取由 Docker 引擎處理，未必會沿用目前終端的環境變數。若 docker pull 仍逾時，但 curl 和 npm ping 已經命中預期規則，請檢查 Docker Desktop 的代理設定及引擎日誌，而不要立刻擴大 Clash 網域規則。反過來說，若日誌顯示 Docker 網域命中 DIRECT，則應先修正規則順序或策略引用。

# 僅清除目前終端工作階段設定的代理變數
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY http_proxy https_proxy all_proxy

# 檢查 npm 目前的代理設定
npm config get proxy
npm config get https-proxy

依日誌定位逾時原因，並控制規則集維護範圍

連線記錄是確認分流是否生效的主要依據。用戶端介面通常有「連線」、「日誌」或「Logs」頁面，名稱會隨版本不同。開始測試後，依序查看請求網域、匹配的規則類型、策略群組、所選節點及錯誤訊息。若連線清單完全沒有該請求，先查工具是否使用代理或是否需要啟用 TUN；若有請求但策略不符，檢查規則順序；若策略正確卻連線逾時，再測節點和 DNS。

顯示 MATCH 或預設規則：自訂網域沒有匹配，可能是漏列實際使用的主機、規則提供器未更新，或該請求未被 Clash 接管。以記錄中的主機名補充精確規則。
顯示 DIRECT：前方可能有較廣泛的直連規則，也可能規則引用了錯誤群組。將特定開發網域規則移到相關廣泛規則之前，再重新載入設定。
顯示代理群組，但仍逾時：確認群組目前選取的節點，不要只看群組名稱。測試節點健康狀態，並檢查認證失敗、TLS 握手錯誤或 DNS 解析異常。
只有 Docker 拉取失敗：Docker 引擎可能有自己的代理環境，或映像層下載使用了尚未列入規則的主機。以引擎日誌和 Clash 連線記錄確認，不要假設 shell 代理變數會自動傳遞。

確認少量規則運作正常後，再將穩定且經常需要的網域整理成規則提供器。每次更新前後都應檢查規則檔格式、下載狀態及命中結果；新增例外時記錄用途與日期，避免多年後無法判斷某條規則為何存在。若規則集更新後突然出現直連或逾時，先回復前一份規則檔，再逐項比對變更。

維護時遵循「最小可用範圍」：只代理確實需要的網域，不用全域代理代替診斷；不要為了讓一個套件成功安裝，就把所有連線都設為代理。定期確認用戶端版本、核心版本與規則來源仍受支援，並保留可回復的設定副本。若在支援討論中分享日誌，先遮蔽內網位址、節點名稱、訂閱網址、代理憑證與可能包含的存取權杖。