路由器直跑 Clash 核心方案概覽:OpenWrt 與旁路由部署思路詳解
介紹在主路由與旁路由兩種拓撲下直接運行 mihomo 核心的部署思路,涵蓋固件選擇、透明代理鏈路、DNS 劫持與開機自啟設定,並說明與桌面客戶端方案的取捨。
為什麼要把 Clash 核心搬到路由器上
桌面客戶端把代理能力局限在安裝了客戶端的那台電腦上,手機、電視盒子、遊戲機想要同樣的分流規則,要麼各裝一份客戶端,要麼完全繞不過去。把 mihomo 核心直接部署到路由器,相當於把代理能力下沉到網路出口這一層,家裡所有連網設備不用裝任何軟體,連上這台路由器就自動走規則分流。這對多設備家庭、智慧電視、不支援裝應用程式的硬體(如某些電視盒子、印表機連網模組)尤其有意義。
這條路徑的代價是設定門檻明顯高於桌面客戶端:需要接觸固件刷寫、透明代理鏈路、DNS 劫持這幾個偏底層的環節,任何一步設定錯誤都可能導致全屋斷網,不適合對命令列和網路基礎知識完全陌生的使用者直接上手。如果只是單台設備的日常使用,桌面或行動客戶端的圖形介面設定顯然更省心;只有當「全屋所有設備統一分流」成為剛性需求時,路由器方案才值得投入這份設定成本。
兩種拓撲:主路由直跑與旁路由掛載
路由器部署 Clash 核心主要分兩種拓撲,選型時先想清楚自己的硬體條件和折騰意願。
主路由直跑:把家用路由器刷成 OpenWrt
這種方案是把家裡原本的路由器(或專門買一台支援刷機的型號)刷成 OpenWrt 固件,再在固件裡安裝 mihomo 核心及配套管理插件,讓路由器本身承擔代理轉發的全部工作。優點是鏈路最短,不需要額外硬體,區域網路內所有設備的流量天然經過這台路由器出口;缺點是對路由器的 CPU 和記憶體有一定要求——運行 mihomo 加上規則比對、DNS 解析,對入門級路由器的處理器是不小的負擔,如果原路由器效能不足,代理開啟後網速可能明顯下降甚至出現卡頓。刷機本身也有變磚風險,需要提前確認設備型號支援的固件版本,並保留好復原用的原廠固件和刷機工具。
旁路由掛載:額外接一台小設備做代理閘道
旁路由方案是在現有路由器(繼續負責基礎連網,不變動)之外,額外接入一台小主機或迷你路由器專門跑 mihomo 核心,透過修改區域網路內其他設備的閘道或 DNS 指向,把需要代理的流量導到這台旁路由處理。常見硬載體是樹莓派、迷你 x86 主機,或者第二台刷了 OpenWrt 的路由器,以橋接模式接入現有網路。這種方案不需要動主路由的固件,風險和門檻都低於主路由直刷,而且旁路由效能不夠時可以單獨升級硬體,不影響主路由的基礎連網功能。多數家庭使用者在「要不要折騰主路由」上猶豫時,旁路由是更穩妥的起點。
刷第三方固件通常會清空設備原有設定甚至觸發保固條款風險,務必先確認路由器型號在 OpenWrt 官方設備清單中的支援狀態,並備份原廠固件包。旁路由方案不涉及刷機,風險敞口小得多,建議作為第一次嘗試的優先選項。
透明代理鏈路:流量如何被路由器接管
路由器層面實現代理接管,核心機制是透明代理(Transparent Proxy),這與桌面客戶端的系統代理或 TUN 模式原理相通,但落地方式不同。設備(手機、電視盒子)本身不知道自己的流量正在被代理,它按正常方式發出請求,路由器在網路層把這些流量透明地重新導向到本機的 mihomo 行程處理,處理完再轉發出去,客戶端設備完全無感知,不需要在每台設備上單獨設定代理位址。
實現透明代理依賴路由器作業系統的流量重新導向能力,OpenWrt 上常見的做法是透過防火牆規則(iptables 或 nftables)把特定連接埠段或協定的流量導向 mihomo 監聽的透明代理連接埠,再配合 mihomo 設定檔裡的 tproxy-port 或類似欄位完成接管。這一層設定是整套方案裡最容易出錯的部分,規則寫錯的直接後果是設備連網正常但代理規則完全不生效,或者反過來所有流量都無法出網。建議先在測試設備上驗證鏈路暢通,再逐步擴大到全屋設備。
| 環節 | 作用 | 常見坑點 |
|---|---|---|
| 防火牆重新導向規則 | 把區域網路設備流量導向 mihomo 透明代理連接埠 | 規則順序錯誤導致部分流量繞過代理 |
| mihomo 透明代理連接埠 | 接收被重新導向的流量並按規則分流 | 連接埠未開啟監聽或權限不足 |
| 路由表與策略路由 | 確保代理後的流量正確回程 | 多網卡環境下路由表衝突 |
DNS 劫持:分流規則生效的前提
透明代理只解決了流量轉發路徑的問題,代理規則要按網域名稱精準分流,還需要 DNS 層面的配合。如果設備直接查詢電信商 DNS,拿到的是真實 IP,mihomo 只能靠 IP 段或 GeoIP 規則粗略判斷,精細的網域名稱規則(如按站點分流到不同代理群組)就無法生效。解決辦法是在路由器上把區域網路內所有設備的 DNS 查詢劫持到 mihomo 內建的 DNS 伺服器,讓 mihomo 自己接管網域名稱解析,再根據解析結果和規則決定這條流量走直連還是走代理。
這一步在 OpenWrt 上通常透過修改 dnsmasq 設定或直接用防火牆規則把 53 連接埠的查詢強制轉發到 mihomo 的 DNS 監聽連接埠實現。mihomo 設定檔裡對應的欄位包括 DNS 伺服器位址、是否啟用 fake-ip 模式等,fake-ip 能進一步提升網域名稱分流的準確性,但對部分需要真實 IP 的場景(比如某些區域網路內網服務發現協定)可能產生相容性問題,設定時需要按實際使用的應用場景做取捨。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29上面是 mihomo 設定檔裡 DNS 段的一個簡化範例,實際部署時還需要結合 fake-ip 排除範圍、中國大陸網域名稱直連清單等欄位做更細緻的調整,具體欄位含義可以在概念速查頁裡查到詳細解釋。
開機自啟與穩定運行設定
路由器和桌面電腦的使用場景不同,路由器幾乎是 7×24 小時通電運行,斷電重啟後必須自動恢復代理服務,不能指望人工介入。OpenWrt 上給 mihomo 設定開機自啟,一般透過 /etc/init.d/ 下編寫符合 procd 規範的啟動腳本,並用 service mihomo enable 註冊到系統服務裡,這樣固件重啟後會自動拉起行程。旁路由方案如果用的是通用 Linux 發行版,則通常用 systemd 編寫對應的 .service 檔案,設定 Restart=on-failure,讓行程異常退出後自動重啟。
除了開機自啟,長期穩定運行還要考慮幾個細節:訂閱更新是否設定了定時任務、日誌檔案是否會無限增長佔滿儲存空間、記憶體佔用是否隨運行時間增長(記憶體洩漏在部分舊版核心上出現過,建議保持核心版本更新)。對於旁路由這種獨立小主機,還建議設定看門狗腳本定期檢測 mihomo 行程狀態,異常時自動拉起,避免深夜服務掛掉卻無人察覺,導致全屋設備第二天早上發現網路異常。
部署完成後按這個順序驗證:先確認 mihomo 行程正常監聽連接埠,再確認防火牆重新導向規則生效(用測試設備存取已知走代理的站點驗證),最後確認 DNS 劫持鏈路正確(用 nslookup 類工具檢查解析結果是否為 fake-ip 段)。三步都通過後才建議把全屋設備閘道切換過來。
與桌面客戶端方案的取捨
路由器方案和桌面客戶端方案不是互相替代關係,更適合按場景搭配使用。如果家裡只有一兩台常用設備需要代理,裝一個桌面客戶端(如 Clash Verge Rev 或 FlClash)設定圖形介面,幾分鐘就能完成,不需要碰命令列和固件。但如果家裡設備數量多、種類雜,尤其是電視盒子、遊戲機、智慧音箱這類無法自行安裝客戶端的設備也需要走分流規則,路由器方案就是唯一能一次性覆蓋全部設備的辦法。
另外要考慮的是維護成本:桌面客戶端更新只需要下載新版本重新安裝,而路由器上的核心升級往往需要手動替換二進位檔案或重新刷入固件包,操作路徑更繁瑣,出錯後排查也更麻煩,一般使用者直接在生產環境的路由器上做大幅變動前,最好先在測試環境或備用設備上驗證一遍。對大多數家庭使用者而言,更務實的組合是:主力設備裝桌面客戶端保證靈活性和及時更新,家裡確實有多設備統一分流的硬需求時,再單獨設定一台旁路由承擔這部分職責,兩者互補而不是二選一。
規則與設定從哪裡來
不管是路由器上的 mihomo 還是桌面客戶端,規則集、策略群組、訂閱連結的寫法都是同一套 mihomo 設定語法,沒有額外的路由器專屬格式。這意味著已經在桌面客戶端上跑通的設定檔,理論上可以直接搬到路由器的 mihomo 執行個體上使用,只需要額外補充透明代理連接埠、DNS 監聽位址這幾個路由器場景特有的欄位。如果是第一次接觸策略群組、規則分類這些概念,建議先在桌面客戶端上理清設定邏輯,再遷移到路由器環境,這樣出問題時更容易判斷是規則寫錯還是路由器鏈路設定的問題。