Mihomo 路由器部署入門：主路由、旁路由與核心直接執行方案比較

先釐清網路位置與執行方式

Mihomo 是延續 Clash Meta 發展而來的代理核心。將它部署於路由器環境時，最容易混淆的並非設定語法，而是兩個不同面向：設備位於網路中的哪個位置，以及核心透過何種方式啟動與維護。主路由、旁路由描述的是網路拓撲；核心直接執行、路由器外掛或容器描述的則是軟體執行方式。這些選項並不互斥，例如旁路由同樣可以直接執行核心。

部署前，先畫出最短的資料路徑：終端裝置將封包送往哪個預設閘道、DNS 查詢送到哪裡、流量在哪台設備進入 Mihomo，以及完成代理後從哪個出口返回。只要這四個位置不清楚，後續遇到網頁無法開啟、台灣本地網站流量繞行、部分設備未套用設定或 IPv6 繞過代理時，就很難判斷問題出在規則、DNS 還是路由。

主路由部署：路徑最直接，變更影響也最大

主路由方案會將 Mihomo 設在整個網路的預設出口。終端裝置通常從這台設備取得 IP 位址、預設閘道與 DNS 位址，因此不必逐台設定，即可套用統一規則。透明代理入口可透過 TProxy、重新導向規則或 TUN 裝置承接，實際選擇取決於系統核心、外掛實作方式及是否需要處理 UDP。

這類拓撲的優點是路徑清楚：區域網路內的終端會先連到主路由，再由規則決定直接連線、使用代理或攔截。DNS 也較容易集中管理，設備分組可搭配來源 IP、MAC 對應的固定租約、VLAN 或不同子網路完成。對於需要長期統一管理電視、手機、電腦與遊戲裝置的家庭網路，使用主路由通常比逐台安裝用戶端更容易維持一致。

代價是故障影響範圍較大。錯誤的防火牆規則、無法使用的設定檔或 DNS 迴圈，可能同時影響整個區域網路。升級核心時，也要考量設備架構、執行檔權限、設定相容性及服務重新啟動順序。若路由設備效能有限，加密連線、規則比對、DNS 快取與記錄寫入會共同占用 CPU 和記憶體，不能只依網路埠標示的速率判斷實際代理傳輸效能。

適合採用主路由方案的條件

1. 具備維護路由系統的能力，並保留本機管理入口與設定還原方式。
2. 設備 CPU 架構有對應的 Mihomo 建置版本，且儲存空間足以容納核心、規則集與記錄。
3. 希望多數終端預設套用同一套分流邏輯，而非僅讓少數設備使用代理。
4. 能安排升級時段，並接受重新啟動代理服務時發生短暫斷線。

旁路由部署：方便測試，重點在流量導向

旁路由通常與主路由位於同一個區域網路。主路由繼續負責撥號、NAT 與無線網路連線，旁路由則處理指定終端的代理和 DNS。這種方案適合漸進式部署：先讓一台測試電腦使用旁路由，確認規則、訂閱及 DNS 運作正常後，再逐步擴大至固定設備或獨立子網路。

旁路由不會因為接上交換器，就自動取得整個網路的流量。最直接的方式，是在終端上將預設閘道與 DNS 指向旁路由；也可以透過 DHCP 向特定設備配發不同閘道，或在主路由使用策略路由，將指定來源位址導向旁路由。應採用哪種方式，取決於主路由是否支援靜態租約、依設備配發參數及策略路由。

單臂旁路由只有一個區域網路介面，封包從該介面進入，處理後仍由同一介面送往主路由。此時要特別留意回程路徑。若終端傳出的封包經過旁路由，但回應封包由主路由直接送回終端，就可能形成非對稱路徑。一般連線有時仍可運作，但在依賴連線追蹤、透明代理或嚴格狀態防火牆的情境下，可能會出現異常。實際部署時，通常會透過正確的閘道規劃、策略路由或必要的來源位址轉譯，讓來回路徑保持一致。

旁路由常見連線方式

旁路由關閉 DHCP 並非通用規則。如果由主路由統一分配位址，旁路由通常不必在相同網段再次啟用 DHCP；若旁路由管理獨立子網路，則可為該子網路提供 DHCP。判斷原則應是每個廣播網域只能有一套清楚、可控的位址分配方案，而不是一律開啟或關閉某項服務。

核心直接執行：控制更精細，系統功能須自行補足

核心直接執行是指下載符合 CPU 架構的 Mihomo 執行檔、準備 YAML 設定，再透過系統服務管理程式啟動。這種方式較不受圖形化外掛的設定結構限制，適合需要自訂規則提供者、監聽連接埠、實驗功能或自動化部署流程的使用者。不過，核心只負責本身的代理功能，不會自動完成路由系統所需的其他工作。

可正常運作的核心直接執行方案至少包含五個部分：設定檔與外部規則資源、持久化目錄、啟動服務、透明代理或 TUN 所需權限，以及 DNS 與防火牆的搭配設定。此外還要規劃更新與還原機制，例如更新前先執行設定檢查、保留上一版二進位檔，並在新程序啟動失敗時恢復原本的服務。

mode: rule
allow-lan: true
bind-address: "*"
mixed-port: 7890
tproxy-port: 7893

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

上述片段只呈現監聽關係，並非可直接用於路由器的完整設定。代理節點、策略群組、規則、規則集及防火牆導流仍須另外定義。DNS 上游也應依網路環境與分流目標選擇。若讓 DNS 監聽 1053 連接埠，還需要由系統 DNS 轉送器將查詢送到該連接埠，或明確讓終端存取它；僅寫入設定並不會自動接管區域網路的 53 連接埠。

