路由器與旁路由直跑 Clash 核心:mihomo 部署方案概覽

為什麼要把代理放到路由器層

桌面客戶端與手機 App 只能覆蓋安裝了軟體的那台裝置,家裡的電視盒子、遊戲主機、智慧音響、平板往往沒辦法逐一設定,而且系統代理與 TUN 模式各家實作不一致,遇到不支援自訂 DNS 或不支援虛擬網卡的裝置就會束手無策。把代理下沉到路由器或旁路由這一層,相當於在網路出口處統一接管流量,連上這張網路的所有裝置都自動取得分流能力,不需要逐台安裝客戶端,也不用擔心某個裝置本身架構冷門裝不上軟體。這也是許多家庭網路最終選擇在閘道層部署 mihomo 核心的核心原因。

mihomo 是 Clash Meta 專案延續下來的核心實作,相比早期 Clash 核心,協定支援更完整、規則引擎更靈活,且原生提供 TUN 模式與豐富的行程層級分流能力,非常適合被韌體化後長期掛在路由器上運作。下文會分主路由與旁路由兩種拓撲分別說明落地思路。

主路由與旁路由:兩種拓撲該怎麼選

「主路由」指直接刷入支援第三方軟體的韌體(常見是 OpenWrt 系),讓路由器本身承擔 mihomo 執行環境;「旁路由」則是在現有路由器之外,額外接一台小型裝置(迷你主機、閒置的路由器刷成純閘道、甚至一台 NAS 的虛擬機),透過閘道劫持或是區域網路內 DHCP 選項,把需要代理的裝置指向這台旁路由處理。

• 主路由方案:優點是拓撲簡單,一台裝置完成路由與代理兩件事,不需要額外硬體;缺點是對路由器本身的韌體相容性、CPU 效能要求更高,一旦代理行程異常也可能影響到整個網路的路由轉發,風險集中在同一台裝置上。
• 旁路由方案:優點是主路由保持原廠韌體不變,穩定性與售後不受影響,旁路由這台裝置專職跑代理,出問題只需重啟這一台,排查邊界清晰;缺點是多了一台硬體、多了一層網路設定(閘道指向、DHCP 分發),初期搭建門檻略高。

如果家裡只有一台支援刷第三方韌體的路由器,且願意接受「全部集中在一台裝置」的風險敞口,主路由方案更省事;如果希望代理環境與基礎網路解耦、方便隨時重置或更換代理裝置而不影響上網,旁路由是更穩妥的選擇,也是目前家庭網路裡更常見的做法。

硬體選型與韌體基礎

mihomo 本身是用 Go 撰寫的單一二進位程式,資源占用不算重,但透明代理情境下需要同時處理 NAT 轉發、DNS 查詢與規則比對,選型時建議關注三個維度:

1. CPU 架構與算力:優先選支援硬體加速的多核心 ARM 或 x86 平台,純路由等級的低功耗單核心晶片在高並發連線下容易出現規則比對延遲。
2. 記憶體容量:規則集載入、連線表維護都吃記憶體,建議至少預留 512MB 以上給代理行程與韌體本身,規則較多或開啟日誌追蹤時可適當再放寬。
3. 儲存與韌體生態:主路由方案通常依賴 OpenWrt 或其衍生韌體,需要確認目標裝置有穩定的第三方韌體支援與社群維護;旁路由方案則更自由,迷你主機跑 Linux 發行版、老舊路由器刷 OpenWrt 純閘道模式都是常見選擇。

韌體層面,mihomo 官方及社群提供了適配 OpenWrt 的軟體包與 LuCI 管理介面,可以透過套件管理器安裝,也可以直接放置編譯好的二進位檔配合 init 腳本執行,兩種方式在後文的自啟動部分都會涉及。

透明代理模式:TUN、TPROXY 與 REDIRECT 怎麼選

在閘道層接管流量,核心是把區域網路裝置發出的 TCP/UDP 流量透明地導向 mihomo 監聽的埠,再由核心依規則決定放行、代理或攔截。常見的三種實作方式各有取捨:

• TUN 模式:mihomo 建立一張虛擬網卡,把流量在第三層直接接管,設定直觀、對 UDP 支援完整,是目前推薦的預設方式,尤其適合需要精確控制 IPv4/IPv6 分流的情境。
• TPROXY:依賴 Linux 核心的透明代理機制,在閘道裝置上用 iptables/nftables 把流量重新導向到 mihomo,能保留原始目的位址資訊,相容性較好,常見於成熟的 OpenWrt 分流腳本方案。
• REDIRECT:較早期的實作方式,僅支援 TCP 重新導向,UDP(尤其是依賴 UDP 的遊戲、部分影音協定)需要額外處理,新部署一般不再首選。

