OpenWrt 旁路由跑 mihomo：透明閘道與 DNS 重新導向一步步設定

這篇適合誰？與「桌機裝 Clash」差在哪？

若您已有一台軟路由或旁路網關（同一區網內第二台路由器／小主機），想讓電視、手機、筆電不必逐台設定代理，就能依規則全屋走 mihomo，同時避免DNS 污染或「規則看起來對、實際分流卻怪」的情況，本文以 OpenWrt 為作業系統、以 mihomo（Clash Meta 核心）為代理後端，整理可照做的順序。

這與在 Ubuntu 或 Windows 上開圖形用戶端不同：旁路方案要把預設閘道與DNS 請求導到旁路機器，並讓核心以透明代理或 TUN 接管流量；任一環節漏接，就會出現「只有瀏覽器通」「區網裝置仍走電信 DNS」等現象。您若也在桌機除錯過類似問題，可先對照本站 系統代理與 TUN 排查 的概念，再回到閘道層級收斂。

步驟一：拓樸與 IP 規劃（先畫清楚再走線）

典型旁路接法是：主路由的 LAN 接到旁路 OpenWrt 的 WAN（或單埠改為 LAN 橋接的一員），旁路取得與主路由同網段的 IP，例如主路由 192.168.1.1、旁路 192.168.1.2。全屋代理的關鍵，是讓內網客戶端的預設閘道與DNS指向 192.168.1.2（或您實際規劃的旁路位址），而不是只改瀏覽器 PAC。

請先決定兩件事：第一，誰發 DHCP？多數家庭仍以主路由發 DHCP較省事，此時在主路由後台設定選項 3（閘道）與選項 6（DNS）指向旁路 IP；若改由旁路發 DHCP，要避免與主路由衝突並留意雙 DHCP。第二，旁路是否再做一次 NAT？純旁路常見設定是關閉旁路 WAN 區的 NAT或將旁路視為同層二層／三層轉發的一環，否則容易形成雙層 NAT，除錯與埠轉發會變複雜。

步驟二：OpenWrt 基本網路與防火牆區域

登入 LuCI 後，確認旁路 WAN（或 uplink 介面）能取得正確的閘道與 DNS。若您把 OpenWrt 當「同網段的一台主機」，請避免讓 LAN 介面與 uplink 網段重疊同一子網卻未橋接，否則會出現路由迴圈或 ARP 異常。防火牆方面，需允許區網客戶端對旁路的代理埠與DNS 埠入站；若您啟用 Allow LAN 類概念於 mihomo，仍須確保 OpenWrt 的 INPUT 鏈不會擋掉轉送後的查詢。

與「單機分享代理」相關的埠、混合埠、綁定位址觀念，可延伸閱讀本站 Allow LAN 與防火牆排查；差別在於本文場景的「客戶端」是整個子網，旁路機器承擔閘道角色時，防火牆錯誤會放大成全屋斷線。

步驟三：安裝 mihomo 或 OpenClash（訂閱與設定檔）

完成網路後，再安裝核心。若使用 OpenClash：於軟體來源安裝依賴後安裝套件，啟用後匯入訂閱網址或本機設定檔，並確認核心程式能正常啟動。訂閱與多設定檔切換的通用觀念，請參考本站 訂閱匯入教學；規則與國內外分流骨架則可對照 規則分流專文。

此階段請先以「旁路本機」測試：在 OpenWrt 上透過 curl 或 LuCI 的網路診斷，確認訂閱更新成功、節點延遲測試合理。若核心尚未穩定，後續透明代理只會把失敗放大到全屋。

步驟四：透明代理（REDIRECT、TPROXY 或 TUN）

透明代理的目標，是讓不支援 HTTP 代理的程式（例如部分遊戲、IoT）也能被導流進 mihomo。常見實作有兩類：一是 iptables／nftables REDIRECT 將 TCP 轉到本機 redir-port；二是 TUN 介面由核心直接接管路由表內的流量。兩者對核心能力與設定檔（tun、auto-route 等）要求不同。

