OpenWrt 旁路由部署 mihomo：透明代理設定與注意事項

先確認網路拓撲：主路由器負責對外連線，旁路由負責分流

旁路由直接執行 mihomo，首先要處理的是流量路徑，而不是匯入訂閱。建議先只修改一台測試裝置的閘道，確認轉送、DNS 和規則都正常後，再調整 DHCP。本文採用單網卡、同網段旁路由：主路由器繼續撥接、提供 DHCP 和網際網路出口；OpenWrt 連上主路由器的 LAN，由 mihomo 處理指定裝置的流量。

裝置	IPv4 位址	預設閘道與用途
主路由器	`192.168.10.1/24`	連接上游，繼續提供 DHCP
OpenWrt 旁路由	`192.168.10.2/24`	預設閘道為 `192.168.10.1`
測試裝置	`192.168.10.100/24`	閘道與 DNS 均設為 `192.168.10.2`

以上位址僅供完整範例參考，實際設定前請換成自己的網段。旁路由的位址應避開主路由器的動態位址範圍，或在 DHCP 中設定固定租約。在 OpenWrt「網路」→「介面」→「LAN」→「編輯」中設定靜態 IPv4 位址、子網路遮罩和 IPv4 閘道；旁路由本身的閘道不可設為自己的位址。

同一個廣播網域只能有一個 DHCP 服務。請在旁路由 LAN 的「DHCP 伺服器」→「一般設定」勾選「忽略此介面」，但保留 dnsmasq 的 DNS 功能。
主路由器的預設出口不要再指向旁路由，否則容易形成「旁路由送回主路由器，主路由器又轉回旁路由」的轉送迴圈。
測試期間請保留一條可直接連線到主路由器的管理路徑，避免服務停止後無法修改裝置設定。

安裝核心：確認 CPU 架構、工作目錄與執行權限

mihomo 是 Clash Meta 後續採用的核心名稱。直接部署核心不包含圖形介面用戶端，也不會自動產生 OpenWrt 防火牆設定。先透過 SSH 檢查系統，確認下載的是適用於該架構的 Linux 可執行檔：

ubus call system board
uname -m
df -h /overlay /tmp
date
ip -4 route show

x86_64 通常對應 amd64，aarch64 通常對應 arm64。MIPS 裝置還必須確認大小端、指令集和浮點 ABI，不能只憑「64 位元路由器」選擇檔案。出現 Exec format error 時，先確認架構；遇到 Illegal instruction 時，檢查 CPU 指令集需求，不要反覆修改 YAML。

放置執行檔與設定檔

使用 SCP 或 SFTP 將解壓縮後的核心上傳到路由器的 /tmp/mihomo，再執行下列指令。/tmp 通常位於記憶體中，重新啟動後會清空；長期執行的核心和設定檔應放在永久儲存空間。

mkdir -p /etc/mihomo
cp /tmp/mihomo /usr/bin/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0700 /etc/mihomo
/usr/bin/mihomo -v

將實際設定儲存為 /etc/mihomo/config.yaml，並執行 chmod 0600 /etc/mihomo/config.yaml。訂閱網址、節點密碼和控制介面金鑰都屬於敏感資訊。如果設定中啟用了規則集或地理資料庫，請確認相關資源可正常下載，或已放入工作目錄；快閃儲存空間較小的裝置尤其要留意剩餘容量。

TUN 也需要核心支援。以下以 OpenWrt 24.10 系列常見的 opkg 環境為例；使用其他版本時，請先確認韌體所用的套件管理工具和軟體來源。核心模組必須符合目前韌體的核心版本，不可強行安裝其他版本的套件。

opkg update
opkg install kmod-tun ip-full
test -c /dev/net/tun && echo "TUN device ready"

先執行 /usr/bin/mihomo -t -d /etc/mihomo 檢查設定。測試通過只能確認語法正確，且部分資源能初始化，不代表透明轉送已經正常運作。

TUN 與 redir：依協定需求選擇流量接管方式

TUN 透過虛擬網路裝置接收 IP 流量，適合需要同時處理 TCP 和 UDP 的部署。redir 則透過防火牆將 TCP 連線重新導向核心的監聽連接埠，較容易逐段檢查連線路徑，但單獨使用 redir-port 不會接管 UDP。請先擇一使用，不要同時啟用多套外掛、TUN 和手動設定的透明代理規則。

項目	TUN	redir
接管範圍	可處理 TCP 與 UDP，實際能力也取決於節點	主要處理 TCP；UDP 需另外採用 TPROXY 等方案
必要條件	`/dev/net/tun`、路由權限、允許轉送	TCP 監聽連接埠與防火牆重新導向規則
主要檢查項目	策略路由、出口介面判定、TUN 防火牆區域	規則比對、排除保留位址、避免重複接管
本文範例連接埠	`mixed-port: 7890` 用於測試手動代理	`redir-port: 7892`

TUN 最小測試設定

