路由器與旁路由直跑 mihomo 核心部署指南：架構選擇與設定要點

先確認部署目標：路由器上的 mihomo 負責什麼

在 Windows、macOS 或手機上執行 Clash 圖形化客戶端時，代理通常只涵蓋目前裝置。將 mihomo 核心部署到路由器或旁路由後，流量入口會移至區域網路閘道，電視、遊戲主機、智慧音箱，以及不便安裝客戶端的裝置，也能依規則分流。這裡的 mihomo 是由 Clash Meta 延續發展的核心，可讀取 Clash 風格的 YAML 設定，並提供規則比對、策略群組、DNS、TProxy、重新導向與 TUN 等功能。

路由器部署的重點不是「讓核心執行起來」，而是確保封包確實經過它，並能正確返回。完整鏈路至少包含四個部分：區域網路裝置將資料交給閘道、路由規則把目標流量送入 mihomo、核心依規則選擇直連或代理出口，返回流量再沿正確路徑回到原裝置。只啟動程序卻未設定透明代理規則時，區域網路裝置不會自動使用它。

主路由與旁路由的核心差異

主路由方案的鏈路最清楚：LAN 客戶端的預設閘道就是執行 mihomo 的裝置，防火牆只需辨識哪些流量要交給透明代理連接埠。旁路由方案則必須回答一個額外問題：客戶端為什麼會把封包發給旁路由？常見做法是將指定裝置的預設閘道設為旁路由位址，或由主路由依來源位址實施策略路由。只將客戶端 DNS 指向旁路由，並不能讓一般 TCP、UDP 流量自動經過旁路由。

如何選擇韌體、架構與硬體資源

mihomo 提供適用於不同 CPU 架構的可執行檔。部署前應透過 uname -m 確認系統架構，而不是只看路由器商品名稱。常見結果包括 aarch64、armv7l、x86_64 與 mips。下載檔案的架構必須與系統相符；例如 64 位元 ARM 韌體通常使用 ARM64 建置版本，而安裝 32 位元韌體的裝置，即使 CPU 支援 64 位元，也不能直接執行 ARM64 檔案。

韌體需要具備的基本能力

• Linux 核心支援策略路由，系統中可以使用 ip rule 與 ip route。
• 防火牆具備 nftables 或 iptables 能力，並支援透明代理所需的 TProxy 模組。
• 檔案系統有可持久寫入的位置，用於儲存設定、規則集、GeoIP 與 GeoSite 資料。
• 能夠註冊開機服務，例如 OpenWrt 的 procd 或一般 Linux 的 systemd。
• 系統時間與 DNS 必須正常運作，否則訂閱更新、TLS 連線與網域規則可能異常。

OpenWrt 23.05 及後續常見建置主要採用 firewall4 與 nftables，舊教學中的 iptables 指令不應直接混用。部署前可在 LuCI 進入「系統」→「套件」，確認 TProxy、nftables 與策略路由相關元件是否存在；也可以透過 SSH 執行 nft list ruleset 檢查目前的防火牆體系。若指令不存在，應先補齊韌體元件，而不是反覆修改 mihomo 設定。

記憶體、儲存空間與 CPU 的實際門檻

核心本身只是一部分開銷。設定中的規則數量、GeoSite 資料、DNS 快取、連線數與面板資源都會佔用記憶體。128 MB 記憶體的裝置可以執行精簡設定，但載入大型規則集、啟用 fake-ip 及處理大量並行連線時，剩餘空間很有限；256 MB 更適合作為基本起點，512 MB 以上則方便同時執行廣告過濾、DNS 服務與監控元件。

以下資料來自一台 RK3399 六核心 ARM64 裝置，配備 4 GB 記憶體、OpenWrt 23.05.5 與 mihomo v1.19.10 的區域網路測試。測試線路為 300 Mbps，下游客戶端使用千兆有線連線，設定約包含 8.6 萬條網域及 IP 規則。結果僅用於估算量級，不代表在不同加密方式、節點距離與韌體建置下都能重現。

百兆寬頻與少量終端對 CPU 要求不高，但千兆連線、WireGuard、複雜加密與大量 UDP 會顯著增加負載。軟路由裝置還要注意網路埠是否共用匯流排，以及是否存在 USB 網卡瓶頸。只看 CPU 時脈無法判斷吞吐量，AES 指令、核心驅動與散熱同樣會影響持續效能。

透明代理方式：TProxy、重新導向與 TUN

路由端常見的接管方式有 REDIRECT、TProxy 與 TUN。REDIRECT 主要處理 TCP，結構相對簡單，但無法完整涵蓋 UDP，也會改變核心處理目標位址的方式。TProxy 可以透明接管 TCP 與 UDP，並保留原始目標資訊，是 Linux 路由情境中常用的方案。TUN 透過虛擬網卡接收 IP 流量，設定概念直觀，但在低效能路由器上通常有較高的內容切換與協定堆疊開銷。

