路由器直跑 mihomo 核心部署指南：主路由、旁路由與透明代理的取捨

先確定目標：路由器代理要解決什麼問題

把 mihomo 放進路由器，核心變化不是把桌面用戶端搬到另一台設備，而是將代理入口前移至區域網路閘道。手機、電視、遊戲機與智慧裝置發出的流量會先抵達閘道，再由閘道依據目標網域、目標 IP、來源設備與協定類型，決定 DIRECT、REJECT 或某個代理群組。終端仍可使用一般網路設定，分流邏輯則集中在路由器。

這類部署最適合設備數量多、部分設備無法安裝用戶端、需要統一規則，或希望依來源設備分流的網路。例如電視使用串流節點、辦公電腦使用固定出口、印表機與 NAS 始終直連，訪客網路完全略過代理。規則可集中維護，不必逐台修改。

路由器透明代理也會擴大故障影響範圍。mihomo 設定載入失敗、DNS 上游無法連線、策略路由遺失或防火牆規則順序錯誤，都可能讓一組設備同時斷線。因此，部署前先釐清三個目標：哪些設備需要代理、哪些協定必須支援、mihomo 停止時是否允許自動直連。目標不同，主路由、旁路由與透明代理方案的取捨也會不同。

韌體、架構與硬體門檻

先看 CPU 架構，不要只看路由器型號

mihomo 提供不同架構的 Linux 核心檔案。常見的軟路由是 x86_64，新款 ARM 路由器多為 aarch64，部分舊設備則是 armv7 或 mipsle。下載錯誤架構時，可執行檔通常會直接回報 Exec format error。可透過 SSH 檢查：

uname -m
cat /etc/openwrt_release
ubus call system board
df -h
free -m

以下討論以 OpenWrt 24.10.0、Linux 6.6 與 mihomo 1.19.3 的常見能力為參考，不代表所有韌體都包含相同模組。第三方韌體可能調整核心、nftables、DNS 服務與啟動管理方式，實際部署應以設備上的指令輸出為準。

記憶體與儲存空間要為規則集保留餘裕

只啟動 mihomo 核心與一份小型 YAML 設定檔時，資源需求並不高；但 GeoIP、GeoSite、規則集、Fake-IP 對映、連線表與控制面板都會持續佔用記憶體。硬體規劃可從以下區間開始：

設備資源	適用情境	部署判斷
128 MB 記憶體、16 MB 快閃記憶體	小型規則集、少量設備	空間緊張，升級與回復困難，不建議承擔全家的透明代理
256 MB 記憶體、128 MB 儲存空間	10 至 20 台設備、一般規則集	可以執行，但需控制日誌層級與規則集數量
512 MB 以上記憶體	TUN、較大型規則集、多設備並行	維護餘裕較為充足
x86_64、1 GB 以上記憶體	千兆網路、容器、複雜策略	適合用作主路由或獨立閘道

儲存空間不要只計算 mihomo 可執行檔。設定檔、執行日誌、規則資料庫與更新時的暫存檔也需要空間。建議至少預留 50 MB 可寫入空間；如果規則資料與日誌存放在本機，預留 100 MB 以上會更穩妥。快閃記憶體不足時，可將資料目錄放到掛載磁碟，但啟動腳本必須等待掛載完成。

吞吐量取決於單核心效能、協定與加密

路由器包裝上標示的「千兆」通常是指硬體 NAT 條件下的轉發速度，不等於代理吞吐量。透明代理會讓流量進入使用者空間，協定加密、規則比對與連線重用都會消耗 CPU。一台四核心 ARM 設備在一般 NAT 下能跑滿 940 Mbps，不代表 mihomo 經由加密節點後仍能達到相同數字。

測試時至少記錄三組數據：直連測速、終端執行用戶端測速、路由器透明代理測速。也要觀察 top 中是否有單一核心接近 100%。如果透明代理只有 180 Mbps，而終端用戶端可達 600 Mbps，瓶頸通常在路由器 CPU、虛擬網卡處理或協定實作，而不是訂閱節點本身。

主路由直跑：路徑最短，故障範圍最大

