系統代理與 TUN 模式的邊界
SECTION / PROXY VS TUN系統代理(System Proxy)是作業系統層面的一項設定,本質是在系統或應用程式執行環境中寫入一組代理位址(HTTP_PROXY / HTTPS_PROXY 等環境變數,或 Windows 的 WinINet/WinHTTP 設定項、macOS 的網路偏好設定)。程式在發起網路請求時,如果讀取了這組設定並主動把流量投遞到代理連接埠,才算「走了代理」。這是**協商式**轉發:代理是否生效,取決於目標程式是否配合。
TUN 模式則完全不同。Clash Meta(mihomo)開啟 TUN 後,會在系統中建立一張虛擬網卡(Windows 上依賴 Wintun 驅動,macOS/Linux 上對應 utun/tun0 裝置),並將系統預設路由指向這張虛擬網卡。此後所有經過網路層的 IP 封包——無論來自哪個處理程序、是否知道代理的存在——都會先被虛擬網卡攔截,再交給 Clash 核心依規則處理。這是**網路層的強制接管**,不依賴任何程式的主動配合。
一句話總結差異:系統代理管的是「願不願意走」,TUN 模式管的是「走不走都得經過我」。
TUN 模式不是取代系統代理的「加強版」,而是另一套轉發路徑。多數用戶端兩者可以共存,但同時開啟時需要留意路由表是否出現互相覆蓋的情況,建議二選一使用,以降低排查成本。
哪些流量必須依賴 TUN 才能被代理
SECTION / WHO NEEDS TUN下列幾類情境下,系統代理無法生效,只有 TUN 模式能夠涵蓋:
- 以 UDP 為主的通訊協定。系統代理機制主要圍繞 HTTP/HTTPS(基於 TCP)設計,大量線上遊戲、語音通話(VoIP)、部分視訊會議軟體使用 UDP 直連,不會讀取系統代理設定。
- 命令列與背景服務。許多 CLI 工具(套件管理器、部分建置腳本)、系統常駐程序不會檢查代理環境變數,或需要額外的 --proxy 參數才會走代理,設定繁瑣且容易遺漏。
- 硬編碼 Socket 連線的應用程式。部分桌面用戶端、行動裝置應用程式直接呼叫底層 Socket API,完全繞開系統代理設定,常見於部分即時通訊與雲端同步工具。
- ICMP 與非常規通訊協定。 Ping、Traceroute 等基於 ICMP 的探測流量,以及部分 P2P 通訊協定,同樣不在系統代理的處理範圍內。
- 虛擬機器與容器內的流量。主機的系統代理通常不會自動傳遞給虛擬機器或容器,而 TUN 模式在主機路由層攔截,配合網路模式設定即可涵蓋到這部分流量。
如果你發現某個應用程式「開了代理卻依然直連」,大機率就屬於以上幾類,開啟 TUN 模式是最直接的解決辦法。
各平台開啟方法與權限要求
SECTION / PLATFORM SETUPTUN 模式因為需要建立虛擬網卡、修改系統路由表,在三大平台上都要求更高的權限,細節各不相同。
Windows 上建立虛擬網卡依賴 Wintun 驅動程式,主流用戶端(Clash Verge、Clash for Windows 衍生版)會在安裝或首次啟用 TUN 時自動安裝該驅動程式。啟用步驟:
- 以系統管理員身份執行用戶端(在圖示上按右鍵選擇「以系統管理員身份執行」,或在設定中開啟「開機時以系統管理員權限啟動」)。
- 在設定面板中找到 TUN 模式開關並啟用,首次啟用時系統會彈出驅動程式安裝或網路介面卡授權提示,點選允許。
- 若系統防火牆攔截了虛擬網卡的出站規則,需要在 Windows Defender 防火牆中手動放行該驅動程式對應的網路類別(通常首次彈出視窗時選擇「私人網路」即可)。
未以系統管理員權限執行,是 Windows 上 TUN 模式無法開啟的最常見原因,表現為開關打開後又自動彈回。
macOS 上建立 utun 裝置需要 root 權限或系統網路延伸功能授權,現代用戶端多採用系統網路延伸功能(System Extension)方式,避免每次都要輸入密碼:
- 首次開啟 TUN 模式時,系統會彈出「系統延伸功能被封鎖」的提示。
- 前往「系統設定 → 隱私權與安全性 → 網路延伸功能」,找到用戶端對應的延伸功能項目並允許。
- 部分用戶端仍採用傳統方式,需要在設定中授權「以系統管理員權限執行核心」,輸入一次系統密碼後,由背景程序長期持有權限。
如果開啟後在網路延伸功能列表中找不到項目,通常是系統安全性原則攔截了安裝,可重新啟動用戶端或系統後再試一次。
Linux 上建立 tun0 裝置需要 CAP_NET_ADMIN 權限,最簡單的方式是以 root 身份執行核心處理程序,或為二進位檔案單獨授予該權限:
sudo modprobe tun
sudo setcap cap_net_admin=eip /path/to/mihomo使用 setcap 方式的好處是不必以 root 身份啟動整個用戶端,只讓核心處理程序取得網路管理權限,更符合最小權限原則。圖形化用戶端(例如部分基於 GTK/Qt 的封裝)通常在設定中提供「授權 TUN」按鈕,底層執行的正是上述命令。
TUN 模式賦予用戶端接管全域路由的能力,請務必只從官方管道取得用戶端並核對下載來源,不要為來源不明的程式授予系統管理員權限或 CAP_NET_ADMIN。
DNS 處理:fake-ip、劫持與路由迴圈
SECTION / DNS BEHAVIOR開啟 TUN 模式後,DNS 查詢同樣會被虛擬網卡攔截,這也是 TUN 模式下最容易出問題的環節。設定檔中通常需要明確宣告 DNS 劫持與解析策略:
tun:
enable: true
stack: system
dns-hijack:
- "any:53"
auto-route: true
auto-detect-interface: true
dns:
enable: true
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 1.1.1.1dns-hijack 表示把所有對外的 53 連接埠 DNS 請求強制攔截並交給 Clash 核心處理,避免繞過規則直連境外或遭污染的 DNS 伺服器。fake-ip 模式則為每個網域名稱分配一個位於私有網段內的假 IP,應用程式端看到的是這個假 IP,真正建立連線時才由核心換成實際出口,好處是能依網域名稱比對規則,而不必等待真實解析結果。
常見問題排查方向:
- DNS 洩漏。如果發現直連流量的 DNS 請求沒有被攔截(例如瀏覽器仍在使用系統原生 DNS),請檢查 dns-hijack 是否涵蓋了對應連接埠,以及系統網路設定裡是否手動指定了固定 DNS 伺服器導致衝突。
- 路由迴圈。 TUN 模式下,代理節點伺服器本身的連線不能再經過 TUN 網卡,否則會形成「代理連線自己」的死迴圈。用戶端通常透過 auto-detect-interface 或明確排除處理程序規則來避免這個問題,手動設定時務必確認該項已開啟。
- 與 VPN 用戶端衝突。同時執行 TUN 模式與其他 VPN 軟體,兩者都會爭奪預設路由,表現為其中一方間歇性失效,建議兩者不要同時啟用。
驗證 TUN 模式是否已生效
SECTION / VERIFICATION開啟 TUN 模式後,建議依以下順序驗證,而不是僅憑用戶端開關狀態判斷:
- 檢查虛擬網卡是否存在。 Windows 下開啟「網路連線」查看是否新增名稱類似「Mihomo」「Clash」字樣的介面卡;macOS/Linux 下執行 ifconfig 或 ip addr 查看是否出現 utun / tun0 裝置。
- 檢查預設路由。Windows 用 route print,macOS/Linux 用 netstat -rn 或 ip route,確認預設路由已指向虛擬網卡而非實體網卡。
- 用不遵循系統代理的工具做測試。例如在終端機中執行 curl 而不帶任何代理參數,或直接用命令列 Ping 一個被規則判定為「需要代理」的網域,觀察是否命中預期出口。
- 查看用戶端的連線記錄。多數用戶端在「連線」或「記錄」面板裡會標註每條連線的入站類型,TUN 模式下的連線通常標記為 TUN 而非 HTTP/SOCKS,可用來確認具體是哪條連結生效。
如果以上檢查全部通過,但某個具體應用程式仍未走代理,大機率是該應用程式在系統層面綁定了固定網路介面或使用了自訂 DNS,需要單獨排查該程式的網路設定,而非繼續調整 Clash 設定。