為什麼瀏覽器能連線，Git 和套件管理器卻失敗

開發者常遇到這種情況：瀏覽器可以開啟 GitHub，終端機裡的 git clone 卻停在連線中；npm、pip 或 Homebrew 下載套件時出現逾時，甚至 Docker 映像檔拉取到一半中斷。這不一定代表代理節點故障，常見原因是瀏覽器與命令列程式採用不同的代理路徑。瀏覽器可能遵循作業系統的系統代理設定，但終端程式未必會讀取同一組設定；有些工具會查看 HTTP_PROXY、HTTPS_PROXY 等環境變數，有些則使用自己的設定，還有些會由背景服務代為連線。

Clash TUN 模式的用途，是在作業系統的網路層建立虛擬介面，讓符合路由條件的流量經由 Clash 處理。這對不支援傳統 HTTP 或 SOCKS 代理的程式特別有幫助，因為程式不必自行理解代理設定，也能把連線交給 TUN 接管。不過，TUN 不等於「任何程式、任何網路都必定走代理」：路由規則、DNS 行為、核心權限、防火牆，以及容器或虛擬機器的網路拓撲，仍會影響實際結果。

本文以 Mihomo 核心及支援 TUN 的 Clash 客戶端為例，說明如何逐步檢查終端機流量。Clash Verge、Clash Verge Rev、Mihomo Party 等介面的選項名稱可能隨版本不同，請以目前客戶端與核心實際顯示的設定為準。開始前，先確認你使用的設定檔已載入、核心正在運作，而且手邊有可正常使用的代理策略組；否則，即使 TUN 已啟用，連線仍可能因策略本身不可用而失敗。

ℹ 先釐清故障範圍：瀏覽器是否正常、終端機是否設定代理環境變數、Clash 日誌有沒有該連線，以及失敗的是 HTTPS、SSH 還是容器網路。一次只改一項，才能看出真正原因。

啟用 TUN 前先檢查權限、核心與路由

啟用 TUN 前，先確認客戶端使用的是支援 TUN 的核心版本。若客戶端可選擇核心或版本，請查看目前運行中的核心資訊，而不只看應用程式名稱；介面更新後仍載入舊核心，是設定欄位不存在或啟用後沒有預期效果的常見原因。接著確認作業系統是否已授予必要權限：Windows 可能需要允許建立虛擬網路介面或安裝相關驅動程式；macOS 可能出現網路延伸功能的授權提示；Linux 則可能需要可建立 TUN 裝置的權限。請只授予可信客戶端所需的權限，並留意公司或學校裝置可能由管理政策限制。

在客戶端設定中尋找 TUN、虛擬網路介面或類似選項，啟用後重新載入核心，觀察狀態是否顯示成功。Mihomo 的設定通常會在 tun 區塊中控制啟用、路由與 DNS 行為；不同版本可用欄位及預設值可能不同，不建議直接把網路上的整段 YAML 貼入現有設定。若使用設定檔編輯，先備份原檔，再依照目前核心文件確認欄位名稱與縮排，並使用客戶端提供的設定檢查功能驗證。

特別留意 auto-route、strict-route、DNS 相關選項，以及是否有排除網段或進程的設定。它們決定哪些流量被導入虛擬介面，也可能影響區域網路、公司內網、虛擬機器及容器的連線。初次測試時，先採用客戶端建議的預設值，不要同時加入複雜的路由排除清單。若需要存取 NAS、印表機或公司內網，應在確認基本外網代理正常後，再逐項設定直連例外。

還要檢查 DNS。終端機連線通常先解析主機名稱，再建立 TCP 或 TLS 連線；若 DNS 查詢走直連、但後續流量走代理，或解析結果與規則判斷不一致，可能出現瀏覽器可用、命令列卻連錯路徑的情形。切換 TUN 或 DNS 模式後，可重新啟動失敗的命令，再查看 Clash 連線日誌中的主機名稱、命中規則與策略組。除錯期間避免同時開啟多套 VPN 或其他虛擬網路工具，以免多個路由器互相競爭。

驗證 Git：HTTPS 與 SSH 要分開排查