TProxy 連接埠與策略路由

mihomo 的 tproxy-port 只負責監聽透明代理流量。防火牆還需要為選定的封包加上標記，再由策略路由將帶有標記的資料送至本機回環介面。常見的監聽連接埠是 7893，但連接埠號本身沒有強制要求，只要設定、nftables 規則與服務權限保持一致即可。

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

external-controller: 127.0.0.1:9090
secret: "請設定一組獨立的控制金鑰"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

mixed-port: 7890 可供區域網路內臨時手動測試 HTTP 或 SOCKS 代理，但若確實要讓其他裝置存取，仍應使用防火牆限制來源網段。控制介面建議維持監聽 127.0.0.1:9090，需要遠端面板時，透過受控的反向代理或 SSH 轉送存取，不應直接暴露至 WAN。

什麼時候考慮 TUN

如果韌體缺少完整的 TProxy 模組，或希望減少手動撰寫策略路由的工作，可以評估 TUN。mihomo 的 TUN 設定通常需要指定自動路由與介面探測，但當路由器同時負責 WAN、LAN、撥號與橋接時，自動探測不一定能選到預期的出口。部署後應檢查預設路由、TUN 路由表與本機網段，尤其要避免將路由器管理位址與上游閘道送入 TUN。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed 是常見起點，但不同平台的支援情況會隨核心版本變化。啟用 dns-hijack 前，需要確認區域網路的 53 連接埠沒有同時被 dnsmasq、AdGuard Home 與另一套重新導向規則重複接管。實際部署時，可以讓 dnsmasq 繼續監聽 LAN 的 53 連接埠，再將特定查詢轉送至 mihomo 的 127.0.0.1:1053，如此 DHCP 網域與本地主機名稱仍由 dnsmasq 管理。

主路由部署：將故障範圍控制在服務層

主路由方案中，所有客戶端預設都已經過該裝置，因此不需要修改每台終端的閘道。較穩妥的啟用順序是：先讓 mihomo 以一般混合代理模式執行，確認 127.0.0.1:7890 可用；再為一台測試裝置加入透明代理規則；最後才將規則擴充至整個 LAN。如此即使 YAML 或規則有誤，路由器的基本 NAT 與 DHCP 仍能正常運作。

1. 為路由器保留一條可直接連線的管理路徑，例如有線管理埠，或不經透明代理的管理裝置。
2. 將測試客戶端固定為靜態 DHCP 租約，方便依來源 IP 新增規則。
3. 先接管該客戶端的 TCP，再驗證 UDP、DNS 與 IPv6。
4. 確認直連網站、代理網站、區域網路裝置存取與路由器管理介面均正常。
5. 儲存可回復的防火牆設定，再逐步擴大接管範圍。

IPv6 是常見的遺漏點。若區域網路客戶端同時取得公網 IPv6 位址，而透明代理只處理 IPv4，部分應用程式可能直接走 IPv6，表現就像規則隨機失效。解決方向不是簡單關閉所有 IPv6，而是明確選擇：完整接管 IPv6、讓相關網域回傳 IPv4，或在目前網路尚未準備好時，從 RA 與 DHCPv6 層統一關閉。設定中的 ipv6: true 只代表 mihomo DNS 與連線能力允許 IPv6，並不會自動補齊防火牆規則。

主路由方案的回復設計

透明代理服務停止時，若防火牆仍將流量送至 7893，客戶端就會斷網。啟動腳本應先啟動核心並檢查監聽連接埠，再載入透明代理規則；停止腳本則應先移除規則，再結束程序。OpenWrt 上也可以讓 procd 監控程序並設定重新啟動策略，但不要無限快速重啟；設定語法錯誤時持續啟動會佔用 CPU 並塞滿日誌。

旁路由部署：閘道、回程與單臂架構

旁路由通常與主路由位於同一網段。例如主路由位址為 192.168.10.1，旁路由為 192.168.10.2。若測試電腦將預設閘道設為 192.168.10.2，旁路由必須啟用 IP 轉送，並將未代理或代理後的流量正確送往 192.168.10.1。此時旁路由既是客戶端閘道，也是 mihomo 的執行位置。

單臂旁路由只有一個 LAN 介面，入站與出站流量經過同一個實體連接埠。它的佈線簡單，但要特別注意回程路徑。若主路由直接將返回封包交給客戶端，而請求封包經過旁路由，狀態追蹤可能出現不對稱。常見處理方式是對旁路由轉送的流量進行來源位址轉換，或在主路由上新增指向客戶端網段的靜態路由。前者設定容易但會隱藏客戶端原始位址，後者保留位址資訊，但要求主路由支援精確的路由設定。

讓客戶端經過旁路由的三種方法