主路由部署是最直接的架構。主路由同時負責撥號或上聯、DHCP、DNS、防火牆、NAT 與 mihomo。所有終端的預設閘道都指向主路由，流量自然會經過代理規則，不需要額外修改下一跳。

終端設備
  ↓ 預設閘道
主路由：DHCP / DNS / 防火牆
  ↓ 透明代理規則
mihomo：規則比對
  ├─ DIRECT → WAN
  ├─ REJECT → 丟棄
  └─ 代理群組 → 遠端節點 → 目標網站

主路由方案的優點

網路拓撲簡單，預設閘道只有一個。
來源 IP、MAC 對應位址與訪客網路介面更容易識別。
DNS 劫持、IPv4 策略路由與防火牆規則集中管理。
終端彼此存取 NAS、印表機與投放裝置時，路徑更容易控制。

主路由方案的代價

設定錯誤會影響整個網路，復原操作必須能繞過代理。
韌體升級可能重設防火牆自訂規則或套件。
主路由 CPU 同時處理 PPPoE、SQM、Wi-Fi、NAT 與代理，資源競爭會更明顯。
部分硬體 NAT、流量卸載與軟體流量卸載功能可能繞過透明代理鏈，必須停用或重新驗證。

如果選擇主路由直跑，至少要保留一個管理入口。可以保留一條只允許區域網路存取的 SSH 路徑，也可以為管理電腦設定靜態位址，並準備停止 mihomo、清除策略路由與恢復 DNS 的指令。不要將管理網域、路由器自身的更新流量與代理節點位址再次送入代理，否則容易形成迴圈。

旁路由部署：改動較小，但回程路徑要釐清

旁路由通常是一台接入主路由 LAN 的獨立設備。它不一定負責撥號，也不一定接管整個網路的 DHCP。mihomo 在旁路由上執行，指定終端將預設閘道或策略下一跳指向旁路由，再由旁路由轉送至主路由連接網際網路。

測試電腦 192.168.10.50
  ↓ 閘道 192.168.10.2
旁路由 192.168.10.2：mihomo
  ↓ 上游閘道 192.168.10.1
主路由 192.168.10.1
  ↓
網際網路

接法一：終端手動指定旁路由閘道

這是最容易排除問題的旁路由方式。主路由位址設為 192.168.10.1，旁路由設為 192.168.10.2，將測試電腦的預設閘道改成 192.168.10.2。旁路由自身的預設路由仍指向 192.168.10.1。如果測試失敗，只要把電腦閘道改回主路由即可。

DNS 可以先明確設定為旁路由位址，確認 mihomo DNS 正常後再透過 DHCP 下發。旁路由必須啟用 IPv4 轉送，並允許 LAN 流量從入站介面轉送至主路由。如果兩台設備位於同一網段，尤其要檢查回程是否繞過旁路由；只看網頁能否開啟，不足以判斷透明代理是否完整。

接法二：主路由依設備下發不同閘道

支援 DHCP 選項或策略路由的主路由，可以依 MAC 位址為指定設備下發旁路由閘道。如此一來，不必在電視或手機上手動填寫靜態位址。設定時要為旁路由建立固定租約，避免位址變動。也要明確 DNS 由誰下發：閘道指向旁路由，但 DNS 仍指向公共解析器，可能造成網域規則失效或解析路徑洩漏。

旁路由常見的迴圈錯誤

最典型的問題是旁路由自身的代理連線又被透明代理規則攔截。mihomo 連線至遠端節點時，資料再次進入 mihomo，最後逾時。處理方法包括依程序身分繞過、依防火牆標記繞過、將節點伺服器 IP 加入直連集合，以及讓路由器本機流量與轉送流量進入不同鏈。

另一個問題是主路由將回傳封包直接交給終端，而去程經過旁路由。一般 TCP 有時仍可運作，但依賴連線追蹤、來源位址轉換或 TProxy 標記的流程可能不相容。工程上更穩妥的做法是讓旁路由執行必要的 SNAT，或使用獨立子網路明確分隔上下游，避免同網段內的非對稱路由。

透明代理的三種實作路徑

透明代理不是單一開關。Linux 路由器上常見的方案包括 Redirect、TProxy 與 TUN。三者都能將終端流量交給 mihomo，但支援的協定、路由方式與排錯重點各不相同。

