TUN 與系統代理：流量接管位置不同
瀏覽器可以上網，但終端機、遊戲或某個桌面應用程式卻連不上，常見原因是該應用程式沒有讀取系統代理設定。系統代理主要是告知支援代理的應用程式：將請求交給指定的 HTTP 或 SOCKS 入口。若應用程式自行建立連線、忽略代理設定，或使用未涵蓋於該入口的 UDP 通訊，只開啟系統代理通常不夠。
TUN 會在系統中建立三層虛擬網路介面，再透過路由將符合條件的 IP 封包送進核心。mihomo 收到資料後，會根據目標位址、網域資訊與規則判斷要直連或代理。因此，應用程式通常不必另外填寫代理位址，但核心必須具備建立介面及修改路由的權限。
| 比較項目 | 系統代理 | TUN 模式 |
|---|---|---|
| 接管入口 | 應用程式透過代理通訊協定連線至監聽連接埠 | 系統路由將 IP 封包送入虛擬介面 |
| 應用程式相容性 | 需要應用程式支援或手動設定 | 通常不要求應用程式識別代理設定 |
| 權限 | 通常不需要建立網卡的權限 | 桌面版通常需要管理員、root 或已授權的服務 |
| UDP | 視應用程式與代理入口而定 | 可以接管，但代理節點與通訊協定也必須支援 |
| 涵蓋範圍 | 未使用代理的連線可能會繞過 | 會受路由、排除項目、IPv6 及其他 VPN 影響 |
啟用前：先確認核心、節點與復原方式
「Clash 用戶端」是介面名稱，不代表內建核心都相同。本文 YAML 適用於 mihomo，不應直接視為所有原版 Clash 或舊版 Premium 核心的通用設定。請先在用戶端的「關於」或「核心資訊」中確認實際使用的核心；若是獨立執行，可查看版本輸出：
mihomo -v
mihomo -t -f config.yaml第二條命令會檢查目前核心能否解析設定，但無法證明節點可用或路由正確。若命令顯示找不到程式，請使用實際執行檔路徑；在 Windows PowerShell 中，目前目錄下的程式通常寫作 .\mihomo.exe。
- 保留目前可用的設定與覆寫檔。訂閱更新可能會覆蓋直接修改訂閱檔的內容，建議優先使用用戶端提供的合併或覆寫功能。
- 先在系統代理模式下確認節點可用。至少測試一次網頁瀏覽；若需要遊戲、語音或 QUIC，再確認節點是否支援 UDP。
- 暫停其他 VPN、網路加速器與舊版代理核心。首次測試時，不要讓兩套工具同時修改預設路由。
- 記下關閉 TUN 的操作入口。若要遠端管理伺服器，請先準備主控台或其他復原管道，避免路由變更中斷唯一的 SSH 連線。
mihomo TUN 基本設定與欄位說明
以下是要加入現有可用設定的頂層片段，並非包含節點與策略群組的完整訂閱。若已有 tun 或 dns 區段，請合併欄位，不要重複新增同名頂層索引鍵。首次驗證先只處理 IPv4，確認連線正常後再單獨檢查 IPv6。
mode: rule
log-level: info
ipv6: false
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 1.1.1.1此處的兩個 DNS 位址僅用來示範一般 DNS 上游的寫法，請依所在網路的可連線性調整；一般 DNS 查詢並非加密傳輸。若已有完善的 DNS 分流與節點網域解析設定，請保留原有設計，不要整段換成這份入門範例。
| 欄位 | 用途與檢查重點 |
|---|---|
enable | 要求啟動 TUN；是否成功仍須檢查權限、介面與記錄檔。 |
auto-route | 自動設定將流量導入 TUN 的路由，不代表所有排除路徑都會消失。 |
auto-detect-interface | 自動辨識實際的出站網卡。有多張網卡或其他 VPN 時，請確認辨識結果。 |
dns-hijack | 範例會攔截進入 TUN、目標連接埠為 53 的 UDP DNS；不代表能攔截所有加密 DNS。 |
listen | 本機 DNS 監聽位址；1053 是範例連接埠，不是要求系統 DNS 使用的連接埠。 |
fake-ip-range | 配置用於網域對應的位址；應用程式取得這些位址後，仍須由核心處理。 |
198.18.0.1/16 所屬的位址範圍用於基準測試，不是真實遠端網站的 IP，也不是一般公網節點位址。若應用程式快取了 Fake-IP，關閉核心後仍繼續使用快取，可能會暫時無法連線；請關閉相關應用程式並清除 DNS 快取後再測試。
stack 怎麼選：system、gvisor、mixed
system：主要使用系統網路堆疊處理連線。適合先依用戶端建議值測試，但實際表現會受到作業系統與網路環境影響。gvisor：使用使用者空間網路堆疊。遇到特定應用程式的相容性問題時，可作為對照方案，但不能因此直接推論效能更快或更穩定。mixed：TCP 使用 system 路徑，UDP 使用 gVisor 路徑。這是混合處理方式，並非同時執行兩份代理設定。
不同平台與核心版本對 stack 的支援及限制可能有所不同。修改後請先檢查設定，再查看啟動記錄。不要一次同時更換 stack、DNS 上游與節點，否則即使恢復連線，也很難判斷是哪項變更生效。
Windows：先授予核心建立網卡的權限
- 結束其他代理用戶端，確認目前節點在一般系統代理模式下可正常使用。
- 若用戶端提供服務模式，請依介面指示安裝並啟動服務；若沒有服務模式，在確認程式來源可信的前提下，可用系統管理員身分啟動用戶端進行一次測試。
- 在用戶端的 TUN 設定中啟用虛擬網卡接管，再查看記錄是否顯示介面建立成功、路由設定成功或明確的失敗原因。不同用戶端的選單名稱不盡相同，不要只憑開關顏色判斷是否成功。
- 按下 Win + R，輸入
ncpa.cpl查看網路介面卡；介面名稱由用戶端或設定決定，不一定會叫做 Clash。
驗證時先關閉用戶端的系統代理開關，只保留 TUN，避免瀏覽器仍透過系統代理連線，掩蓋 TUN 故障。可前往 Windows 11「設定」→「網路和網際網路」→「Proxy」確認手動 Proxy 狀態；受機構管理的裝置請勿擅自變更組織政策。
route print
ipconfig /all
curl.exe --noproxy "*" -I https://example.comroute print 可用來查看路由，但不一定會出現指向 TUN 的傳統預設路由：實作也可能透過更具體的網段進行接管。測試時也要查看用戶端的連線清單，確認請求已進入核心並符合預期策略。單獨收到 HTTP 回應只能證明目標可連線，不能證明流量經過代理節點。
macOS 與 Linux：檢查授權、路由與 DNS
macOS 啟用步驟
- 請使用支援 mihomo TUN 的用戶端，依介面提示安裝或授權輔助服務。一般使用者程序通常無法直接完成所有網路設定操作。
- 啟用 TUN 後查看記錄，再於終端機執行
ifconfig和netstat -rn。系統中可能已有多個utun介面；看到 utun 並不能單獨證明它屬於目前使用的用戶端。 - 前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」，確認是否仍保留舊的手動代理設定。實際選項名稱會因系統版本而異。
- 關閉系統代理，使用未設定明確代理的應用程式建立新連線，並在核心連線清單中交叉確認。
若網頁正常，但無法存取區域網路裝置，請先檢查區域網路流量符合的規則與路由，再判斷是否需要調整排除網段。不要把整個內網無法透過代理存取誤判為 DNS 故障。
Linux 啟用步驟
Linux 通常需要 root 或相應的網路管理權限，且系統必須提供 TUN 裝置。請先檢查 /dev/net/tun 是否存在；容器與精簡系統也可能限制裝置存取，即使程序以 root 執行，也不一定能建立介面。
ls -l /dev/net/tun
mihomo -t -f config.yaml
sudo mihomo -f config.yaml
# 在另一個終端機檢查
ip link
ip rule
ip route show table all
resolvectl status在前景啟動，方便觀察首次失敗發生在哪個步驟。長期執行時應使用受控的服務設定；不要為了排除問題而批次授予整個目錄中程式的權限。resolvectl 適用於使用 systemd-resolved 的系統，其他發行版則需確認實際採用的 DNS 管理方式。
Android 與 iOS：使用系統 VPN 授權
Android 用戶端通常透過系統 VPN 介面接管流量。首次連線時請確認 VPN 授權，再檢查用戶端的應用程式排除或分應用程式代理設定。即使已開啟 TUN，被排除的應用程式也不會自動進入規則處理流程。可前往 Android「設定」→「網路和網際網路」→「VPN」查看目前連線；部分廠牌系統的入口可能位於「連線與分享」。
Android 在同一使用者或工作資料夾中通常只能維持一個作用中的 VPN 服務。本機防火牆、廣告過濾工具與其他 VPN 可能會爭用這個介面。若設定了「一律使用 VPN」或「封鎖未使用 VPN 的連線」，關閉用戶端前請先了解可能造成的斷網情況。Android 私人 DNS 使用加密通道，也不能假設會被 53 埠劫持規則攔截。
iOS 請使用支援相應設定的用戶端，並透過系統 VPN 授權建立通道。可在「設定」→「一般」→「VPN 與裝置管理」確認狀態。iOS 用戶端未必使用 mihomo，也未必接受上述 YAML 欄位；請以該應用程式的設定格式為準，不要將桌面版設定原封不動匯入並視為通用步驟。
DNS、IPv6 與 UDP：三個容易忽略的檢查項目
攔截 53 埠不涵蓋 DoH、DoT
範例中的 any:53 用於處理一般 UDP DNS。DNS over TLS 通常使用 TCP 853 埠，DNS over HTTPS 通常使用 HTTPS 的 443 埠；僅靠這項設定，兩者都不會自動轉為由核心處理的 DNS 查詢。排除問題時，可暫時關閉瀏覽器的安全 DNS 進行比對，確認後再決定最終的解析方案。
測試時應分別確認「網域能否解析」及「連線是否進入核心」。例如 nslookup example.com 可協助查看解析結果，但不能證明特定瀏覽器使用相同的解析路徑。網域規則是否符合，也取決於核心能否取得該連線對應的網域資訊。
停用 AAAA 回應不等於停用系統 IPv6
範例中的 IPv6 設定是為了簡化初次診斷，並非系統層級的防繞過保證。應用程式仍可能使用快取的 IPv6 位址、IP 字面位址或其他解析器。若需要 IPv6，應一併檢查核心 IPv6 設定、TUN 路由、DNS 回應與節點能力；若不需要，也應確認系統沒有未涵蓋的 IPv6 路徑。
成功接管 UDP，也需要可用的出站連線
語音或遊戲無法使用時，請先查看連線清單是否出現對應的 UDP 工作階段，再確認規則選取的節點是否支援 UDP。瀏覽器的 QUIC 也使用 UDP；網頁可透過 TCP 備援連線開啟，不代表 UDP 連線正常。不要以一次網頁測速取代遊戲或語音應用程式本身的測試。
常見故障：依序檢查權限、路由、DNS 與出站連線
| 現象 | 優先檢查 | 下一步 |
|---|---|---|
| 開啟後立刻關閉 | 設定解析錯誤、服務未啟動、權限不足 | 執行設定檢查，查看第一筆介面建立錯誤。 |
| 啟用後完全無法連線 | 選錯出站介面、其他 VPN 衝突、節點無法連線 | 關閉 TUN 以恢復網路，再只保留一個接管工具。 |
| IP 可連線，但網域無法使用 | DNS 上游無法連線、監聽埠衝突、解析路徑未被接管 | 確認 1053 監聽狀態與 DNS 記錄，不要先更換所有規則。 |
| 網頁正常但遊戲無法使用 | UDP 出站、規則策略、應用程式排除項目 | 檢查 UDP 工作階段及實際選取的節點。 |
| 切換 Wi-Fi 後無法連線 | 出站介面與路由未隨網路變更更新 | 重新啟動 TUN 工作階段，查看是否重新辨識實體網卡。 |
| 關閉後仍無法上網 | 殘留的系統代理、路由、Fake-IP 快取 | 先結束用戶端，再檢查代理與路由，最後清除快取。 |
只有在確認 MTU 可能是原因時才單獨調整。常見情況是小型請求正常，但大型回應或特定網站卡住；不過也可能是節點或網路鏈路問題。可先記下原值，再以 mtu: 1400 進行對照測試；此數值僅供診斷起步使用，不是所有寬頻、行動網路及 VPN 疊加情境的最佳值。
確認是 DNS 快取問題後，Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 sudo resolvectl flush-caches。清除快取無法取代修復錯誤路由，也無法解決節點失效。排除問題後，請將暫時提高的記錄層級恢復為 info；分享記錄前，請移除訂閱網址、權杖及其他敏感資訊。
完成標準：以同一條連線驗證整個流程
- 關閉系統代理與應用程式內的明確代理設定，建立一條全新連線。
- 在核心中找到該連線，確認目標、TCP 或 UDP 類型、符合的規則及出站策略。
- 分別測試一個應直連的目標與一個應走代理的目標，避免只測單一網頁。
- 檢查區域網路存取、網路切換，以及關閉 TUN 後能否恢復。
通過這四個步驟，才能確認流量接管、規則與出站連線大致正常。之後再加入 IPv6、應用程式排除或更細緻的路由設定，每次只修改一項並保留復原紀錄。欄位延伸說明請參閱設定大全中的 TUN 設定與DNS 設定。