路由器與旁路由直跑 mihomo 內核:全屋透明代理部署概覽

為什麼要把代理下沉到路由層

桌面客戶端(Clash Verge Rev、FlClash 之類)把代理跑在某一台裝置上,好處是配置直觀、介面友善,但覆蓋面只到這一台機器。家裡的電視盒子、智慧音箱、平板、印表機、以及朋友借用的手機,統統被漏在代理之外——它們要麼走公網直連,要麼根本沒法配置代理。把 mihomo 內核直接部署在路由器或旁路由上,相當於把「代理」這件事從終端裝置上摘下來,掛到網路出口這一層,連到這台路由器的所有裝置自動獲得代理能力,不需要在每台終端上重複安裝、重複配置訂閱。

這種「全屋代理」思路特別適合幾類場景:家裡裝置數量多且類型雜、需要給不支援自訂代理的智慧裝置(電視、機上盒)提供出口、或者本身就想省掉給每台裝置單獨維護客戶端的維運成本。代價是部署門檻比裝一個桌面客戶端高得多,需要接觸配置檔、命令列和一定的網路基礎知識,遇到問題也要靠日誌自己排查,不像客戶端有可視化的連通性提示。

硬體選型:主路由刷機還是旁路由

落地前先確定硬體路線,常見兩條:

• 主路由直接刷入支援 mihomo 的固件:適合本身就打算換路由器、且對現有路由穩定性要求不高的場景。優點是省一台裝置、拓撲簡單;缺點是主路由承擔全部轉發壓力,固件出問題會導致全屋斷網,風險更集中。
• 旁路由方案(推薦給多數家庭):在現有主路由後面接一台小型裝置(常見是 x86 迷你主機、樹莓派、或支援刷機的二手路由器),只讓它運行 mihomo,主路由繼續負責 DHCP 與常規路由,把閘道地址或預設路由指向旁路由。這種拓撲改動小、主路由穩定性不受影響,出問題只需要把預設路由指回主路由即可臨時恢復上網,回退成本低,更適合第一次嘗試全屋代理的使用者。

硬體規格上,mihomo 本身對 CPU 和記憶體要求不算高,一般千兆環境下雙核、512MB 以上記憶體的裝置就能穩定跑起來;如果家裡頻寬超過 500Mbps 且規則數量較多,建議預留更充裕的記憶體與稍強的 CPU,避免規則匹配和連線數上升後出現轉發瓶頸。儲存方面幾十到上百 MB 即可滿足內核與配置檔的日常使用。

系統環境準備

不同硬體路線對應不同的系統環境,但流程思路一致:

1. 確認系統架構:下載 mihomo 內核前先確認裝置是 amd64、arm64 還是其他架構,架構不匹配會導致二進位檔案無法執行。
2. 準備運行環境:如果是基於 Linux 的旁路由(常見發行版或 OpenWrt 系固件),確保系統具備基礎的網路工具(iproute2、iptables 或 nftables)與開機腳本能力;如果走的是支援第三方外掛的路由固件,優先查看該固件是否已有現成的 mihomo/Clash 外掛包,能省掉手動編譯和依賴排查的步驟。
3. 關閉衝突元件:如果裝置上此前跑過其他代理或透明代理方案,先確認相關的轉發規則、DNS 劫持規則已經清理,避免新舊規則疊加導致流量走向混亂、排查困難。
4. 預留管理入口:部署前先打通 SSH 或固件自帶的管理後台,方便後續查看內核日誌、重啟服務,不要等到網路中斷之後才發現管理入口本身也走了代理規則導致連不上。

配置檔落位與關鍵欄位

mihomo 使用的配置檔延續 Clash 系配置的 YAML 結構,核心欄位包括入站埠、模式、DNS 段與代理規則,這部分與桌面客戶端裡「匯入訂閱」背後發生的事情本質一致,只是在路由層需要手動落位檔案路徑並管理服務生命週期。典型的最小骨架大致如下:

mixed-port: 7890
mode: rule
log-level: info
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

實際使用時,proxies 與 rules 段通常由訂閱連結提供的遠端配置替換,不需要手寫每一條節點資訊。把訂閱生成的配置檔放到內核約定的配置目錄後,內核啟動時會讀取該檔案建立代理組與規則表。多數部署會把配置檔單獨存放、內核以固定參數指向該檔案路徑,便於後續更新訂閱時只替換配置檔本身,不用重新調整啟動腳本。

