為什麼 Git、npm 與 Docker 會各自遇到連線問題
開發工作中，瀏覽器能正常開啟網站，不代表終端機裡的 Git、npm、pip、Docker 也會使用同一條網路路徑。瀏覽器可能讀取系統代理，或透過擴充功能轉送流量；命令列工具則可能遵循自己的代理設定、讀取環境變數，甚至完全忽略桌面系統代理。於是就會出現網頁瀏覽正常，git clone 卻逾時；npm 安裝一直重試；Docker 拉取映像檔卡在解析或 TLS 握手的情況。
這些工具連線時也不一定只接觸一個主機。Git 操作可能連到程式碼託管服務及其物件儲存網域，套件管理工具可能連至套件登錄站、鏡像站和 CDN，Docker 則可能先連線到 Registry，再取得映像檔圖層。若其中某一段被規則送往不合適的出口，或程式只對部分請求採用代理，表面上便像是某個工具故障，實際問題卻可能出在整條連線路徑。
Clash TUN 的作用，是在作業系統網路層建立虛擬介面，讓原本不支援 HTTP 代理、或沒有讀取代理環境變數的應用程式流量，也有機會交由 Mihomo 核心處理。它能補上「命令列程式沒有走系統代理」這個缺口，但不等於所有程式一定會自動成功：路由、DNS、規則、應用程式自己的設定與網路權限仍會影響結果。本篇會依照工程師常見的終端機工作流程，說明何時值得開 TUN、如何逐步驗證，以及如何避免把原本正常的區域網路或公司 VPN 一併弄壞。
TUN、系統代理與環境變數：先分清各自負責的部分
排查代理時，先分辨「流量有沒有進入 Clash」與「進入後被分配到哪個策略」是兩個不同問題。系統代理主要提供 HTTP、HTTPS 等應用程式可採用的本機代理位址；環境變數則讓支援該慣例的命令列工具知道代理伺服器在哪裡；TUN 則從作業系統網路層接收部分 IP 流量。三者可以搭配使用，但不是同一個開關，也不必一開始全部啟用。
- 系統代理：適合會遵循桌面作業系統代理設定的應用程式。若 Clash Verge Rev 已開啟系統代理，而工具仍沒有連線紀錄，可能是該工具不讀取系統設定。
- 環境變數：適合支援
HTTP_PROXY、HTTPS_PROXY或ALL_PROXY的 CLI 工具。設定範圍容易控制，也方便只在單一終端機視窗測試。 - TUN：適合需要涵蓋較多系統網路連線的情境，例如工具不提供代理選項、子行程沒有繼承環境變數，或只靠系統代理看不到相關連線時。
可先從較小範圍的方案開始：先確認 Clash 核心正常、規則與節點可用，再測試系統代理或環境變數。只有在請求仍未進入 Clash，或應用程式確實不遵循代理設定時，才啟用 TUN。這樣做的好處是每次只改一個變因，能更快分辨問題是在命令列工具、Clash 規則，還是作業系統路由層。
不同用戶端與版本的選單名稱可能不同。以 Clash Verge Rev 為例，TUN 相關設定通常會在設定頁或核心功能區，並可能需要管理員權限；請以目前版本的介面提示為準，不要照著其他版本截圖盲目尋找。若裝置受公司管理，或同時安裝了企業 VPN、零信任軟體、虛擬機網路工具，先確認組織政策與相容性，再決定是否啟用 TUN。
啟用 TUN 前先核對的設定與風險
開始調整前，記下目前使用的設定檔、模式、代理埠號與已啟用的 VPN。這些資訊能在測試失敗時協助你還原狀態。若使用遠端 SSH 工作階段，也要留意修改本機路由通常不會改變遠端主機自身的網路出口；你要確認代理流量來自本機工具，還是來自遠端伺服器上的程式。
- 確認設定檔已載入：有些用戶端會同時保留訂閱原檔、合併設定與覆寫內容。修改前先確認目前生效的是哪份設定，避免在未載入的檔案裡調整規則。
- 檢查模式與策略群組：以規則模式測試時，確認目標網域不會被較早的規則送往
DIRECT。若只為短暫診斷而使用全域模式，完成對照後應恢復原有模式。 - 確認 TUN 權限與狀態：若介面顯示啟動失敗，查看作業系統權限提示及 Clash 日誌；不要反覆輸入管理員密碼，也不要為了排錯關閉整體安全防護。
- 盤點其他網路元件：公司 VPN、虛擬機、容器網路與防毒軟體都可能新增路由或攔截連線。排錯時避免同時更換節點、DNS、規則與 VPN 狀態，否則難以判斷是哪項改動造成差異。
- 保留區域網路需求：Docker 可能需要存取本機 Registry、開發伺服器或區網服務。確認 LAN 網段與內部網域能依預期直連，不要為了讓外部套件下載成功而把所有目的地一律送往代理。
DNS 也值得獨立檢查。若網域解析結果不正確，或 DNS 請求走了與連線不同的路徑，可能出現主機解析失敗、連到錯誤位址，或只有特定網域逾時。先觀察 Clash 連線紀錄中的目的網域與規則命中，再比較系統解析結果；不要在未確認原因時同時更換多組 DNS 設定。
實作流程：逐步確認 Git、npm 與 Docker 是否走對路徑
建議使用同一個終端機視窗完成測試，並在 Clash 用戶端打開連線或日誌檢視。測試時先選一個可重現的操作，例如更新 Git 遠端資訊或安裝一個常用套件；不要同時跑多個大型下載，否則連線紀錄會混在一起。每個步驟都記錄結果，方便回復原設定。
- 先驗證 Clash 本身。確認核心正在執行、目前設定檔成功載入，且所選策略群組有可用出口。若其他程式透過 Clash 也無法連線，先處理核心、設定檔或節點問題，暫時不要把焦點放在 Git 或 npm。
- 用單一工具確認基準狀態。先在終端機執行一個可重現的 Git、npm 或 Docker 操作，同時查看 Clash 連線列表。若完全看不到目標請求，表示應用程式可能沒有使用系統代理，或流量尚未進入 Clash；若看得到請求，記下網域、命中規則及策略名稱。
- 試用環境變數縮小範圍。如果工具支援代理環境變數，可先只在目前 Shell 設定，將位址與埠號替換成 Clash 用戶端實際提供的本機 HTTP 或 mixed-port。不要直接假設埠號固定；請在用戶端設定中核對。完成測試後，關閉該終端機或清除變數，確認結果是否可重現。
- 仍未進入 Clash 時，再啟用 TUN。依用戶端提示開啟 TUN，處理必要的系統授權，等待狀態顯示啟用後，再用完全相同的命令重測。不要同時更換節點或修改規則。若此時連線紀錄開始出現 Git 或套件管理工具的請求，便能確認問題與流量攔截範圍有關。
- 依連線紀錄修正規則。如果目標網域已進入 Clash，但顯示
DIRECT或走錯策略，檢查規則順序及網域匹配方式，將必要網域導向適當的策略群組。以實際紀錄中看到的網域為準，不要只憑工具名稱猜測一份很寬泛的網域清單。 - 分別驗證並恢復測試環境。Git、npm 與 Docker 要個別重測，因為它們可能存取不同服務。確認外部下載成功後，也測試區域網路、內部 Registry 與公司資源；最後關閉不需要的暫時性環境變數，並確認 TUN、系統代理及 VPN 狀態符合日常工作需求。
環境變數的命名與大小寫支援會因工具、語言執行環境及作業系統而異。常見變數包括 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，但並非每個程式都會讀取全部變數。設定代理時，請使用 Clash 實際提供的本機位址與埠號；測試完成後，也可檢查是否有舊的 NO_PROXY 規則把目標網域排除，導致部分請求繞過代理。
如果 Git 失敗但 npm 正常，優先檢查 Git 自身的代理設定與遠端網址；若 Docker 命令可用、映像檔卻拉取失敗，則要分辨是 Docker Engine 的網路環境，還是目前終端機的代理設定。Docker Engine 若以服務或背景程序執行，未必會繼承登入 Shell 的環境變數；此時 TUN、Engine 自身的代理設定或管理員提供的網路設定可能各有影響，應以連線紀錄和實際部署方式逐項確認。
常見連線症狀與排查順序
相同的「逾時」訊息背後可能有不同原因。與其不斷換節點，不如先看失敗發生在哪一層：網域解析、連線建立、TLS 握手，還是下載過程中斷。把錯誤時間與 Clash 日誌對照，通常可以先判斷請求有沒有進入核心，再確認策略是否合理。
- 連線列表完全沒有相關請求：檢查 TUN 是否真正啟用、程式是否在另一台主機或容器中執行，以及目前路由是否繞過本機介面。若是支援代理的工具，可用暫時環境變數做交叉測試。
- 請求出現在列表，但策略為 DIRECT：檢查規則順序、目標網域與模式。較廣泛的直連規則若排在特定代理規則之前，後續規則可能不會被採用。
- 策略正確，仍在 TLS 或下載階段失敗：再檢查 DNS 結果、系統時間、憑證環境與出口連線穩定度。若只有大型檔案中斷，可能是長連線或傳輸路徑不穩，不一定是代理設定錯誤。
- 啟用 TUN 後內部網站或 VPN 失效：先停用 TUN 恢復基準狀態，再檢查排除網段、區域網路規則和公司 VPN 的相容性。不要直接清空路由或調整不熟悉的系統網路參數。
- 重新開機後設定失效：確認用戶端是否需要重新授權、TUN 是否設為隨核心啟動，以及系統代理或 Shell 設定是否只存在於單次工作階段。不同作業系統的持久化方式不同，修改前先記錄原值。
排錯過程中也要保護訂閱與憑證資料。設定檔、完整訂閱網址、私有 Registry 位址、Git Token 和套件登入憑證都可能包含敏感資訊。分享日誌前，先遮蔽帳號、令牌、內部網域與節點資訊；在團隊文件中記錄流程時，保留可公開的埠號與錯誤類型即可，不要貼出可直接使用的憑證。
常見問題
開發者需要一直開著 TUN 嗎？
不一定。如果 Git、npm 等工具已透過系統代理或環境變數穩定連線，而且區域網路與公司資源沒有問題，通常不必為了「可能有用」而長期啟用 TUN。當工具不讀取代理設定、連線紀錄看不到請求，或需要涵蓋更多應用程式流量時，再把 TUN 作為補充方案。
已設定 HTTPS_PROXY，還需要 TUN 嗎？
取決於工具是否遵循該變數，以及子行程是否能繼承設定。支援環境變數的 CLI 通常可以先採用較小範圍的代理方式；不支援、使用不同網路函式庫，或由背景服務執行的程式，可能需要檢查 TUN 或程式自身的代理設定。兩種方式可以用相同命令做對照，但排錯時一次只改一項。
Docker 拉不到映像檔，但 Git 與 npm 正常，該怎麼辦？
先確認失敗的是 Docker CLI、Docker Engine，還是 Registry 端的映像檔請求。Engine 可能以背景服務執行，網路環境與目前 Shell 不同；同時留意連線紀錄中的 Registry 網域和下載圖層網域。不要只因為 Git 已成功，就假設 Docker 一定共用相同代理設定。
TUN 和公司 VPN 衝突時怎麼處理？
先依公司網路政策確認是否允許同時使用，再暫時停用其中一個網路接管工具做基準測試。如果停用 TUN 後公司資源恢復，可能是路由或 DNS 範圍重疊；此時應檢查用戶端提供的排除選項，或詢問管理員建議，而不是自行移除公司 VPN 的安全設定。
建立可維護的終端機代理流程
對開發工作而言，最穩定的設定通常不是規則越多越好，而是能明確回答三件事：哪些程式需要代理、請求有沒有進入 Clash、命中的策略是否符合預期。可先為個人終端機選擇系統代理或環境變數，記錄混合埠與必要的 NO_PROXY 範圍；遇到不支援這些設定的工具，再以 TUN 補足。團隊共用的工作站或 CI 環境，則應依管理方式統一配置，避免每位成員各自維護一套不透明的變數與路由。
一些只依賴單一應用程式代理選項的工具，遇到子行程、容器或多個下載網域時，常需要逐項補設定；相較之下，Clash TUN 能在系統網路層集中觀察與分流更多流量，也可搭配連線紀錄確認 Git、套件管理工具與 Docker 的實際路徑。不過它仍需配合清楚的規則、正確的 DNS 與 VPN 相容性檢查。如果你希望從同一個用戶端開始管理代理設定，可先依裝置選擇合適版本，再按本文流程逐步驗證。