本文目錄
瀏覽器正常、終端機卻沒有連線記錄，與請求已經出現、網域規則卻未生效，需要修改的不是同一項設定。前者要看流量如何進入用戶端，後者核對實際網域、解析結果與規則；節點或服務本身失敗，也不能靠擴大接管範圍解決。分清這些情況，才能判斷何時使用虛擬網卡、何時只為一個內部網域設定例外。
系統代理與 TUN 怎樣接管應用流量？
開啟系統代理時，Clash 把本機代理位址寫進作業系統，願意讀取這項設定的應用再把 HTTP、HTTPS 請求發到該連接埠。瀏覽器通常會使用它，終端工具、遊戲和部分桌面應用可能不使用；系統代理本身也不能統一接管 UDP。
TUN 建立虛擬網路介面卡，透過系統路由讓更多 TCP、UDP 連線進入 Mihomo。它解決「這個處理程序沒有走本機代理連接埠」的問題，但不會改變節點可用性、規則順序或伺服器端回傳的 403。
兩種入口的核心差別
| 項目 | 系統代理 | TUN |
|---|---|---|
| 誰決定進入 Clash | 應用是否讀取系統設定 | 系統路由與虛擬網路介面卡 |
| UDP | 通常不接管 | 可以進入 TUN，仍取決於節點和設定 |
| 系統權限 | 修改代理設定 | 還需虛擬網路介面卡、服務或網路擴展權限 |
| 還原 | 關閉代理開關即可 | 關閉 TUN，並等待路由和介面撤回 |
- 應用發起連線瀏覽器、終端、遊戲或背景服務
- 系統代理或 TUN決定這條流量能否進入核心
- 規則與 DNS保留網域並決定直連或代理
- 實際出口DIRECT、代理節點或拒絕
系統代理或 TUN 負責把流量送入核心，之後走直接連線還是代理節點，仍由規則、DNS 結果和策略群組共同決定。
用 Connections 判斷應用是否需要 TUN
用同一動作做前後對照
固定 Profile、Rule 模式和節點
避免入口測試被自動切換或設定更新干擾。
只開系統代理
在目標程式裡重複一個固定動作。
查看 Connections
若請求已經出現，說明它已進入用戶端，繼續查看規則和日誌。
無記錄時再開 TUN
重做同一動作，比較是否出現新連線。
TUN 後新連線出現並成功，說明它補上了接管範圍。兩種入口下都能看到請求，卻同樣 timeout，問題應放在節點、DNS 或目標網路，而不是繼續切換入口。
auto-route、出口網路介面卡與 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:53網域規則失效時，檢查 DNS 是否進入 Mihomo
DNS 把網域轉換成連線使用的位址。如果解析請求繞過 Mihomo，核心可能只看到 IP，無法按預期匹配網域規則；解析結果也可能與代理出口不一致，導致首頁能開、圖片失敗或連線時好時壞。
dns-hijack 把符合條件的 DNS 流量交給 Mihomo 內部 DNS，但並非在所有系統上自動生效：Windows、macOS 無法自動劫持發往區域網路 DNS 伺服器的查詢，要核對實際系統 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 上游和日誌 |
redir-host 與單網域 fake-ip-filter 例外
有些企業軟體、區域網路服務或裝置發現功能會直接使用 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 與企業內部網路分別適合哪種方式？
按使用情境選擇
| 使用情境 | 建議起點 | 理由 |
|---|---|---|
| 主要是網頁和遵循系統代理的桌面軟體 | 系統代理 | 權限少、容易關閉、連線路徑清楚 |
| 終端、遊戲啟動器沒有 Connections 記錄 | 應用代理或 TUN 對照 | 補上不讀取系統代理的處理程序 |
| 需要處理 UDP 的應用 | TUN | 系統代理無法統一接管 UDP |
| 企業內部網路、虛擬機和複雜區域網路 | 系統代理起步 | 先保留原路由，再逐項驗證 TUN 排除範圍 |
| 某網域規則走錯 | 任一已有入口 + 修規則 | 入口擴大不會改變第一條命中規則 |
選擇不是永久的。日常只需瀏覽器時可以關閉 TUN，回到系統代理；需要特定程式時再開啟。切換後都用原目標動作和 Connections 驗證，而不是只看開關顏色。
關閉 TUN、恢復系統代理與處理殘留連接埠
若剛開 TUN 就全斷，先關閉 TUN，保留原 Profile 與節點。系統代理恢復，說明故障在虛擬網路介面卡、路由或 TUN 的 DNS；系統代理也失敗，再回到節點和設定。不要直接使用作業系統的網路重置，它會清掉更多無關設定。
關閉用戶端後網頁仍打不開時，檢查系統代理是否殘留在 127.0.0.1 的舊連接埠；清除後，用原本可直連的目標驗證恢復。