本文目錄
系統代理等應用主動交流量，TUN 在系統網路層接住流量
開啟系統代理時，Clash 把本機代理位址寫進作業系統，願意讀取這項設定的應用再把 HTTP、HTTPS 請求發到該連接埠。瀏覽器通常會使用它，終端工具、遊戲和部分桌面應用可能不使用；系統代理本身也不能統一接管 UDP。
TUN 建立虛擬網路介面卡，透過系統路由讓更多 TCP、UDP 連線進入 Mihomo。它解決「這個處理程式沒有走本機代理連接埠」的問題，但不會改變節點可用性、規則順序或伺服器端回傳的 403。
兩種入口的核心差別
| 專案 | 系統代理 | TUN |
|---|---|---|
| 誰決定進入 Clash | 應用是否讀取系統設定 | 系統路由與虛擬網路介面卡 |
| UDP | 通常不接管 | 可以進入 TUN，仍取決於節點和設定 |
| 系統權限 | 修改代理設定 | 還需虛擬網路介面卡、服務或網路擴展權限 |
| 還原 | 關閉代理開關即可 | 關閉 TUN，並等待路由和介面撤回 |
- 應用發起連線瀏覽器、終端、遊戲或背景服務
- 系統代理或 TUN決定這條流量能否進入核心
- 規則與 DNS保留網域並決定直連或代理
- 實際出口DIRECT、代理節點或拒絕
入口只負責接住流量。真正走哪個出口，仍由規則、DNS 結果和策略群組共同決定。
判斷入口，只看原來失敗的程式有沒有連線記錄
用同一動作做前後對照
固定 Profile、Rule 模式和節點
避免入口測試被自動切換或設定更新干擾。
只開系統代理
在目標程式裡重複一個固定動作。
查看 Connections
若請求已經出現，入口沒有缺失，繼續讀規則和日誌。
無記錄時再開 TUN
重做同一動作，比較是否出現新連線。
TUN 後新連線出現並成功，說明它補上了接管範圍。兩種入口下都能看到請求，卻同樣 timeout，問題應放在節點、DNS 或目標網路，而不是繼續切換入口。
auto-route、interface 和 stack 共同決定資料怎麼穿過虛擬網路介面卡
Mihomo 的 auto-route 用來把流量路由到 TUN，auto-detect-interface 用來識別實際出口網路介面卡。stack 可選 system、gvisor 或 mixed 等實作；預設值能覆蓋目標應用時，不需要為了「更快」隨意更換。
從 Wi-Fi 切到熱點後突然沒網，可能是出口網路介面卡變化；只有 system 或 mixed 在某台電腦被防火牆攔，才針對核心處理程式調整防火牆。Windows 的 strict-route 還可能影響 VirtualBox 等虛擬網路，使用虛擬機時要單獨驗證。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53DNS 覆寫要把解析請求送進同一條判斷路徑
應用先把網域解析成位址，再建立連線。如果 DNS 請求繞過 Mihomo，核心可能只看到 IP，網域規則無法按預期工作；也可能得到與代理出口不匹配的解析結果，表現為首頁能開、圖片失敗或同一服務時好時壞。
dns-hijack 用來把匹配的 DNS 流量交給 Mihomo 內部 DNS。它並非在所有系統和所有來源上自動生效：Windows、macOS 無法自動劫持區域網路其他裝置的 DNS，請求來自路由器或手機時要單獨設定；Android 私人 DNS也會繞過普通劫持路徑。
- Connections 有網域且規則正確
- DNS 與嗅探至少提供了可用於規則判斷的資訊。
- 只看到 IP，網域規則不命中
- 檢查 DNS 是否進入 Mihomo，以及應用是否使用加密 DNS。
- IP 能存取，網域報解析錯誤
- 重點比較系統 DNS、Mihomo DNS 和目前網路。
Fake-IP 的作用是保留網域關係，不是憑空加速
在 fake-ip 模式下，Mihomo 先向應用回傳一段保留位址，並在內部儲存「這個假位址對應哪個網域」。應用連線該位址時，核心可以恢復原網域，較早做 DOMAIN、DOMAIN-SUFFIX 和 RULE-SET 判斷。
這種方式不會讓 DNS 自動變快，也不會改變遠端節點品質。某些區域網路服務、裝置發現、企業軟體或直接驗證 IP 的程式可能不相容，需要按具體網域加入 fake-ip-filter，或在驗證後選擇其他 DNS 增強模式。
Fake-IP 常見結果
| 表現 | 解釋 |
|---|---|
| 系統查詢得到保留位址 | 可能是正常的 fake-ip 映射，不代表網域被劫持 |
| Connections 能顯示原網域 | 映射幫助核心按網域規則判斷 |
| 某個內部網路網域在 fake-ip 下失敗 | 把準確網域排除並讓內部 DNS 解析 |
| 所有網站都慢 | 不能僅憑 fake-ip 下結論，繼續看節點、DNS 上游和日誌 |
需要實際 IP 的應用，用 redir-host 或準確的 Fake-IP 例外
有些企業軟體、區域網路服務或裝置發現功能會直接使用 DNS 回傳的實際位址，不適合拿到 Fake-IP。此時可以讓整份設定使用 redir-host，也可以只把明確不相容的網域加入 fake-ip-filter；前者改變所有網域的解析方式，後者影響範圍更小。
redir-host 更接近普通 DNS，應用直接拿到上游回傳的實際 IP；代價是 Mihomo 不一定像 Fake-IP 那樣早地保留網域映射，網域規則識別還會受用戶端、快取與嗅探設定影響。不要因為一個內部網路網域失敗就把全站切換，先做單網域例外。
需要實際 IP 時怎麼選
| 情境 | 更合適的處理 | 驗證結果 |
|---|---|---|
| 只有一個企業內部網路網域失敗 | 加入準確的 fake-ip-filter，並使用內部 DNS | 回傳內部網路實際 IP，連線命中 DIRECT |
| 一類應用普遍不相容 Fake-IP | 用 redir-host 做單獨設定對照 | 應用恢復，公用網路網域規則仍能正確命中 |
| NAS、印表機使用固定私有 IP | 保留私有網段 DIRECT | 存取不再繞到代理策略 |
| 不知道哪個網域不相容 | 先從 Connections 與 DNS 日誌找目標 | 確認對象後再加例外，不使用大範圍通配 |
DNS 檢查需要保留一個不變的請求
遇到網域問題，固定節點和請求，先記錄目前 enhanced-mode、上游 DNS 與錯誤。只改一個變數做對照：例如把某個明確不相容的內部網域加入 fake-ip-filter，或臨時切換 Android 私人 DNS 狀態。結果有變化，再保留這項改動。
no such host / DNS lookup failed
檢查上游 DNS 可達性和請求是否進入 Mihomo。
區域網路網域失效，公用網路網域正常
保留內部 DNS 路徑，並為準確網域設定直連或 Fake-IP 排除。
切網路後才解析異常
比較兩張網路的 DNS、IPv6 和出口介面，不要先換所有節點。
網域規則始終顯示 MATCH
查看核心是否拿到網域，以及更寬規則是否提前命中。
瀏覽器使用者從系統代理開始，需要 UDP 或補漏再用 TUN
按使用情境選擇
| 使用情境 | 建議起點 | 理由 |
|---|---|---|
| 主要是網頁和遵循系統代理的桌面軟體 | 系統代理 | 權限少、容易關閉、連線路徑清楚 |
| 終端、遊戲啟動器沒有 Connections 記錄 | 應用代理或 TUN 對照 | 補上不讀取系統代理的處理程式 |
| 需要處理 UDP 的應用 | TUN | 系統代理無法統一接管 UDP |
| 企業內部網路、虛擬機和複雜區域網路 | 系統代理起步 | 先保留原路由，再逐項驗證 TUN 排除範圍 |
| 某網域規則走錯 | 任一已有入口 + 修規則 | 入口擴大不會改變第一條命中規則 |
選擇不是永久的。日常只需瀏覽器時可以關閉 TUN，回到系統代理；需要特定程式時再開啟。切換後都用原目標動作和 Connections 驗證，而不是只看開關顏色。
斷網時按 TUN、DNS、系統代理的順序撤回
若剛開 TUN 就全斷，先關閉 TUN，保留原 Profile 與節點。系統代理恢復，說明故障在虛擬網路介面卡、路由或 TUN 的 DNS；系統代理也失敗，再回到節點和設定。不要直接使用作業系統的網路重置，它會清掉更多無關設定。
若關閉用戶端後網頁仍打不開，檢查系統代理是否殘留在 127.0.0.1 的舊連接埠。清掉殘留後應恢復直連。選擇可以落到實際結果上：系統代理負責瀏覽器，TUN 接住原來漏掉的處理程式，DNS 模式讓目標網域穩定命中預期規則。哪一層沒有帶來需要的結果，就不要長期保留。