Redirect：適合先讓 TCP 跑通

Redirect 通常透過 NAT 規則將 TCP 連線重新導向 mihomo 的 redir-port。設定範例：

redir-port: 7892
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

它的優點是概念簡單，適合驗證 HTTP、HTTPS 與大多數 TCP 應用程式。限制也很直接：UDP 無法靠 TCP Redirect 完整處理。QUIC、部分遊戲、語音與基於 UDP 的 DNS 都需要額外方案。如果只驗證網頁存取，Redirect 是合理的起點；準備接管整個網路時，通常還要加入 TProxy 或 TUN。

TProxy：保留目標位址，涵蓋 TCP 與 UDP

TProxy 借助策略路由、封包標記與防火牆透明代理目標，將 TCP 與 UDP 傳送至 mihomo 的 tproxy-port。核心需要相應的透明代理模組，OpenWrt 也要確保 nftables 或 iptables 規則與目前的防火牆架構相符。

tproxy-port: 7893
mixed-port: 7890
allow-lan: true
mode: rule

TProxy 的關鍵不只是一條連接埠規則。封包通常會先被標記，再由 ip rule 選擇專用路由表，將目標送回本機透明代理連接埠。如果只寫防火牆規則而沒有策略路由，連線會直接失敗。如果代理節點 IP、區域網路網段與保留位址沒有預先繞過，可能出現迴圈或本地服務失去連線。

排查 TProxy 時，可以依序檢查監聽連接埠、nftables 計數器、策略規則與路由表：

ss -lntup
nft list ruleset
ip rule show
ip route show table all
conntrack -L | head

TUN：接管範圍更完整，路由衝突也更多

mihomo 的 TUN 模式會建立虛擬網卡，將符合條件的流量送入使用者空間協定堆疊。它通常能統一處理 TCP 與 UDP，也方便在不同 Linux 環境中重用設定。精簡示意如下：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053

auto-route 與 auto-redirect 能否如預期運作，取決於作業系統、mihomo 版本與防火牆環境。在已有多 WAN、VPN、WireGuard、策略路由或容器網路的設備上，自動寫入的路由可能與現有規則衝突。部署前應保存 ip rule、ip route 與 nft list ruleset 的輸出，以便比較。

TUN 也不代表一定有較高效能。使用者空間網路堆疊、GRO、MTU 與 UDP 處理都會影響吞吐量。如果某些網站載入到一半停止，可以嘗試檢查路徑 MTU。PPPoE 常見介面 MTU 為 1492，加上通道後可用值會更低；沒有封包擷取依據時，不要任意將 TUN MTU 調成極端數值。

DNS 決定網域規則能否命中

透明代理最容易被低估的部分是 DNS。規則中寫了 DOMAIN-SUFFIX，不代表路由器一定知道連線對應的網域。如果終端直接存取外部 DNS、啟用加密 DNS，或只將目標 IP 交給透明代理，網域規則的命中率就會下降。

Fake-IP 流量鏈

終端向路由器查詢網域。
mihomo DNS 回傳 Fake-IP 位址，並儲存網域對映。
終端連線至這個 Fake-IP。
透明代理攔截連線，mihomo 從對映中還原原始網域。
規則引擎依網域選擇 DIRECT、REJECT 或代理群組。

Fake-IP 適合依賴網域分流的網路，但區域網路網域、印表機探索、部分遊戲與特殊應用程式可能需要加入過濾清單。路由器管理網域、本地域名後綴與私有位址解析應優先交給本地 DNS，不要送往遠端代理。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.lan"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver 用於解析代理節點伺服器網域。這條解析鏈必須能在代理尚未建立時運作，否則會出現必須先連線節點才能解析、必須先解析才能連線節點的依賴迴圈。實際設定也應配合所在網路選擇可連線的上游，不要機械式複製位址。

連接埠 53 的接管範圍

傳統 DNS 使用 UDP 或 TCP 53，可以在路由器上將其重新導向至 mihomo DNS，例如轉送至本機 1053。但 DoH 使用 HTTPS，DoT 通常使用 TCP 853，無法只靠一條 53 連接埠規則接管。如果終端啟用了系統層級加密 DNS，需要透過設備管理停用、以規則限制已知端點，或接受該設備不參與網域強化解析。

