前言：為什麼瀏覽器能連，終端機卻不行？
使用 Clash 時，瀏覽器可以正常開啟網站，不代表 Git、Homebrew、npm 或容器裡的命令列程式也會自動走代理。常見原因是這些工具使用不同的網路介面：瀏覽器可能有自己的代理設定，命令列工具則可能直接連線，或只讀取目前終端機工作階段中的代理環境變數。結果就會出現 Git clone 卡住、套件下載逾時，或同一台電腦上的不同應用程式表現不一致。
TUN 模式的作用，是讓 Clash 透過虛擬網路介面接管符合條件的系統流量。因此，不需要每個命令列工具都個別設定 HTTP 代理，便有機會讓終端機應用程式與一般桌面程式使用同一套分流規則。不過，TUN 並不代表任何流量都必定經過代理：路由規則、DNS、系統權限、網路介面與應用程式自身設定仍會影響結果。
本文的操作目標
先確認終端機的故障類型，再啟用適合的平台 TUN 設定，最後用 DNS、路由與實際下載測試驗證流量去向。若 TUN 不適合你的權限或網路環境，也會說明如何使用明確的命令列代理作為替代方案。
1先判斷終端機流量目前走哪裡
調整設定前，先找出問題範圍，避免把 DNS、憑證或伺服器故障誤認為代理問題。選定 Clash 中一個目前可用的節點，確認代理核心已啟動，並記下終端機測試前後的時間，方便在連線紀錄或連線面板中對照目的網域。
區分系統代理與終端機代理
桌面客戶端中的「系統代理」通常設定 HTTP 或 SOCKS 代理，讓支援系統代理的應用程式使用；它不會保證所有 CLI 工具都會自動讀取設定。相較之下，TUN 會在作業系統網路層建立虛擬介面，對未自行指定代理的程式通常更方便。兩者可以依客戶端能力搭配使用，但遇到衝突時，應先暫時停用額外的程式代理設定，以單一方式測試。
先檢查目前 shell 是否已設定代理環境變數：
若看到 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或其小寫版本，代表目前 shell 可能把連線送往指定的代理位址。若代理已關閉、埠號錯誤或變數指向舊客戶端，請求可能直接失敗。反過來說，若這些變數不存在，並不能單獨證明 TUN 沒有工作，還要配合 Clash 連線紀錄及網路測試判斷。
建立基本連線測試
挑選一個平常失敗的目標與一個可正常存取的目標測試。以下命令只用於檢查 DNS 和 HTTPS 連線；若你的環境沒有安裝 curl，可改用瀏覽器或客戶端的連線紀錄交叉確認。
測試時留意錯誤類型：名稱解析失敗通常要檢查 DNS；連線逾時可能與路由、節點或防火牆有關；收到 TLS 或憑證錯誤則不應直接關閉憑證驗證，而應檢查系統時間、根憑證和公司網路的 HTTPS 檢查政策。若 Clash 面板看不到相應目的連線，也要確認流量是否被應用程式的自訂代理、VPN、容器或另一張虛擬網卡接走。
2啟用 TUN 並設定合理的路由
不同 Clash 客戶端的選單名稱可能不同。Clash Verge、Clash Verge Rev 與其他整合 Mihomo 的客戶端，通常會在設定或網路頁面提供 TUN 開關；請以目前版本實際顯示的選項為準。TUN 需要建立虛擬網路介面，部分系統還需要管理員授權或安裝服務。啟用前先確認使用的是支援 TUN 的核心，並確保設定檔沒有 YAML 語法錯誤。
理解常用 TUN 選項
常見設定包括 enable、stack、auto-route、strict-route、dns-hijack 和 auto-detect-interface。它們是否可用、預設值和細節會依 Mihomo 核心版本及客戶端而異；修改前請查閱目前版本的設定說明，並優先使用客戶端提供的表單控制，不要把範例盲目覆蓋進現有設定。
auto-route 通常用於自動加入路由，讓系統流量進入 TUN；auto-detect-interface 則協助核心選擇實體出口介面。不同網路環境可能需要調整路由或排除介面，例如同時連線公司 VPN、虛擬機、容器網路或多張網卡時。若一啟用便無法連內網或遠端桌面，先停用 TUN 還原連線，再檢查路由與介面設定，不要持續疊加不確定的排除規則。
依平台完成權限與啟動
- 在 Clash 客戶端啟用 TUN，若系統要求安裝服務或提升權限，確認提示來自已安裝的客戶端後再授權。
- 重新啟動核心或客戶端，確認虛擬介面已建立，且 Windows 網路狀態沒有因其他 VPN 或安全軟體而中斷。
- 先測試一般 HTTPS 網站，再執行 Git 或套件管理命令；若只有特定程式失敗，查看該程式是否使用自己的代理設定。
- 在客戶端開啟 TUN，依 macOS 提示允許必要的網路擴充功能或系統授權；授權後如需重新啟動，請按提示完成。
- 若客戶端提示需要管理權限，使用其官方功能完成授權，不要從來源不明的指令安裝額外服務。
- 確認 Wi-Fi 或乙太網路仍為有效出口，並在切換網路後重新測試，以排除介面偵測未更新的情況。
- 確認客戶端或核心有權建立 TUN 介面及修改路由；權限需求會依發行版、安裝方式與服務管理方式而異。
- 在客戶端檢查核心日誌與虛擬介面狀態，並留意防火牆、NetworkManager、WireGuard 或其他 VPN 是否重寫路由。
- 若在容器或遠端主機中執行，容器網路命名空間和能力限制可能令 TUN 無法接管宿主機流量，應在預期的網路命名空間內測試。
權限與安全提醒
TUN 會影響整個系統或指定路由的網路流量，安裝服務或授予系統權限前，請確認客戶端來源可信。需要恢復網路時，先關閉 TUN 並正常退出客戶端，再檢查是否有殘留路由；不要隨意清除整台電腦的網路設定。
3讓 Git、Homebrew 與套件工具穩定工作
確認 TUN 已啟用後，不要只以「網頁打得開」作為完成標準。命令列工具會連線到不同網域，有些下載器還會重新導向到 CDN。建議依序測試 Git、套件管理器與實際專案依賴，並在 Clash 面板確認連線紀錄中出現預期的網域及策略組。規則模式下，目標網域可能被分配到不同策略；若連線存在但使用了不合適的策略，再檢查規則順序與分流結果。
Git clone 與遠端操作
先用 HTTPS 測試遠端讀取，確認名稱解析、TLS 握手與 Git 連線都正常。若 HTTPS 可用而 SSH 連線仍逾時，問題可能是 SSH 目的埠或路由策略不同；TUN 是否能接管該連線，仍取決於目前規則、路由與網路政策。也可檢查 Git 是否保存了舊的代理設定：
如確認 Git 的代理設定已過時，可移除特定範圍的錯誤設定，再由 TUN 接管，或重新填入有效代理位址。操作前先看清楚 --show-origin 顯示的設定來源；設定可能來自系統、使用者或單一專案，不建議未檢查便清除所有 Git 設定。使用 SSH 時，也要確認客戶端的規則是否允許相應連線，並避免把私鑰或含有憑證的遠端網址貼到公開日誌。
Homebrew 與其他下載器
Homebrew 的更新和安裝可能涉及多個 Git 遠端、套件伺服器或重新導向的下載來源，因此「公式清單更新成功」不一定代表大型檔案下載也正常。請分別測試更新、查詢套件與下載安裝，並在卡住時查看 Clash 連線紀錄中的實際目的網域。若瀏覽器能開啟下載頁，但命令列下載逾時，檢查 DNS 解析及下載目的網域是否被規則送往可用策略。
對 npm、pip、Cargo、Docker 等工具也採用相同方法：先辨識實際下載網域，再檢查核心日誌和 DNS，最後才考慮設定工具專屬代理。套件來源有自訂鏡像或公司內部登錄檔時，應保留其必要的直連或內網路由，避免把內部憑證、授權標頭或私有套件資訊送到不受信任的代理服務。
TUN 不適用時：明確設定 shell 代理
在受限主機、遠端開發環境或不方便授權虛擬介面的設備上，可以使用 Clash 客戶端提供的 HTTP 或 SOCKS 監聽埠，明確設定目前 shell 的代理變數。埠號須以客戶端實際設定為準，以下僅為格式示意：
有些程式只支援 SOCKS 代理，或使用自己的代理設定格式，應查看該工具的文件；不要把 HTTP 代理埠當成 SOCKS 代理埠使用。環境變數通常只影響目前終端機及其啟動的子程序，新開的視窗或登入 shell 未必會繼承。若要寫入 shell 啟動檔，應先確認使用的 shell 與代理埠，並保留取消方式，避免離開 Clash 後所有命令列連線仍指向不存在的代理。
4驗證結果、排除故障並建立可還原流程
設定完成後，按「核心啟動、TUN 狀態、目標連線、實際工具」的順序驗證。先確認客戶端沒有核心錯誤，再查看 TUN 是否顯示啟用，接著執行 HTTPS 測試與 Git 測試，同時觀察連線面板是否記錄到目的網域。若使用規則模式，還要檢查該連線最終選中的策略；有流量紀錄不代表一定選到了預期節點。
| 現象 | 優先檢查 | 建議處理 |
|---|---|---|
| 瀏覽器正常，終端機沒有連線紀錄 | TUN 狀態、路由、應用程式代理變數 | 確認 TUN 已建立；檢查程式是否使用舊代理或在不同網路命名空間執行。 |
| 出現連線紀錄，但下載逾時 | 分流策略、節點狀態、目的網域 | 檢查實際選中的策略與重新導向網域；換用已確認可用的節點再測。 |
| 域名解析失敗或結果不一致 | DNS 設定、DNS 劫持、系統快取 | 確認核心 DNS 正常，檢查 TUN DNS 設定是否受版本支援，再清除相關快取重試。 |
| 啟用 TUN 後內網或 VPN 失效 | 路由優先順序、介面偵測、VPN 衝突 | 先關閉 TUN 恢復連線，再依實際網段與客戶端文件設定必要的路由例外。 |
| Git HTTPS 正常，但 SSH 失敗 | SSH 目的埠、規則與網路政策 | 分開診斷 SSH 路由；遵循公司或網路管理政策，不要以關閉安全檢查作為解法。 |
DNS 與路由檢查要點
DNS 設定應與 TUN 和核心版本相容。若啟用 DNS 劫持後出現解析異常，先查看核心日誌，確認 DNS 請求是否被接收，以及上游伺服器是否可用；不要同時改動多個 DNS 選項，否則難以判斷是哪一項造成問題。若只有某些網域解析異常，檢查規則、快取和該網域的 DNS 回應；若所有網域都失敗，優先確認核心、上游 DNS 和系統網路是否正常。
多 VPN、虛擬機、容器與公司內網常會建立多張虛擬介面，路由表也可能由不同服務反覆更新。出現衝突時，先停用不需要的 VPN 或網路工具做單一變因測試，確認問題來源後再恢復必要服務。對內網網段、公司 DNS 和本機開發服務，依組織政策設定直連或路由例外；不要為了讓一個下載命令成功而把整段未知流量永久導向特定節點。
記錄設定並準備還原
每次只改一類設定，並記錄修改前的 TUN 選項、代理埠、規則及測試結果。若更新客戶端或 Mihomo 核心後行為改變，先核對版本變更與核心日誌，再確認 YAML 欄位仍被支援。停止使用 TUN 時，透過客戶端正常關閉功能並重新測試一般網路；若仍無法連線，重啟客戶端或網路介面之前，先確認沒有其他 VPN 或管理工具接管路由。
理想的工作流程是：日常使用時以 TUN 統一接管符合規則的流量；在權限受限的遠端環境中，改用短期、明確的 shell 代理；遇到故障時，先分辨 DNS、路由、節點或工具設定，再根據連線紀錄修正。這樣既能減少每個工具各自配置代理的負擔，也能避免把所有問題都歸因於「Clash 沒有生效」。