在旁路拓樸下，若使用 TUN，需特別注意預設路由是否由旁路發布、以及是否與主路由的內網網段衝突；錯誤的 auto-route 可能導致「旁路自己斷線」或「區網互訪失效」。若您剛開始部署，建議先採用 LuCI 套件提供的混合／相容模式或文件建議的轉發順序，再進階調整。更多 TUN 觀念可參考本站 TUN 模式指南。

透明代理啟用後，請用內網第二台裝置（不要只用 OpenWrt 本機）開啟一般網頁與 HTTPS，觀察 mihomo 日誌是否出現對應連線；若仍無紀錄，代表流量未經過旁路轉發，應回到閘道與 DHCP 設定，而非先調規則。

步驟五：DNS 重定向與 fake-ip／redir-host 對齊

只改閘道不改 DNS，常見後果是：網頁看似可走代理，但解析仍被電信或本地 DNS污染，導致分流規則永遠對不到正確網域，或出現「部分站點怎樣都繞不過」。因此旁路方案幾乎一定要做DNS 重定向：要嘛讓 DHCP 直接把 DNS 指到旁路，要嘛在旁路以 dnsmasq 將查詢轉發到 mihomo 監聽埠，要嘛以防火牆將 53 導向核心（視您套件提供的精靈與防火牆規則而定）。

在 mihomo 設定中，fake-ip 與 redir-host 會影響透明代理與嗅探行為；若您啟用 fake-ip，請確保內網客戶端查詢都經過核心 DNS，否則會出現「解析到假位址卻無對應連線」的錯亂。若串流或遊戲異常，可對照本站 Sniffer 與串流網域規則 的除錯順序，但仍以 DNS 全量進核心為前提。

dnsmasq 轉發思路（示意）

在 OpenWrt 的 DHCP 與 DNS 設定中，常見作法是將上游 DNS 設為 127.0.0.1#核心監聽埠，並視需要加入重新綁定保護或忽略解析檔類選項，避免 dnsmasq 與核心搶同一埠。實際選項名稱請以您版本為準；重點是區網所有查詢最終要落到 mihomo 的 DNS 模組，而不是只改瀏覽器 DoH。

步驟六：DHCP 選項與全屋驗證清單

完成閘道、透明代理、DNS 後，用下列順序驗證：一、客戶端取得的預設閘道是否為旁路 IP；二、客戶端使用的DNS 伺服器是否為旁路 IP（或以旁路為上游）；三、在客戶端執行 nslookup 或 dig 觀察回傳是否與 fake-ip 設定一致；四、開啟需代理的 HTTPS 網站並同時檢視核心日誌的規則命中。

若僅特定裝置異常，請檢查該裝置是否手動指定 DNS（例如硬寫 8.8.8.8）、是否使用私人轉送（Apple 類功能）、或是否走 IPv6 繞過您的規則；IPv6 若未一併規劃，可能形成「看似一半流量沒進代理」的錯覺。

常見症狀對照

• 全屋無法上網：優先檢查旁路是否誤設預設閘道指向自己、或主路由是否仍把閘道指回自己卻關閉了轉發。
• 只有部分網站通：多半是 DNS 仍分流到外部，或規則被 MATCH 提前帶走；請對照 DNS 與分流排查 中的「置前規則」觀念。
• 延遲正常但串流地區錯誤：多為解析或 SNI 與節點地區不一致，需同時查 DNS、嗅探與策略。

結語

OpenWrt 旁路由跑 mihomo，本質是把「單機代理」擴展成「閘道級策略引擎」：透明代理解決應用程式不支援代理的問題，DNS 重定向則決定規則能否拿到正確的網域名稱。兩者與 DHCP／閘道設定同一條鏈，缺一即會變成難查的間歇性故障。

相較於只在單一桌面反覆切換系統代理，把家庭網路的預設閘道與 DNS收斂到可信的旁路裝置，長期維護成本通常更低。若您同時也需要 Windows 或 macOS 用戶端作行動補位，可從本站 下載頁面取得安裝包，並搭配 教學文件 與本文的閘道段落互相對照。