GitHub 專案的 HTTPS 與 SSH 連線是兩條不同的路徑。HTTPS clone 通常使用 TCP 443，會受到 Git 代理設定、環境變數與 TUN 路由共同影響；SSH clone 則通常連到 SSH 服務埠，並不會自動遵循 HTTPS_PROXY。因此，先確認你使用的遠端網址格式，再選擇對應的測試方法。可用 git remote -v 查看現有儲存庫的遠端位址；測試時也可以直接使用一個公開且你有權存取的專案。

  1. 先檢查終端機環境變數與 Git 自身設定，確認是否已有舊代理指向已關閉的本機埠。可使用 env | grep -i proxy 檢查環境變數，再以 git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy' 查看 Git 設定來源。
  2. 若使用 HTTPS，執行一次 git ls-remote https://github.com/OWNER/REPOSITORY.git，以讀取遠端參照而不下載整個專案。若指令逾時，立即查看 Clash 連線日誌，確認請求是否出現、命中哪條規則，以及是否交給預期的代理策略組。
  3. 若使用 SSH，先執行 ssh -T [email protected]。連線成功時，GitHub 通常會回覆帳戶驗證訊息；若停在連線階段，應檢查 SSH 連線是否進入 TUN、路由是否允許該埠，以及防火牆或網路政策是否阻擋，而不是只修改 HTTPS 代理。

當 HTTPS 失敗而 SSH 正常，優先檢查 Git 的代理設定、終端機環境變數及 HTTPS 網域的策略命中；若 SSH 失敗而 HTTPS 正常，則重點在 SSH 埠、路由策略與 SSH 用戶端本身。部分網路會限制常見 SSH 埠，遇到這種情況，應先確認網路管理者允許的連線方式，再評估 GitHub 官方支援的替代 SSH 連接埠設定；不要把任意埠號改寫進規則，卻沒有驗證服務端是否接受。

不建議在尚未釐清 TUN 效果前，永久寫入多組 Git 代理設定。若環境變數、全域 Git 設定與 TUN 同時套用，容易造成重複代理或請求走向難以判斷。測試完成後，保留一種明確且可維護的代理策略；若你決定完全交由 TUN 接管，可以移除指向失效本機埠的舊設定，但操作前先記下原值，方便回復。

npm、pip 與 Homebrew：先看連線紀錄再改設定

套件管理器可能連線到多個主機，而不只是你熟悉的首頁網域。npm 會查詢套件註冊表並下載套件檔案，pip 會連到套件索引及其檔案來源，Homebrew 則可能同時取得公式資訊、原始碼或預編譯套件。這些請求可能經由不同網域或 CDN，因此不能只測試一個網站就認定整條安裝鏈正常。當安裝指令卡住時，先記下錯誤類型、正在處理的套件與停滯階段，再用 Clash 日誌找出實際連線的主機。

對 npm 而言，可先執行 npm config get registry 確認目前使用的註冊表，再用 npm ping 做基本連線測試。若 ping 成功但安裝失敗，問題可能出在套件 tarball 的下載來源、憑證、權限或鎖檔，而不是註冊表本身。對 pip，可確認目前使用的索引設定，並以安裝一個已知套件的小型測試觀察是否停在索引查詢或檔案下載。對 Homebrew，先執行 brew update，再觀察更新過程中的連線紀錄；不要在尚未確認來源的情況下，直接切換到陌生鏡像。

如果這些工具原本設定了 HTTP_PROXY 或 HTTPS_PROXY，請確認代理位址、連接埠及協定都正確。環境變數通常由 shell 啟動設定載入，圖形介面重新啟動核心後，既有終端視窗可能仍保留舊值；關閉並重新開啟終端機，再檢查一次，能排除不少「設定已改但程式不變」的狀況。NO_PROXY 也值得檢查：若其中有過寬的網域或萬用字元，可能讓原本預期經代理的請求直接連線。

遇到 TLS 錯誤時，不要立刻關閉憑證驗證。先確認系統時間正確、系統根憑證與套件管理器版本可用，再查看錯誤是憑證拒絕、DNS 失敗、TCP 逾時，還是下載中斷。這幾種問題的處理方向不同：TUN 可以改善流量路由，卻無法修補過期的憑證、錯誤的套件索引位址或無效的登入權杖。把錯誤訊息與同一時間的 Clash 日誌對照，通常比盲目更換策略組有效。

Docker 為什麼可能與主機終端機表現不同

Docker 的網路路徑比一般終端程式多一層。你在主機終端機執行 curl 時，連線由主機作業系統發出；使用 Docker CLI 拉取映像檔時，實際下載工作可能由 Docker 背景服務或另一個守護程序執行。容器內執行的 npm、pip 或 Git，又會使用容器自己的網路命名空間。因此，主機的 TUN 已接管一般流量，不代表 Docker daemon 與所有容器也必然使用相同 DNS 和路由。

