Mihomo 路由器與旁路由部署概覽：核心直跑、流量接管與維護界線

將 Mihomo 部署在家用路由器或旁路由上，重點不是為每台裝置個別安裝桌面用戶端，而是把代理能力放在區域網路出口附近，由網路設備統一處理符合條件的連線。這能涵蓋電視、遊戲主機、智慧音箱與家用伺服器等不便安裝 Clash 用戶端的裝置，但也會將設定、轉送、DNS 與故障定位集中在單一網路節點。

實務上所說的「路由器部署」可能代表兩種完全不同的架構：一種是 Mihomo 直接執行於負責家用閘道的主路由系統；另一種是增加一台裝置作為旁路由，與主路由並行，再透過閘道、策略路由或手動設定，讓部分用戶端將流量交給旁路由。兩種架構都能實現透明代理，但封包經過的路徑、斷電後的影響範圍與維護方式並不相同。

先確認部署模型：主路由直接執行核心，還是由旁路由分流

主路由直接執行核心

主路由直接執行核心，是指 Mihomo 運行在目前區域網路的預設閘道裝置上。終端透過 DHCP 取得主路由的 IP 位址作為預設閘道，存取外部網路時，封包自然會先抵達這台裝置。路由系統可在轉送階段將流量交給 Mihomo 的透明代理入口，再由 Mihomo 依據規則模式、策略群組與代理節點決定後續路徑。

這種架構的優點是拓撲簡單：預設閘道、區域網路 DHCP、DNS 轉送與代理程式集中在同一台裝置上，規則涵蓋範圍也較自然。缺點是主路由承擔較多職責，核心會使用 CPU、記憶體與連線表資源；若設定更新失敗、路由系統重新啟動或 Mihomo 程序異常，可能影響整個家用網路。對硬體效能有限、廠商韌體封閉，或不熟悉路由系統啟動項目的使用者而言，直接修改主路由前應先確認能否復原。

旁路由獨立運作

旁路由通常是區域網路中的第二台裝置，例如執行 Linux、OpenWrt 或其他路由系統的迷你電腦。主路由繼續負責撥號、無線連線與 DHCP，旁路由則只執行 Mihomo 及相關透明代理元件。終端可透過三種常見方式使用旁路由：將旁路由設為預設閘道；只將 DNS 指向旁路由並搭配透明轉送；或僅為指定裝置手動設定閘道與代理入口。

旁路由的價值在於隔離風險。主路由維持原有設定，旁路由停止運作時，未經其轉送的裝置仍可透過主路由上網。旁路由也方便逐步測試，例如先讓一台電腦使用旁路由，再擴展至電視、家用伺服器或訪客網路。不過，旁路由不代表會自動接管所有流量。若終端的預設閘道仍是主路由，而主路由也沒有將相關流量轉送至旁路由，Mihomo 就無法看見這些連線。

理解透明代理：流量接管不代表所有連線都會自動代理

桌面用戶端常見的系統代理，是將 HTTP、HTTPS 或 SOCKS 代理位址寫入作業系統或應用程式設定。應用程式主動遵循這些設定時，連線會傳送至指定連接埠；不支援系統代理的程式則可能完全繞過它。路由器上的透明代理處理方式不同：通常會在轉送鏈路中比對連線，並透過防火牆重新導向、策略路由或 TUN 等機制，將原本直接轉送的流量交給代理核心。

傳統透明代理方案通常依賴系統網路堆疊與防火牆規則。例如，TCP 流量經過路由器的轉送鏈時，會被重新導向至本機的透明代理連接埠；Mihomo 再依據原始目標位址進行規則比對。UDP、ICMP、IPv6 與本機發起的流量可能需要不同處理，不能因為 TCP 網頁能開啟，就推斷所有協定都已被接管。

TUN 模式會透過虛擬網卡接收經由系統路由的 IP 封包，核心從中處理 TCP、UDP 等連線，並結合設定中的 DNS 與路由設定完成後續轉送。它適合需要涵蓋更多應用程式協定，又不希望逐項設定連接埠重新導向的情境，但對系統權限、路由表、DNS 處理與 IPv6 設定較為敏感。在路由器環境中，TUN 是否可用還取決於系統核心能力、虛擬裝置權限，以及對應版本的 Mihomo 支援狀況。