• 手動指定閘道：只修改一兩台裝置，適合測試。客戶端閘道指向旁路由，DNS 可指向旁路由或指定的區域網路 DNS。
• 由 DHCP 發放旁路由閘道：適合整個網路遷移，但網路中只能有一套明確負責分配位址的 DHCP 服務，避免客戶端取得衝突的閘道。
• 主路由策略路由：主路由依客戶端 IP、MAC 對應的固定租約或網段，將流量送往旁路由，適合分組啟用，但取決於主路由的韌體能力。

旁路由不應與主路由同時在同一廣播網域中任意發放 DHCP。若需要由旁路由提供 DHCP，應關閉主路由對應介面的 DHCP 服務，或將兩者分隔至不同 VLAN。遷移期間保留一台閘道固定為主路由的管理電腦，便能在旁路由設定失敗時繼續登入兩台裝置的管理介面。

設定檔、訂閱與規則集的存放方式

mihomo 應從持久化目錄讀取設定。OpenWrt 常用 /etc/mihomo/config.yaml 儲存主要設定，/etc/mihomo/providers/ 儲存代理提供者檔案；執行期間的快取與大型資料庫則可放在 /var/lib/mihomo/ 或掛載的儲存空間中。不要將唯一的設定放在 /tmp，因為 OpenWrt 的 /tmp 通常位於記憶體檔案系統，重新啟動後內容會消失。

/etc/mihomo/
├── config.yaml
├── providers/
│   ├── primary.yaml
│   └── backup.yaml
└── rules/
    ├── direct.yaml
    └── proxy.yaml

/var/lib/mihomo/
├── cache.db
├── country.mmdb
└── geosite.dat

訂閱網址可以寫在 proxy-providers 中，由 mihomo 按間隔更新。路由器快閃記憶體的寫入壽命有限，更新間隔沒有必要設定得過短。多數情況可從 interval: 21600，也就是 6 小時開始；規則集則可依變更頻率設定為 12 小時或 24 小時。每分鐘抓取一次不僅會增加上游請求，也會產生不必要的寫入與日誌。

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

上方的網域僅用於展示設定結構，部署時需要替換為實際訂閱網址。設定檔通常包含存取憑證，應限制檔案權限，例如只允許服務使用者與管理員讀取。修改 YAML 後，先執行核心提供的設定檢查，再替換目前檔案。縮排必須使用空格，策略群組引用的 provider 名稱、規則集名稱與出站名稱也必須完全一致。

開機自動啟動、健康檢查與日誌排錯

手動執行指令適合首次驗證，長期運作則應交由服務管理器負責。OpenWrt 使用 procd 時，服務腳本應指定可執行檔、工作目錄、設定目錄、標準輸出與重新啟動策略。一般 Linux 旁路由可以使用 systemd，並透過 After=network-online.target 等待網路準備完成。服務啟動成功不代表透明代理已正常運作，還要檢查連接埠、防火牆規則、策略路由與 DNS。

建議的啟動檢查順序

1. 執行 mihomo -t -d /etc/mihomo，檢查設定是否能正確解析。
2. 啟動服務後，使用 ss -lntup 確認 7890、7893、9090 與 1053 中實際啟用的連接埠。
3. 使用 ip rule 與 ip route show table all 檢查策略路由表。
4. 使用 nft list ruleset 檢查流量標記、保留位址放行與透明代理轉送。
5. 從一台測試客戶端分別測試網域存取、直接存取 IP、UDP 應用程式與區域網路裝置。

設定錯誤通常會在啟動日誌中提供欄位路徑與行號。OpenWrt 可在 LuCI 的「狀態」→「系統日誌」中查看，也可執行 logread -e mihomo。若程序存在但客戶端無法連線，優先確認透明代理連接埠是否正在監聽；若只有網域解析失敗，檢查 DNS 上游與 53 連接埠鏈路；若 TCP 正常但遊戲、語音失敗，檢查 UDP 是否經過 TProxy；若無法存取路由器管理介面，檢查區域網路保留位址是否被誤接管。

架構選擇結論：依維護成本，而非功能數量決定

現有主路由具備足夠的 CPU、記憶體與可維護韌體，且家庭網路結構簡單時，直接在主路由執行 mihomo 能減少中間層，預設閘道與透明代理路徑也更清楚。部署時應保留管理入口，先針對單一測試 IP 啟用，再擴大至整個區域網路。

主路由由電信業者管理、韌體擴充能力有限，或希望將代理故障與基本上網隔離時，旁路由更合適。旁路由應明確採用「客戶端閘道指向旁路由」或「主路由策略轉送」其中一種方案，並提前處理 DHCP、回程路由與 DNS，避免依賴多套規則碰巧連通。

TProxy 更適合功能完整的 Linux 路由環境，能同時涵蓋 TCP 與 UDP；TUN 適合希望由虛擬網卡統一接管，且硬體資源較充足的裝置。無論選擇哪種方式，穩定部署都依賴相同原則：設定持久化、節點連線繞行、服務與防火牆依序啟動、保留回復通道，並以單台客戶端逐項驗證。