直接執行核心時的服務啟動順序

1. 確認網路介面、時間同步及設定目錄都已就緒。
2. 檢查設定語法與外部資源是否能正常讀取，避免服務不斷重新啟動。
3. 啟動 Mihomo，確認代理連接埠、DNS 連接埠及控制介面均依預期監聽。
4. 接著再載入透明代理與策略路由規則，避免流量被送往尚未開始監聽的連接埠。
5. 停止服務時，先移除導流規則再結束核心，縮短區域網路連線遭丟棄的時間。

DNS、透明代理與 IPv6 必須一併規劃

在路由器部署中，許多看似「節點不穩定」的狀況，其實源自 DNS 路徑。終端可能將 DNS 查詢送至主路由，再由主路由轉送給 Mihomo；也可能直接查詢旁路由。必須確認查詢鏈路不會形成「系統 DNS 轉送給 Mihomo，而 Mihomo 又將同一個上游請求送回系統 DNS」的迴圈。

Mihomo 的 fake-ip 模式會從保留位址池傳回對應位址，後續連線進入核心後再還原網域名稱，有利於依網域規則處理連線。部分區域網路設備、內部網域、時間同步服務或依賴真實位址回應的應用程式，可能需要加入 fake-ip-filter。redir-host 模式較接近傳回實際解析結果，但網域名稱辨識與快取行為仍須依具體通訊協定測試。兩種模式沒有脫離實際環境的絕對優劣；選定後，應透過記錄確認網域規則確實命中。

解析代理伺服器網域名稱是另一個獨立環節。節點主機名稱必須先完成解析，才能建立連線，因此需要為這類查詢準備可連線的解析器。Mihomo 設定中的 proxy-server-nameserver 可用來處理代理伺服器網域名稱，降低啟動階段對代理鏈路的依賴風險。規則提供者或訂閱網址的存取也要考量相同的相依關係：如果取得設定前必須先連上代理，而代理又依賴尚未下載的設定，就會形成無法啟動的迴圈。

如何選擇透明代理入口

• 明確指定代理連接埠：由終端主動填入 HTTP 或 SOCKS 代理，路徑容易驗證，但無法涵蓋不支援代理設定的應用程式。
• TProxy：常用於 Linux 路由環境，可保留原始目的地資訊並處理 TCP、UDP，但需要搭配策略路由、核心模組及防火牆規則。
• TUN 模式：透過虛擬網路介面接收流量，設定概念相對一致，但須檢查設備權限、路由表、DNS 劫持及與既有 VPN 的衝突。
• 重新導向方式：常用於 TCP 導流，實作成熟，但 UDP 與原始目的地的處理能力取決於具體系統方案。

IPv6 不能只看 Mihomo 設定中的單一開關。只要區域網路仍向終端發布 IPv6 預設路由與 DNS，終端就可能優先透過 IPv6 直接連線，進而繞過僅處理 IPv4 的透明代理規則。需要代理 IPv6 時，應同步檢查上游前綴、路由公告、防火牆、TUN 或 TProxy 支援情況及規則涵蓋範圍；若暫時不處理，也應明確停用相關公告，或建立可說明的直接連線策略，而非讓 IPv4 與 IPv6 分別走上不同且無法觀察的路徑。

依控制範圍、維護能力與還原成本選擇

選擇方案時，不必先比較哪一種效能最高，而應先確認需要接管多少設備、能否修改主路由，以及發生故障時哪些設備必須維持連線。若只供一台電視或測試電腦使用，旁路由搭配定向閘道通常已足夠；全屋設備需要統一規則，且具備路由維護能力時，主路由方案較為簡潔；若需要精確控制設定產生、服務編排及防火牆細節，則可在前兩種拓撲上採用核心直接執行。

部署前參數清單

• 記錄主路由、旁路由、終端及 DNS 服務的 IP 位址，避免位址衝突。
• 確認設備 CPU 架構、可用記憶體、儲存空間及系統採用的防火牆架構。
• 確認 TCP、UDP、IPv4、IPv6 各自要由哪一種入口處理。
• 針對不應進入代理的區域網路網段、管理位址及基礎服務建立排除規則。
• 為測試終端分配固定位址，方便從記錄中辨識連線來源。
• 準備停止代理後恢復一般網路連線的操作步驟，並在正式接管前實際演練。

上線後的逐層驗收

1. 基礎網路：關閉透明代理後，終端能否透過原本的出口正常存取區域網路與網際網路。
2. DNS：檢查終端實際使用的 DNS 位址、查詢回應及 Mihomo DNS 記錄，排除迴圈與逾時問題。
3. 流量入口：確認目標連線出現在 Mihomo 記錄中，且能查看來源位址、目的位址及命中的規則。
4. 策略結果：分別測試應直接連線、應使用代理及應攔截的網域名稱，不要只依賴單一測速網站判斷。
5. UDP 與 IPv6：個別測試即時通訊、遊戲或其他 UDP 情境，再確認 IPv6 是否遵循預定路徑。
6. 故障還原：停止 Mihomo 或套用無法使用的設定，確認管理入口仍可存取，網路也能依預案恢復。

在路由器上部署 Mihomo，本質上是一項網路路徑測試。主路由方案著重統一入口，旁路由方案著重可控範圍，核心直接執行則著重自行維護設定與系統層功能。先用一台固定位址的終端建立可觀察、可還原的最小鏈路，再逐步加入 DNS 接管、UDP、IPv6 與更多設備，通常比一次接管整個網路更容易找出問題。