一條連線實際經過哪些位置

1. 區域網路終端解析網域名稱，並依據本機路由表決定預設閘道或 DNS 伺服器。
2. 封包抵達主路由或旁路由。若旁路由不是預設閘道，就必須有額外的轉送規則讓流量經過它。
3. 透明代理入口接收連線。入口可能是重新導向連接埠、TProxy 連接埠或 TUN 虛擬網卡，實際名稱取決於系統與設定。
4. Mihomo 解析目標、執行 DNS 處理，並依規則順序選擇直連、代理或某個策略群組。
5. 連線從直連出口或代理節點發出，回傳資料再沿著可達的回程路徑返回終端。

其中任何一個環節缺失，都可能表現為「某些網站無法開啟」。例如策略規則選擇了代理，但旁路由無法連線至節點；或者節點可用，卻因為終端仍將 DNS 傳給主路由而取得錯誤位址。排查時應先判斷連線是否抵達 Mihomo，再確認命中了哪些規則，最後才檢查代理節點與遠端網路。

Mihomo 在路由器上的運作組成：設定、連接埠與規則

Mihomo 是負責解析設定、比對規則與建立代理連線的核心實作。部署在路由器上時，至少要區分三類內容：核心執行參數、代理設定檔，以及系統網路接管規則。設定檔通常包含代理節點、代理群組、規則集、DNS、模式與監聽連接埠；系統層則負責將終端流量送至正確入口。只修改其中一層而未同步另一層，往往無法得到完整結果。

設定中的模式通常包括規則、全域與直連。家用網路長期使用時，規則模式較適合依網域、IP 或規則集分流；全域模式可用來驗證代理鏈路是否可用；直連模式則適合判斷問題是否來自代理節點或規則選擇。切換模式只會改變 Mihomo 處理連線的策略，無法修正預設閘道錯誤、DNS 無法連線或連接埠監聽失敗。

監聽連接埠也需要對應流量類型。HTTP 與 SOCKS 連接埠主要服務於明確設定代理的用戶端；透明代理連接埠用於系統轉送鏈路；DNS 監聽則處理網域名稱解析請求。不要將一般 HTTP 代理連接埠直接當作透明代理入口，也不要在未確認連接埠使用狀況前重複啟動多個服務。路由器系統中還要檢查監聽位址：只監聽迴圈位址時，區域網路終端無法直接存取；監聽區域網路位址時，則需要搭配存取控制。

mixed-port: 7890
mode: rule
allow-lan: true
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053

上方片段僅用來說明設定項目之間的關係，不代表可以直接套用至每一種路由系統。allow-lan 允許區域網路存取明確設定的代理連接埠，但透明代理仍需要由系統端完成轉送；DNS 的監聽連接埠也必須與路由器的 DNS 轉送設定一致。控制面板連接埠更應限制在本機或可信任的管理網段，避免將管理介面暴露給不需要存取的網路。

維護界線：訂閱更新、DNS、IPv6 與復原路徑

訂閱更新應分開看待

訂閱更新通常會替換代理節點、策略群組或規則相關內容，但不會自動理解你的路由拓撲。若更新後的設定缺少原本依賴的策略群組名稱，規則可能會比對到不存在的目標；若訂閱只提供節點，沒有完整的 DNS、TUN 或路由設定，透明代理功能仍需透過本機設定補齊。更新前保留目前可用的設定，更新後先檢查檔案是否成功解析、策略群組是否存在，再測試一台終端。

DNS 是最容易被忽略的中間層

終端能否開啟網域，取決於解析請求傳送到哪裡，以及回傳的位址是否符合目前規則。主路由、旁路由、電信業者 DNS、加密 DNS 與 Mihomo 內建 DNS 可能同時參與處理。若代理連線本身正常但網域解析失敗，應分別測試 IP 存取、區域網路 DNS 連接埠、Mihomo DNS 監聽連接埠，以及規則中的網域解析策略。不要只反覆切換代理模式，因為切換模式不會改變終端實際使用的 DNS 伺服器。