以下是用來確認直連轉送的基本設定。這份設定沒有代理節點，最終規則為 DIRECT，因此測試成功不代表節點代理正常。請先用它檢查 TUN 和 DNS 路徑，再合併實際的 proxies、proxy-providers、proxy-groups 和分流規則；不要用它覆寫尚未備份的設定。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

tun:
  enable: true
  device: mihomo
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

rules:
  - IP-CIDR,192.168.10.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

allow-lan: false 限制的是手動代理的監聽服務，不代表禁止 TUN 處理轉送流量。auto-route 會建立接管流量所需的路由，但不會代替你完成所有 OpenWrt 防火牆區域設定。auto-detect-interface 也需要正常的預設路由才能判斷；若同時使用多 WAN、VPN 出口或其他策略路由，請依實際出口明確設定 interface-name，不要直接假設介面一定是 eth0。

redir 的限制

選用 redir 時，請停用 tun.enable、設定 redir-port: 7892，再於防火牆 prerouting 路徑中，只重新導向指定 LAN 裝置的 TCP 流量。OpenWrt 22.03 及後續版本常用 firewall4 和 nftables，舊教學中的 iptables 指令不一定會建立有效規則。

規則應限定入口介面和測試來源位址 192.168.10.100，並排除路由器管理位址、區域網路及必要的保留位址範圍。
不可將核心自行建立的節點連線再次導回透明代理入口。若要擴大處理路由器本機流量，必須另外設定出口繞行與迴圈防護。
HTTP/3 使用 UDP/443。若只有 TCP redir，瀏覽器的 HTTP/2 和 HTTP/3 可能會走不同出口，這不代表 7892 連接埠失效。
不要整段取代 table inet fw4。規則設為永久生效後，還要測試 /etc/init.d/firewall reload，確認重新載入後規則仍然存在。

DNS 指向：裝置先連旁路由，再由本機服務轉送至上游

建議的初始路徑是：裝置查詢 192.168.10.2:53，OpenWrt dnsmasq 再轉送到 127.0.0.1:1053，最後由 mihomo 查詢明確指定的上游解析器。這樣既能保留 dnsmasq 處理區域網路名稱的功能，也能避免兩個服務同時繫結相同位址的 53 連接埠。

在沒有自訂網域分流解析的簡單環境中，可使用以下 UCI 設定。請先備份 /etc/config/dhcp；這些指令會移除第一組 dnsmasq 既有的一般上游清單。若有企業網域或其他本機轉送規則，請手動合併設定，不要直接執行。

cp /etc/config/dhcp /root/dhcp.before-mihomo
uci set dhcp.@dnsmasq[0].noresolv='1'
uci -q delete dhcp.@dnsmasq[0].server
uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#1053'
uci commit dhcp
/etc/init.d/dnsmasq restart

nslookup example.com 127.0.0.1

noresolv='1' 可避免 dnsmasq 同時讀取自動產生的上游清單。mihomo 的上游解析器不可再設為 192.168.10.2，否則 dnsmasq 和 mihomo 會互相轉送 DNS 查詢，形成迴圈。若節點伺服器使用網域名稱，也要確保代理尚未連線時，解析路徑仍可正常運作。

初次部署時使用 redir-host，比較容易直接檢視解析結果。切換至 fake-ip 前，請先確認旁路由轉送穩定，再依區域網路網域名稱和裝置相容性設定 fake-ip-filter。瀏覽器安全 DNS、Android 私人 DNS，以及應用程式內建的 DoH 可能會繞過一般的 53 連接埠查詢；dns-hijack 不會自動解密這些連線。

OpenWrt 轉送與同網段回程：建立 TUN 還不夠

請在「網路」→「防火牆」中確認實際使用的區域和轉送關係。常見做法是為 TUN 裝置 mihomo 建立獨立區域，允許 LAN 流量進入該區域，並允許 TUN 解出的直連流量前往實際出口區域。單網卡旁路由的出口通常仍是 LAN；不要照搬雙網卡教學，直接認定出口一定屬於 WAN。

允許裝置存取旁路由的 UDP/TCP 53 連接埠；切勿讓 DNS 服務意外開放給不受信任的介面。
確認 net.ipv4.ip_forward 是否設為 1。即使核心已有路由，若未啟用轉送，裝置仍然無法上網。
排除問題時，可暫時停用軟體與硬體流量卸載，避免既有連線走快速路徑，影響規則計數和封包擷取結果。
不要透過全面停用防火牆來「修復」轉送問題。只開放明確需要的區域和方向，並確認現有規則的順序。

同網段還有一個容易忽略的問題：旁路由將直連流量送往主路由器後，主路由器可能直接將回應傳給裝置，造成非對稱路徑。若設計要求轉送流量的往返都經過旁路由，應對指定流量進行範圍受限的來源位址轉換，讓上游看到的來源位址為 192.168.10.2。不要未經判斷就對整個 LAN 區域啟用所有流量的偽裝；另一個較清楚的做法，是將需要代理的裝置放在獨立子網路。

