為什麼瀏覽器能連線，Git、npm 和 Docker 卻還是逾時
在電腦上開啟 Clash 後，瀏覽器可能已能正常連線，但終端機裡的 Git、npm、pip 或 Docker 仍會出現逾時、TLS 錯誤，甚至卡在下載進度不動。這通常不是單一工具故障，而是不同程式使用代理的方式不同：瀏覽器可能讀取系統 Proxy 或擴充套件設定，終端程式則可能依賴環境變數、自己的設定檔，或完全不使用系統代理。
因此，處理工程師的終端機代理問題時，先分清楚兩件事會比較有效率：第一，流量有沒有進入 Clash；第二，進入 Clash 後，目的網域套用的是哪條規則、哪個策略群組。環境變數是告訴支援它的程式「本機代理入口在哪裡」，規則分流則是決定連線進入核心後要走代理或直連。若前者未設定，規則再完整也收不到請求；若前者設定正確但規則判定為 DIRECT，請求仍可能直接連出。
本文以常見的 Clash Verge Rev／Mihomo 使用方式為例，整理一套從本機埠號、Shell 變數到 Git、npm、pip 和 Docker 的檢查流程。各版本介面名稱可能不同，請以目前核心實際監聽的 HTTP 或 mixed-port 為準；常見的 7890 只是示例，不代表每台電腦都使用相同埠號。
先選路徑：系統 Proxy、環境變數，還是 TUN
排錯時不建議一開始就同時開啟多種代理方式。先確認 Clash 的核心正在運作，再查看設定中 HTTP、SOCKS 或 mixed-port 的實際值；接著選擇一條清楚、可觀察的流量路徑。對一般開發工作站而言，系統 Proxy 配合終端環境變數通常較容易理解；當某個程式不理會這些設定，才考慮以 TUN 補上系統層的接管。
- 系統 Proxy：適合會讀取作業系統代理設定的圖形程式與部分終端工具。它不保證每個 CLI、背景服務或子行程都會自動使用代理。
- 環境變數：適合明確支援 HTTP 代理變數的工具。優點是可在單一終端工作階段測試，缺點是不同 Shell、IDE、CI 工作程序可能不會繼承同一組變數。
- TUN 模式：可在更低的網路層處理部分沒有讀取代理變數的流量，適合用來驗證程式是否繞過應用層設定。它會影響更廣泛的系統流量，可能與公司 VPN、虛擬機器網路或容器網路互相影響。
建議先使用規則模式與系統 Proxy，確認請求是否出現在 Clash 的連線紀錄，再逐一測試終端變數。若某個工具確實沒有使用 HTTP Proxy 的能力，且連線紀錄也完全看不到它的目的地，才短時間開啟 TUN 做對照。這種逐層驗證的方式，能避免把埠號錯誤、網域規則錯誤和路由衝突混成同一個問題。
使用公司或學校設備時，請先確認代理與 VPN 符合組織網路政策。TUN 可能改變 DNS 與路由行為；若裝置已有零信任用戶端或企業 VPN，應先了解管理規範，不要為了測試而停用安全元件或修改受管理設定。
設定終端機代理變數，並先驗證入口
在 Unix 類 Shell 中，可先於目前終端機視窗設定 HTTP 與 HTTPS 代理。下例使用 127.0.0.1:7890，請將埠號改成 Clash 實際監聽的 HTTP 或 mixed-port。使用本機迴圈位址可避免把代理服務不必要地暴露到區域網路。
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5h://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"HTTPS_PROXY 的值通常仍是以 http:// 開頭，因為它表示先連到 HTTP 代理，再透過 CONNECT 建立 HTTPS 通道；不要只因目的網站是 HTTPS，就自行把代理入口改成 https://。ALL_PROXY 常用於支援 SOCKS 的程式，並非所有工具都會讀取它。使用 socks5h 時，網域解析也會交由代理端處理；若核心或工具不支援這種寫法，可改用已確認可用的 HTTP 代理方式。
在 Windows PowerShell 中，可以用下列方式為目前視窗設定變數；關閉視窗後，這些值不會自動保留：
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5h://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"先用一個簡單請求確認入口，不要立即執行大型套件安裝或完整 Docker 建置。若你的 curl 版本支援代理環境變數，可執行 curl -I https://example.com；也可在命令中明確指定 --proxy http://127.0.0.1:7890，把「環境變數未載入」和「代理本身不可用」分開測試。觀察回應時，重點不是一定要得到特定 HTTP 狀態碼，而是確認連線能完成，且 Clash 連線紀錄中看得到相應網域。
環境變數只對啟動它們的程序及其子行程生效。若你在 IDE 開啟前沒有設定變數，IDE 內建終端可能繼承不到後來才在另一個視窗設定的值；反過來說，在終端設定變數，也不一定會影響已經開啟的圖形程式。遇到這種狀況，請重新啟動相關程式，並在同一個終端確認變數確實存在，而不是只檢查 Shell 設定檔內容。
讓 Git、npm 和 pip 使用一致的代理設定
終端變數可作為快速測試，但每種工具仍有自己的行為與設定入口。實務上應先選定一種主要管理方式，避免全域 Git 設定、Shell 變數和專案設定彼此覆蓋，最後無法判斷請求從哪個位置取得代理位址。
Git：檢查遠端位址與獨立代理設定
Git 的 HTTP／HTTPS 傳輸通常能使用代理環境變數，但也可能存在先前留下的獨立設定。若只有 Git 失敗，先查看遠端網址是不是 HTTPS，再檢查目前套用的設定來源：
git remote -v
git config --show-origin --get-regexp 'http\..*proxy|http.proxy'如果要進行短期測試，可先在目前終端設定代理變數；若希望 Git 長期使用明確的 HTTP 代理，也能透過 git config 設定。請先確認現有值及其來源，再決定是否修改全域設定。排錯完成後，移除不再需要的值，避免日後 Clash 埠號改變時 Git 仍指向舊入口。若 Git 連線紀錄顯示目的地已進入核心但選到 DIRECT，應回頭檢查對應網域的規則，而不是反覆更換 Git 憑證。
npm：檢查設定檔、登錄站與套件來源
npm 可讀取相關代理變數，也有自己的 proxy 與 https-proxy 設定。執行 npm config get proxy 和 npm config get https-proxy，確認是否殘留舊代理；另外可用 npm config get registry 查看目前使用的套件登錄站。不同套件可能來自不同 registry 或 tarball 主機，因此不能只確認首頁域名就認定下載路徑都已涵蓋。
若變更過 npm 設定，請在小型測試專案執行一次套件查詢或安裝，並同時觀察 Clash 連線紀錄。若只有特定套件下載失敗，先查看錯誤訊息中的實際主機名稱，以及 lockfile 或套件中是否指定了其他下載來源。不要把包含帳號、權杖或公司私有 registry 認證的設定檔貼到公開討論區；npm 設定檔可能含有敏感資訊。
pip：驗證套件索引與依賴下載來源
pip 通常能透過 HTTP 代理環境變數連線，也可在單次命令中使用 --proxy 進行隔離測試。若索引頁面可達，但實際安裝套件時中斷，請查看完整錯誤內容中的主機名稱；安裝流程可能還會連到檔案託管服務或自訂索引。確認這些目的地後，再依實際需求調整 Clash 規則，而不是一開始就把所有流量切換到全域模式。
對 Python 虛擬環境而言，代理變數一般由啟動該環境的終端繼承，但 CI、IDE 或背景工作程序可能有不同的環境。可以先在同一個 Shell 執行 python -m pip --version 確認使用的是預期的 Python，再用一次小型套件查詢測試連線。若直連網路已可用，不要為了「看起來一致」而強制套用代理；內部索引與私人服務通常應採用符合團隊政策的連線方式。
Docker 的代理分兩層：主機、建置程序與容器
Docker 是最容易讓人誤以為「終端代理已設好，所有東西就會一起走」的工具。實際上至少要分開看三個位置：Docker CLI 所在的主機程序、Docker Engine 或 Docker Desktop 背後的守護程序，以及執行中的容器。主機 Shell 的環境變數不會自動保證守護程序、映像建置步驟和容器內的應用程式都使用相同代理。
- 映像拉取：由 Docker Engine 或 Docker Desktop 背後的服務連接映像倉庫；若錯誤發生在
docker pull，先檢查引擎自身的網路與 Proxy 設定，而不是只修改目前終端的變數。 - 映像建置：Dockerfile 內的套件安裝命令可能需要代理。可依 Docker 與建置環境支援方式傳入建置參數，並確認該值只在需要的階段使用，不要將帳密直接寫入映像層或提交到版本控制。
- 容器執行：容器中的應用程式若要使用主機代理，必須能連到容器網路可達的代理位址。容器內的
127.0.0.1指向容器本身，不是宿主機；Docker Desktop 與 Linux 原生 Docker 的主機連線方式也可能不同。
如果錯誤出現在建置時，先記錄失敗步驟是在拉取基礎映像、下載語言套件，還是執行應用程式測試。若只有拉取映像失敗，調整 Docker Engine 的代理設定方向較合理；若只有 Dockerfile 中的 npm 或 pip 失敗，則應檢查建置階段如何取得代理參數與 DNS。若容器啟動後才無法連線，請在容器內檢查環境變數與路由可達性，並確認代理位址不是錯誤地寫成容器自己的迴圈位址。
Docker Desktop 可能在虛擬化網路中轉送請求，TUN 對它的影響會受作業系統、版本與網路配置影響；Linux 原生 Docker 則常由獨立守護程序處理拉取流量。不要將一個平台的設定步驟原封不動套到另一個平台。每次只改一層，重現同一條失敗命令，再看 Clash 連線紀錄是否出現目的網域，會比一次改動 Shell、Docker daemon 與容器環境更容易定位問題。
規則分流、NO_PROXY 與內網服務的保護
代理設定正常後，仍要避免把本機開發服務、公司內網或容器間通訊錯誤送進代理。常見的 NO_PROXY 可列出不應透過 HTTP Proxy 的主機或網域；例如 localhost、127.0.0.1 與 ::1。不同程式對大小寫、網域後綴、CIDR 和萬用字元的支援並不一致，因此不要假設一份清單會被所有工具完全相同地解讀。
在 Clash 規則側，也應依實際網路設計保留內網直連策略。例如公司 Git 服務、私有套件倉庫、開發伺服器與區域網路裝置，可能需要使用 DIRECT；一般外部服務則由你信任的策略群組處理。規則排序很重要：若廣泛的代理或直連規則先命中，後面更具體的網域規則可能永遠不會生效。修改後請到連線紀錄確認「目的網域、命中規則、策略群組」三者，而不只是看模式名稱。
NO_PROXY 主要影響會遵循該變數的應用程式，不會自動覆蓋 TUN 的系統路由或 Clash 核心規則。若開啟 TUN 後，本機開發伺服器仍繞到外部出口，應分別檢查應用程式 Proxy 變數、核心規則與作業系統路由。反過來說，若內網網域被錯誤送往代理，請確認它是否因 DNS 解析結果或規則匹配順序而落入外部代理策略。
建議把設定拆成可維護的幾層：Shell 只保存目前工作環境需要的代理入口；工具設定只處理確實需要獨立代理的程式；Clash 規則負責目的地分流；Docker daemon 與容器則各自確認實際網路位置。團隊協作時，記錄使用的埠號來源、變數作用範圍和內網例外，比把一整份帶有個人位址或憑證的設定檔直接分享更安全。
若你已按層檢查仍有問題，可依序完成一輪診斷：確認核心正在監聽預期埠號；從目前終端確認變數值；用簡單 HTTPS 請求驗證代理入口；再用 Git、npm 或 pip 的單一測試命令重現；最後在 Clash 連線紀錄比對目的網域和命中策略。對 Docker 則另外標記錯誤發生在 pull、build 或容器執行階段。每輪只改一個設定，並在測試後撤銷臨時變更，較容易保留可重現的結論。
常見問題
設了 HTTPS_PROXY，為什麼某個 CLI 還是直連？
不是所有程式都會讀取 HTTPS_PROXY；有些工具採用自己的設定，有些背景服務也不會繼承目前 Shell 的環境。先確認該程式的代理支援方式與啟動環境，再查看 Clash 連線紀錄。若請求完全沒有出現，可測試工具的專屬設定或短時間以 TUN 對照；若請求已出現但走 DIRECT，則應檢查規則。
工程工作一定要開 TUN 嗎？
不一定。支援代理變數的 Git、npm 或 pip，通常可先用系統 Proxy 加環境變數處理。TUN 適合測試或接管不遵循應用層 Proxy 的流量，但影響範圍較廣，也可能與 VPN、Docker 或虛擬機器路由互相干擾。應以實際連線紀錄和需求決定是否啟用。
容器裡的 127.0.0.1 為什麼連不到主機上的 Clash？
容器中的 127.0.0.1 指向容器自己，不是 Docker 主機。應使用該平台支援的主機連線位址與可達的代理埠，並確認 Clash 沒有只監聽容器無法存取的介面。修改前先檢查 Docker 網路模式與安全性需求，避免為了方便而將代理埠暴露到不可信的網路。
設定 NO_PROXY 後，為什麼內網仍被送進代理？
NO_PROXY 的格式與支援程度會因工具而異，而且它不一定能影響 TUN 路由或 Clash 核心規則。先確認問題程式確實讀取該變數，再檢查網域是否符合清單格式、解析結果和規則順序；需要時在 Clash 規則中為內網服務明確設定符合組織政策的直連方式。
有些桌面代理工具只提供全域開關，遇到 CLI、套件管理器和 Docker 時，常需要自行補環境變數、分別設定守護程序，內網例外也容易散落在多處。Clash 的分流規則、連線紀錄與 TUN 選項，則能讓你逐一確認請求是否進入核心、命中哪條規則，以及是否需要擴大接管範圍；如果你希望在同一個介面整理這些代理工作流程，可依自己的平台與網路政策選擇合適的 Clash 用戶端。