先用 docker pull 拉取一個可信且常用的測試映像，並同時觀察 Docker CLI 回報與 Clash 日誌。如果日誌完全沒有相關請求，需確認下載由哪個服務執行、該服務是否走主機 TUN，以及作業系統是否為 Docker 虛擬網路設定了例外。如果請求已出現在日誌，則檢查命中的網域規則與策略組，再確認是否遇到映像倉庫驗證、速率限制或映像標籤錯誤。區分「網路未到達 Clash」和「網路已到達但遠端拒絕」，可避免把帳戶或映像設定問題誤判為代理故障。

若容器內工具需要代理，還要分清楚主機上的 Docker daemon 設定與容器環境變數。前者可能影響映像檔拉取，後者則影響容器執行期間的 HTTP 或 HTTPS 請求；兩者的設定位置與生效時機不同。請依 Docker 版本與作業系統文件設定，避免把主機的 127.0.0.1 直接當成容器可用的代理位址，因為容器內的 loopback 通常指向容器本身，而不是主機。

Docker Desktop、虛擬機器與 WSL 等環境還可能有獨立的虛擬交換器和 DNS 轉送。若只有 Docker 或 WSL 裡的請求失敗，先測試主機端的同一個網域，再比較容器或子系統內的解析結果和連線狀態。一次只調整一層設定，並保留變更前的內容；直接改動多個網路介面、DNS 伺服器與防火牆規則，會讓回復與定位問題都更困難。

分層排查清單與常見問題

要讓排查結果可重現，建議固定一個簡單流程：先確認 Clash 核心和代理策略正常，再確認 TUN 狀態；接著從主機執行 DNS 或 HTTPS 測試，然後測試 Git HTTPS、Git SSH、套件管理器，最後才測 Docker 或容器內的程式。每次測試都記錄時間、命令、錯誤訊息與 Clash 日誌中的命中結果。若開啟 TUN 後原本可用的內網或區域網路中斷，先還原最近變更，再檢查路由排除與 DNS，而不是疊加更多規則掩蓋問題。

也請避免把訂閱連結、存取權杖、私人倉庫網址或包含憑證的命令貼到公開討論區。除錯日誌可能包含網域、內部位址或帳戶資訊；分享之前應先遮蔽敏感內容。若使用公司或校園網路，確認代理與 TUN 使用符合相關政策，因為客戶端有能力接管流量，不代表所有環境都允許自行變更路由。

常見問題

瀏覽器正常，npm 卻逾時，應先改 TUN 還是 npm 設定？
先查看 Clash 日誌並執行 npm config get registry。如果沒有看到 npm 連線，檢查 TUN、環境變數及終端機是否保留舊設定；如果日誌顯示請求已進入代理，則繼續檢查命中的策略、套件來源及錯誤類型。

開啟 TUN 後，還需要設定 HTTP_PROXY 嗎？
不一定。TUN 的目的之一，是讓不支援代理設定的程式也能經由網路層路由；若同時保留環境變數，程式可能先連到環境變數指定的代理，再由 TUN 處理該連線。這可能是預期行為，也可能造成重複代理。先確認現有環境變數，再選擇一致且容易除錯的方式。

GitHub SSH 連線失敗，但 HTTPS clone 成功，該怎麼辦？
SSH 與 HTTPS 使用不同協定與連線設定。請先用 ssh -T [email protected] 測試，再查看 Clash 日誌、路由規則及網路是否允許 SSH 連線；不要只因 HTTPS 可用，就假定 SSH 也會沿用相同代理設定。

Docker 拉取映像失敗，但主機的 Git 和 npm 都正常，代表 TUN 壞了嗎？
不一定。Docker daemon 可能由不同服務或虛擬網路執行下載，容器也有自己的 DNS 與網路命名空間。先確認 Docker 請求是否出現在 Clash 日誌，再分別檢查 daemon、容器代理設定與映像倉庫回應。

相較於要求每個命令列工具都各自理解 HTTP 代理的做法，Clash TUN 能把多種終端程式的流量集中到可觀察的路由與規則流程中；但只靠環境變數又容易漏掉不支援代理的背景服務。把 Git、套件管理器與 Docker 分層驗證，才能兼顧便利與可診斷性。若你希望在同一個介面管理策略、查看連線日誌並測試 TUN，可前往前往下載，選擇適合系統的 Clash V.CORE 客戶端，再依本文步驟逐項確認。