同一介面進出的轉送也可能觸發 ICMP Redirect，通知裝置改走主路由器。在此拓撲中應檢查相關設定，尤其是實際 LAN 裝置上的值：

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.send_redirects
sysctl net.ipv4.conf.default.send_redirects
sysctl net.ipv4.conf.br-lan.send_redirects

ip -4 route show
ip -4 rule show
ip -4 route show table all

如果裝置名稱確實是 br-lan，可將上述三個 send_redirects 項目設為 0，確認有效後再設為永久生效。若介面名稱含有句點，或使用不同的橋接架構，請依實際裝置調整。不要一次修改所有 sysctl 開關，否則很難判斷是哪個變更影響了資料路徑。

開機自動啟動：使用 procd，不是 systemd

OpenWrt 通常使用 procd 管理服務，不適用桌面 Linux 的 systemctl enable mihomo。請先停用其他代理管理外掛，確認沒有第二個程序占用連接埠或維護相同的 TUN 路由，再建立 /etc/init.d/mihomo：

#!/bin/sh /etc/rc.common

START=99
STOP=10
USE_PROCD=1

start_service() {
    /usr/bin/mihomo -t -d /etc/mihomo || return 1

    procd_open_instance
    procd_set_param command /usr/bin/mihomo -d /etc/mihomo
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_set_param limits nofile="65535 65535"
    procd_close_instance
}

此腳本會先檢查設定，再交由 procd 啟動。respawn 範例參數可避免程序在短時間內反覆當機重啟。服務預設以 root 身分執行，以便建立 TUN 和修改路由；若要改用低權限使用者，必須另外規劃權限授予，不能只加上一行使用者名稱。

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo start
logread -e mihomo
ip link show mihomo

# 確認執行與轉送正常後再啟用開機自動啟動
/etc/init.d/mihomo enable

修改 YAML 後，先執行 mihomo -t -d /etc/mihomo；確認通過後，再執行 /etc/init.d/mihomo restart。只有防火牆規則已另行設為永久生效、DNS 服務正常，且啟動後能下載所需資源，才算完整具備開機復原能力；單靠 START=99 無法保證網際網路已連線。

驗收與復原：依序檢查連接埠、DNS、轉送與節點

驗收期間只修改測試裝置的閘道。先在旁路由上測試手動代理，再測試裝置的透明流量，最後才將閘道和 DNS 設定套用到主路由器的 DHCP。如此一來，就能分辨「核心可以連上網路」和「裝置流量已成功接管」。

確認核心正在執行。查看 logread -e mihomo，確認沒有連接埠占用、規則下載失敗或 TUN 建立失敗等問題。若已安裝 ss，可執行 ss -lntup，檢查 7890、1053 等實際監聽狀態。
測試手動代理。路由器若有 curl，請執行 curl -I -x http://127.0.0.1:7890 https://example.com。此步驟不經過裝置的透明轉送；若失敗，請先檢查核心、上游 DNS 和出口。
測試裝置 DNS。在 Linux 測試裝置上執行 nslookup example.com 192.168.10.2，再用 ip -4 route show default 確認閘道。成功解析不代表 TCP 流量已經經過 TUN。
確認透明代理規則有命中。關閉裝置上的應用程式手動代理後，建立新的連線並查看 mihomo 記錄中的來源位址、規則和出站方式。合併節點設定後，應能看到實際的代理群組和節點，而不是一直命中 DIRECT。
測試復原能力。依序測試重新啟動服務、重新載入防火牆及重新啟動裝置。確認 DNS 能否恢復、TUN 是否重新建立，以及裝置是否仍使用原定閘道。

常見狀況與優先檢查項目

狀況	優先檢查項目
路由器可連線，裝置無法連線	裝置閘道、IPv4 轉送、防火牆區域、同網段回程
IP 連線正常，網域名稱無法連線	53/1053 連接埠、dnsmasq 上游、DNS 轉送迴圈
部分應用程式繞過代理	IPv6 預設路由、UDP、應用程式自訂代理或 DNS
小型請求成功，下載常常卡住	路徑 MTU、上游封裝、重傳；不要先盲目調高 TUN MTU
重新啟動後失效	procd 啟用狀態、永久設定檔位置、防火牆規則復原、啟動記錄

需要復原時，先將測試裝置的閘道與 DNS 還原為主路由器 192.168.10.1，再停止 mihomo，移除自訂透明代理規則和轉送設定。如果已將 dnsmasq 設為只轉送至 1053，必須一併還原其上游設定；否則停止核心後，旁路由仍會接收查詢，卻沒有可用的 DNS 解析服務。

/etc/init.d/mihomo stop
/etc/init.d/mihomo disable

# 僅在備份確實是本次部署前的設定時還原
cp /root/dhcp.before-mihomo /etc/config/dhcp
/etc/init.d/dnsmasq restart

最後再決定是否套用至整個網路。主路由器透過 DHCP 選項 3 發布閘道、選項 6 發布 DNS；只有需要經過旁路由的裝置才應取得相應位址。保留網路拓撲紀錄、設定備份和復原方式，比一次套用整套規則更有利於長期維護。欄位說明請參閱設定參考，用戶端匯入流程請見快速入門。