把代理規則收攏到路由器層,是解決多裝置分流問題的常見思路。相比在每台裝置上單獨安裝用戶端,讓路由器直接運行 mihomo 內核,可以讓區域網路內所有接入裝置(包括不支援安裝用戶端的電視盒子、智慧音箱、遊戲主機)統一走同一套分流規則,設定改一處、全網生效。這篇文章梳理路由器直跑 mihomo 的整體思路,不涵蓋具體韌體的逐畫面點擊操作,重點講清楚決策點和容易踩的坑。
為什麼要在路由器上跑 mihomo
手機、平板、電腦各自安裝用戶端固然靈活,但存在兩個明顯短板。第一,不支援安裝應用程式的裝置(智慧電視、掃地機器人、部分遊戲主機)完全無法接入代理網路,只能靠手動設定代理伺服器位址,而很多裝置根本不提供這個選項。第二,多裝置各自維護一份設定,規則、訂閱更新需要逐台同步,容易出現版本不一致導致的分流差異。
把 mihomo 內核部署在路由器上解決了這兩個問題。區域網路內所有裝置預設經過路由器轉發流量,只要路由器做好透明代理,裝置端不需要任何額外設定就能享受到規則分流,而設定維護也集中到了路由器這一個點。這種思路在實務上通常被稱為「網關代理」或「旁路由代理」,區別只在於代理是跑在承擔網路出口職責的主路由上,還是跑在與主路由並列、透過策略路由接管流量的旁路由上。
主路由與旁路由的取捨
主路由直跑指的是刷了支援 mihomo 的第三方韌體(常見是 OpenWrt 及其衍生版本)的路由器,直接在網路出口這一層運行代理內核,所有流量預設經過。這種方案鏈路最短,不需要額外硬體,但對路由器本身的韌體相容性和效能要求更高——一旦設定出問題,可能影響全屋上網,排查也不方便,做實驗性設定調整前最好想清楚回退路徑。
旁路由方案是在現有路由器網路裡另外接一台小型裝置(常見是樹莓派、迷你主機或二手路由器刷機),只跑代理內核,不承擔主路由的 DHCP、無線等基礎職責。主路由透過策略路由或者 DHCP 網關指向把部分流量轉發給旁路由處理。這種方式的好處是不動主路由的穩定設定,出問題只需要把網關指回主路由,風險可控;缺點是鏈路多了一跳,理論延遲略高,且需要額外裝置和一定的網路知識去打通策略路由。
對大多數家庭網路場景,旁路由是相對穩妥的起點:先在小範圍驗證分流規則是否符合預期,確認穩定後再考慮要不要收編成主路由方案。對已經在用支援刷機的高效能路由器、且有信心自己排查網路問題的使用者,直接主路由部署鏈路更簡潔。
硬體與韌體的基本要求
無論走哪種方案,硬體層面有幾個繞不開的門檻。
- CPU 架構與效能:mihomo 內核對 CPU 有一定要求,規則數量多、並發連線大的場景下,低功耗單核裝置容易出現轉發延遲或丟包。選購或重複使用裝置時優先考慮多核 ARM 或 x86 平台,避免用效能過弱的老舊路由器承擔高並發代理任務。
- 記憶體容量:規則集、GeoIP/GeoSite 資料庫載入進記憶體後會佔用一定空間,記憶體過小(比如 128MB 以下)的裝置在規則數量較大時可能出現內核異常退出或回應變慢,建議預留至少 256MB 以上可用記憶體。
- 儲存空間:韌體本身、mihomo 二進位、規則資料庫、日誌檔案都需要落地儲存,如果裝置自帶儲存太小,建議外接隨身碟或使用支援擴充儲存的機型。
- 韌體支援:主流選擇是 OpenWrt 及其衍生韌體(如支援較好的社群分支),這類韌體生態成熟,套件庫裡通常能找到打包好的 mihomo 或相容元件,省去手動編譯的麻煩。原廠韌體基本不具備直接運行代理內核的能力,需要先刷成支援自訂軟體安裝的第三方韌體。
刷機本身存在裝置變磚的風險,操作前請確認韌體版本與裝置型號完全匹配,並提前備份原廠韌體與關鍵分區資料。
內核二進位的選擇
mihomo 內核會針對不同 CPU 架構和指令集發布對應的二進位檔案,常見的架構標識包括 amd64、arm64、armv7 等,選錯架構會導致程式無法運行或運行後立即崩潰。除了架構匹配,還需要關注以下兩點:
- 版本穩定性:路由器場景對穩定性的要求高於追新,建議選擇經過一段時間驗證的穩定版本,而不是剛發布的最新版,避免把網路出口暴露在未知的相容性問題下。
- 功能特性對齊:確認所選版本是否支援你計劃使用的功能,例如 TUN 模式、特定的規則語法、特定的傳輸協定實作。不同發布渠道打包的二進位有時會裁減部分功能以控制體積,部署前查閱對應版本的更新說明,確認功能涵蓋是否滿足需求。
韌體套件市場裡打包好的 mihomo 元件通常已經處理好架構適配問題,對不熟悉手動部署流程的使用者是更省心的起點;需要自訂編譯參數或使用尚未打包進套件庫的新版本時,才考慮手動下載二進位並設定啟動腳本。
透明代理與 DNS 劫持要點
路由器直跑的核心價值在於「透明」——區域網路裝置不需要感知代理的存在,所有流量在網關層被自動接管。實現這一點依賴兩個機制的配合。
流量透明轉發
mihomo 支援透過 TUN 模式在系統層建立虛擬網卡,把經過路由器的流量重新導向進虛擬網卡,再由內核按規則分流處理,這種方式對協定相容性較好,能涵蓋 TCP 與 UDP。部分韌體環境也支援基於 iptables/nftables 規則的透明代理方案,原理是把特定連接埠段或全部流量重新導向到內核監聽的本機連接埠。兩種思路各有適用場景,TUN 模式設定相對直觀,但對內核版本和韌體網路堆疊的相容性要求更高;iptables 方案相容性更廣,但規則寫法複雜,排查問題時需要熟悉網路重新導向鏈路。
DNS 劫持與污染規避
規則分流很大程度上依賴網域名稱解析結果做判斷,如果裝置的 DNS 請求繞過了 mihomo 直接發往電信業者 DNS,可能拿到被污染或不準確的解析結果,進而影響分流準確性。因此路由器部署通常需要額外做一步 DNS 劫持:把區域網路內所有裝置發出的 53 連接埠 DNS 請求強制重新導向到 mihomo 內建的 DNS 伺服器,由內核統一處理解析與後續的分流決策。
這一步做得不徹底,最常見的表現是「某些應用程式能正常代理,某些應用程式直連走了原始網路」——往往就是這些應用程式內建了自己的 DNS 解析邏輯,繞開了系統 DNS 設定,連帶繞開了劫持規則。排查這類問題時,先確認路由器層的 DNS 重新導向規則是否涵蓋了所有網段和所有連接埠方向,再檢查具體應用程式是否使用了加密 DNS(如 DoH)直連特定伺服器。
區域網路裝置接入的兩種常見方案
把 mihomo 跑起來只是第一步,更關鍵的是讓區域網路內的其他裝置「知道」要走這條代理路徑。常見的兩種接入方式各有取捨。
| 方案 | 實現方式 | 優點 | 局限 |
|---|---|---|---|
| 網關直接指向 | DHCP 分配的預設網關直接指向運行 mihomo 的裝置 | 設定簡單,新接入裝置自動生效,無需逐台設定 | 該裝置成為單點,一旦故障將影響全部下游裝置連網 |
| 策略路由分流 | 主路由按來源 IP 或 MAC 位址,把指定裝置的流量轉發給旁路由處理 | 可按裝置粒度控制是否走代理,故障影響範圍可控 | 需要在主路由上維護策略路由規則,新增裝置需手動加入名單 |
網關直接指向適合「全屋統一走代理」的場景,設定一次即可涵蓋所有新接入裝置,適合家庭成員裝置較多、不希望逐台設定的情況。策略路由分流適合「部分裝置需要代理、部分裝置保持直連」的場景,比如只讓智慧電視和遊戲主機走代理,其他辦公裝置維持原有網路路徑,避免不必要的鏈路影響。選擇哪種取決於你對「全量接管」和「精細控制」的優先級排序,也可以先用策略路由做小範圍驗證,確認穩定後再切換成網關直接指向。
部署前的幾個自查項
動手之前,建議先確認以下幾件事,能省去後續排查的不少時間。
- 確認裝置架構與韌體版本,提前下載好對應的 mihomo 二進位或套件包,避免在斷網狀態下現場查資料。
- 準備好訂閱連結與基礎規則集,先在小範圍(比如自己一台裝置)驗證設定檔語法正確、規則命中符合預期,再推廣到全屋。
- 規劃好日誌保留位置,路由器儲存空間有限,長期運行建議做好日誌輪替或定期清理,避免儲存寫滿導致裝置異常。
- 確認回退路徑:如果部署後出現全屋斷網,能否快速把網關指回主路由,或者用備用網路(如手機熱點)臨時接入路由器管理介面進行修復。
路由器層面的代理部署收益明顯,但試錯成本也高於單裝置用戶端——出問題影響的是全屋網路。建議先在低峰時段進行部署與調試,設定穩定後再作為長期方案運行,並保留一份可快速恢復的原始網路設定備份。