規則設計：先繞過，再接管

路由器規則的首要任務不是將更多流量送進代理，而是明確哪些流量絕不能進入代理。區域網路位址、組播、廣播、DHCP、路由器管理位址、代理節點伺服器與必要的時間同步都應先繞過。否則可能破壞設備探索、投放、NAS 存取或節點本身的連線。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

來源設備分流可透過來源 IP 網段實現。例如為電視固定位址 192.168.10.60，讓訪客網路使用 192.168.30.0/24，再依來源選擇策略。固定租約比依賴動態位址更可靠。規則順序仍是由上至下比對，區域網路繞過規則應放在來源設備代理規則之前。

IPv6 需要單獨決定。只接管 IPv4、保留 IPv6 直連時，應用程式可能優先使用 AAAA 記錄，導致規則時靈時不靈。可選方案有三種：完整設定 IPv6 透明代理；測試階段停止向受控終端下發 IPv6 預設路由；明確接受 IPv6 直連並將其納入安全邊界。不要只在 mihomo 設定中寫入 ipv6: false，卻讓終端繼續透過路由器取得公網 IPv6。

一套可回復的部署流程

記錄現況。儲存主路由位址、DHCP 範圍、DNS、預設路由、防火牆規則與現有 VPN 設定。
驗證二進位檔。透過 SSH 執行 mihomo -v，確認架構正確；再使用 mihomo -t -d /etc/mihomo 檢查設定。
只開啟控制連接埠。先啟動 mixed-port: 7890，讓測試電腦手動設定 HTTP 或 SOCKS5 代理，確認節點與規則可用。
接入 DNS。讓一台測試設備將 DNS 指向路由器，使用 nslookup 或 dig 檢查回傳結果。
加入透明代理。優先只處理測試設備的來源 IP，暫時讓其他設備保持直連。
測試 TCP、UDP 與本地服務。檢查網頁、影片、語音、遊戲、NAS、印表機與投放功能，不要只測一次速度。
設定啟動與回復。mihomo 啟動失敗時，不要繼續保留強制重新導向規則；停止服務後應恢復一般轉送。
逐步擴大範圍。從一台設備擴展到一個 VLAN，最後才考慮接管整個網路。

執行日誌在除錯階段可設為 info，定位規則時短暫使用 debug。長期維持高日誌層級會增加儲存寫入與 CPU 負載。穩定後應設定日誌輪替，並定期觀察記憶體、連線數與程序重新啟動次數。

哪些情境適合，哪些情境應留在終端

適合部署在路由器

電視、遊戲機與智慧裝置無法安裝代理用戶端。
家庭或小型辦公室需要統一維護規則與訂閱。
需要依設備、VLAN 或來源網段選擇不同策略。
路由器硬體效能充足，並具備穩定的 SSH 管理路徑。
維護者了解 DHCP、DNS、路由表、nftables 與連線追蹤。

更適合繼續使用終端用戶端

只有一兩台電腦需要代理，其他設備全部直連。
主路由是電信業者提供的設備，無法安裝軟體或查看防火牆規則。
網路依賴企業 VPN、複雜的多 WAN 或嚴格的終端驗證。
需要頻繁切換設定，並希望故障只影響單一設備。
路由器的記憶體、儲存空間或單核心效能已接近上限。

實際部署不必二選一。常見的組合是路由器只負責電視、訪客網路與無法安裝用戶端的設備，開發電腦則繼續執行桌面用戶端。如此既保留設備層級的控制，也避免將所有複雜策略集中在單一閘道。

最終判斷可以歸結為一點：主路由追求拓撲簡單，旁路由追求改動可控，TProxy 追求 Linux 原生透明轉送，TUN 追求統一接管能力。選型時先看故障邊界，再看功能數量。能快速停用、能恢復 DNS、能繞過節點迴圈的方案，才適合長期運作。

繼續設定用戶端

先在電腦端驗證訂閱、節點與規則，再決定是否將同一套分流邏輯移植到路由器。

前往下載頁查看教學