IPv6 不能依 IPv4 經驗推斷

家用網路啟用 IPv6 後，終端可能優先取得 AAAA 記錄，並透過 IPv6 預設路由直連。若只為 IPv4 設定透明代理，使用者會看到部分服務繞過代理，或出現連線等待時間變長的情況。可依實際需求檢查 IPv6 防火牆、路由通告與 Mihomo 的 IPv6 處理能力；在尚未規劃好 IPv6 路徑時，也可以先在測試網段停用 IPv6 進行對照，但應明確這是網路策略選擇，不代表代理核心必然故障。

為主路由保留復原路徑

主路由直接執行核心時，應準備本機管理入口、可用的原始設定，以及停用透明代理的方法。採用旁路由部署時，則要記錄主路由與旁路由的管理位址、DHCP 歸屬，以及預設閘道的變更位置。修改 DHCP 下發的閘道或 DNS 後，終端可能仍保留舊租約，需要重新連線網路或手動更新租約。維護操作應盡量一次只變更一個變數，避免同時升級核心、替換訂閱與調整防火牆。

如何選擇：依涵蓋範圍、效能與故障成本判斷

如果只有少量裝置需要代理，且裝置本身支援系統代理或 Clash 用戶端，繼續在終端執行用戶端通常更容易觀察連線、規則命中與日誌。路由器部署更適合需要統一涵蓋多種裝置，或希望家用網路依同一套規則分流的情境。選擇前應確認裝置效能：記憶體不足會導致核心被系統終止，CPU 較弱時，大量連線、規則集解析與加密轉送可能造成延遲。

較穩妥的驗證順序是：先確認 Mihomo 程序正在運作，再確認設定檔已成功載入；接著從旁路由本機測試節點連線，然後讓一台區域網路終端使用指定入口；最後才將閘道或 DNS 推送給更多裝置。每一步都記錄終端 IP、預設閘道、DNS 位址、代理監聽連接埠與目前模式。這樣發生問題時，就能快速判斷是裝置沒有經過旁路由、流量未進入透明入口、規則選擇不符預期，還是節點本身無法使用。

常見現象與定位順序

• 終端完全沒有代理效果：先查看終端的預設閘道，確認是否指向負責接管代理的裝置；再檢查旁路由是否允許轉送，以及防火牆規則是否已載入。
• 網頁可以開啟但應用程式失敗：應用程式可能使用 UDP、QUIC、獨立 DNS 或 IPv6，測試時可查看連線類型與日誌，不要只根據瀏覽器結果判斷。
• 節點清單存在但全部逾時：從路由器本機測試至節點伺服器的連線能力，檢查時間、出口 DNS、上游防火牆與訂閱中的伺服器位址。
• 區域網路裝置彼此存取異常：檢查透明代理是否錯誤接管內部網路位址，並確認規則對區域網路、保留位址與管理網段的處理。
• 重新啟動後設定失效：查看啟動服務、掛載路徑與設定檔權限，確認核心啟動順序晚於網路介面與儲存裝置掛載。

日誌應結合網路封包擷取或路由表資訊閱讀。只看到「連線失敗」還不足以說明問題出在節點；如果日誌中完全沒有對應網域或目標位址，更可能是終端沒有經過 Mihomo 入口。相反地，若已看到規則命中與出站連線，但回應逾時，就應繼續檢查策略群組、遠端節點與回程網路。

總體而言，Mihomo 路由器部署是一次網路出口設計，而不只是安裝一個程式。主路由直接執行核心追求路徑集中，旁路由則強調職責隔離；透明代理負責接管經過指定節點的連線，規則負責決定連線的處理方式，訂閱則主要提供可更新的節點與設定內容。先釐清這些界線，再依裝置數量、硬體資源與維護能力選擇架構，後續的設定與排查會更容易掌控。