無論選哪種,設定檔裡都要開啟對應的透明代理開關並宣告監聽埠,例如啟用 TUN 模式時的關鍵欄位大致如下(具體參數以目前版本文件為準):

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

auto-route 負責自動寫入路由表,auto-detect-interface 幫核心識別出口網卡,兩者配合可以省去大量手動改路由規則的步驟,是目前旁路由方案裡最常用的組合。

DNS 接管與防污染

透明代理只解決了流量轉發,如果 DNS 查詢仍然走電信業者的預設線路,規則裡依域名判斷的分流會因為拿到「錯誤」的解析結果而失效,常見表現就是明明設定了規則,某些網站訪問依舊異常緩慢或直接不通。因此閘道層部署必須同步接管 DNS:

1. 在 mihomo 設定裡啟用內建 DNS 伺服器,並設定為區域網路裝置可存取的監聽位址與埠。
2. 結合 fake-ip 或 redir-host 模式,讓核心先取得域名再決定往哪個上游解析,配合規則引擎實現依域名分流而不是單純依 IP 段分流。
3. 在路由器的 DHCP 設定裡,把發送給區域網路裝置的 DNS 伺服器位址指向閘道本身(即執行 mihomo 的裝置),避免裝置繞過閘道直接查詢外部 DNS。

如果是旁路由拓撲,還需要在主路由上確認 DHCP 選項 6(DNS)確實指向了旁路由位址,否則即便旁路由設定正確,區域網路裝置依然會拿到主路由分發的預設 DNS,導致分流規則形同虛設。這一步是排查「規則配了但沒生效」問題時最常被忽略的環節。

開機自啟與長期穩定性

閘道層的代理行程需要具備「重啟路由器後自動恢復」的能力,否則一次意外斷電就會讓全屋斷網或退回未分流狀態。落地時建議關注以下幾點:

• init 腳本或系統服務:OpenWrt 下可以撰寫 procd 服務腳本,把 mihomo 註冊為系統服務,支援 enable、start、stop 等標準操作,韌體重啟後由 procd 自動拉起。
• 看門狗與自我修復:配合簡單的定時任務(cron)偵測行程是否存活,一旦異常退出就自動重啟,避免因核心偶發當機導致長時間斷網而無人察覺。
• 設定與規則集分離:把訂閱產生的節點設定與本地自訂規則分成不同檔案引用,更新訂閱時不會覆蓋手動調整過的路由規則,減少每次訂閱刷新後需要重新排查的工作量。
• 日誌留存:開啟適度的連線日誌與核心日誌輸出到本地檔案,方便在裝置離線或分流異常時回溯具體是哪一條規則或哪次 DNS 查詢出了問題。

旁路由方案由於獨立於主路由執行,通常更容易做日誌留存與行程守護,也更適合放一些實驗性的規則修改;主路由方案則建議保持設定相對保守,重大改動前先備份目前可用的設定檔。

落地前的決策清單

把前面幾節的判斷標準歸納成一份簡單清單,方便對照自己的家庭網路現狀:

1. 現有路由器是否支援穩定的第三方韌體?支援且願意承擔集中風險 → 優先考慮主路由方案。
2. 是否有閒置的迷你主機、舊路由器或小型 NAS 可以專職跑代理?有 → 旁路由方案排查更清晰、風險更分散。
3. 家裡是否存在不支援自訂 DNS 的智慧裝置(電視盒子、音響等)?存在 → 提前規劃好閘道層的 DNS 劫持策略。
4. 是否需要頻繁更換代理裝置或重刷韌體測試?頻繁 → 旁路由更方便隨時替換而不影響主網路。
5. 是否有長期無人值守的場景(出差、異地)?有 → 務必設定好自啟動與看門狗,避免斷電後無法遠端恢復。

不管最終選擇哪種拓撲,核心思路是一致的:先在閘道層把流量與 DNS 都收攏到 mihomo 核心,再用清晰的規則檔案描述分流邏輯,最後用系統服務與日誌機制保證長期穩定運行。把這三層分別做扎實,家庭網路裡的每一台裝置才能真正共享同一套代理策略,而不需要逐台折騰設定。