規則段的寫法與桌面端一致,常見的判斷優先順序是網域規則、IP 規則、最後落到 MATCH 兜底,例如台灣本地網域直連、特定服務走代理、其餘流量按策略組分流。規則數量多了之後建議使用規則集(rule-provider)引用遠端規則檔案而不是把幾千條規則堆進主配置,既方便更新也減輕內核啟動時的解析負擔。

透明代理模式:TUN 與閘道劫持怎麼選

路由層部署要解決的核心問題,是讓接入裝置「無感」地把流量交給 mihomo,常見有兩種思路:

TUN 模式接管全部出口

在旁路由或刷機路由上開啟 TUN 模式,內核會建立一張虛擬網卡並自動接管系統路由表,所有經過這台裝置轉發的流量都會先進入 mihomo 處理再按規則分流。這種方式配置相對簡單,不需要額外配置 iptables 轉發規則,相容性也更好,是目前路由層部署裡最主流的接管方式,配置裡對應上文範例中的 tun.enable 與 auto-route 欄位。

閘道劫持與 DNS 分流

讓區域網內其他裝置把這台跑 mihomo 的機器當作預設閘道(或者只在旁路由上把預設路由指過來),裝置的 DNS 請求與 TCP/UDP 流量就會經過這台裝置統一處理。這種做法需要在網路層面調整預設路由或 DHCP 閘道地址,對網路基礎知識要求更高,但好處是接入裝置完全零配置,插上網路線或連上 Wi-Fi 就自動獲得代理能力,這也是「全屋代理」最終想要達到的效果。

兩種思路並不互斥,大多數實際部署是「旁路由上開 TUN 接管本機轉發流量」+「區域網裝置把閘道指向旁路由」組合使用,讓旁路由變成區域網裝置的統一出口。

開機自啟與穩定性維護

路由或旁路由通常長期通電運行,斷電重啟後如果內核不能自動拉起,全屋網路會跟著中斷,因此開機自啟不是可選項而是必需項。基於系統服務管理器的裝置,常見做法是把內核啟動命令寫成服務單元,設定為隨系統啟動自動運行並在異常退出後自動重啟;走固件外掛體系的路由,一般外掛本身已經內建了自啟邏輯,只需要在管理介面裡勾選「隨路由啟動」即可。

• 定期檢查內核日誌,關注規則匹配異常或節點連線失敗的報錯,避免「跑起來了但實際沒生效」的情況被長期忽略。
• 訂閱更新後重新載入配置(多數部署支援熱重載,不需要重啟整個服務),減少更新配置造成的短暫斷網時間。
• 為管理入口保留直連或白名單規則,防止某次規則更新導致連自己的管理後台都存取不到。
• 關注內核版本更新節奏,mihomo 迭代較快,新版本通常帶來協定相容性修復和效能優化,但升級前建議先看更新說明,避免配置欄位變動導致啟動失敗。

和桌面客戶端方案的取捨

路由層部署與桌面客戶端並不是非此即彼的替代關係,更適合按需求組合:

• 覆蓋面:路由層部署一次覆蓋全屋所有裝置,桌面客戶端只覆蓋安裝了它的那一台。如果家裡智慧裝置多、或者常有訪客臨時接入網路,路由層部署的邊際成本更低。
• 可視化與易用性:桌面客戶端有圖形介面、連通性測試、節點延遲一覽,出問題容易自查;路由層部署缺少這些,排查依賴日誌和命令列,對非技術使用者不友善。
• 靈活切換:桌面客戶端可以隨時按應用或按視窗切換代理策略,路由層部署的策略統一作用於整個網路,精細到單裝置級別的差異化配置需要額外的策略路由知識。
• 故障影響範圍:桌面客戶端出問題只影響這台裝置;路由層部署出問題,尤其是主路由直接刷機的情況,可能導致全屋斷網,這也是前文建議優先選擇旁路由方案的原因。

比較常見的組合方式,是用路由層部署給電視盒子、智慧裝置等「不方便單獨裝客戶端」的終端提供基礎代理能力,同時在自己的電腦、手機上繼續用桌面或行動端客戶端做精細化的按應用分流,兩者各司其職,而不是互相替代。