OpenWrt 旁路由部署 mihomo 核心：透明代理架構與設定指南

旁路由架構：先確認流量的傳遞路徑

在 OpenWrt 上執行 mihomo，必須分別處理核心程序、流量接管與 DNS。核心讀取 config.yaml，依據 rules 選擇出口；Linux 路由與防火牆決定哪些封包會進入核心；DNS 則決定終端裝置如何取得 IP 位址，以及網域資訊能否用於分流。啟動程序只完成其中一部分，不代表區域網路已啟用透明代理。

本文以單網路埠、同網段旁路由作為示範環境。以下位址僅供說明網路拓撲，實際部署時請替換為目前使用的網路位址，並確認沒有位址衝突。

測試電腦的 IPv4 預設閘道設為 192.168.10.2，旁路由的預設路由仍指向主路由器 192.168.10.1。兩者不可互相指向，否則會形成路由迴圈。旁路由必須啟用 IPv4 轉送，並允許相關介面或防火牆區域之間轉送流量；這與允許連線至旁路由本機輸入埠是兩回事。

核心架構與設定檔目錄

確認 CPU、系統與執行環境

先透過 SSH 查看系統資訊，再選擇相符的 Linux 核心版本。x86_64 通常對應 amd64，aarch64 通常對應 arm64；32 位元 ARM 還需核對指令集與浮點 ABI。不要只憑路由器商品名稱判斷，也別將 OpenWrt 套件的架構名稱直接當成核心發行檔名稱。

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

選擇 amd64 版本時，也要留意發行說明中的 CPU 指令集需求。啟動時若出現 Illegal instruction，請確認所選版本是否要求超出設備能力的指令集；若出現 Exec format error，先檢查架構與檔案格式。若出現 Permission denied，再檢查執行權限與掛載選項，不要直接歸因於訂閱內容。

分開存放持久檔案與暫存記錄

獨立部署時，可將核心放在 /usr/bin/mihomo、設定檔目錄放在 /etc/mihomo，主要設定檔則使用 /etc/mihomo/config.yaml。這些是本文採用的路徑，並非所有 OpenWrt 管理外掛的預設位置。若已使用管理外掛，應透過同一個管理介面維護程序與防火牆，避免再啟動第二個執行個體。

• /etc/mihomo/config.yaml：存放主要設定。若含有訂閱網址或憑證，請限制檔案讀取權限。
• /etc/mihomo/providers/：可存放設定中引用的 provider 檔案，實際相對路徑由對應欄位指定。
• /tmp/：適合存放暫存診斷檔，重新啟動後通常不會保留，不適合存放唯一的設定檔副本。
• 規則集與地理資料：依實際設定準備。先確認快閃記憶體與記憶體容量，不要預設啟用所有資料來源。

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

以下指令假設核心與設定檔已放在對應路徑。-t 可用來檢查設定，但無法證明節點連線正常或防火牆接管正確。檢查通過後，可先在前景執行並查看啟動記錄；需要常駐執行時，再使用 OpenWrt 的 procd 管理程序，不要依賴 SSH 工作階段中的暫存背景程序。

/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

先測試 mixed-port，再啟用透明代理

建議先讓一台測試電腦明確使用代理，以排除訂閱、出口與規則問題。以下是用於檢查監聽狀態的基本設定：不包含代理節點，最後的規則全部直連，僅用來確認程序、連接埠與請求路徑。若要測試代理出口，請使用有效的個人設定，並確認 proxies、proxy-providers、proxy-groups 與 rules 的名稱引用正確。

mixed-port: 7890
allow-lan: true
bind-address: "192.168.10.2"
mode: rule
log-level: info
ipv6: false

rules:
  - MATCH,DIRECT

mixed-port: 7890 提供 HTTP 與 SOCKS 代理入口。allow-lan: true 允許其他設備連線，bind-address 則限制監聽位址；該位址必須已設定在旁路由上。還需在 OpenWrt 防火牆中，只允許可信任的 LAN 存取 TCP 7890，切勿向 WAN 開放代理連接埠。

測試電腦可執行以下請求。使用基本設定時，應可成功直連；換成有效節點與規則後，再搭配 mihomo 記錄確認實際出口。單次 HTTP 請求成功，不能證明 UDP、DNS 或全網透明代理都已正常運作。

curl -I --proxy http://192.168.10.2:7890 https://example.com/

若這一步失敗，先檢查監聽位址、防火牆輸入規則與核心記錄，不必急著調整 TProxy。若電腦使用明確代理時正常，改用旁路由作為閘道後卻失敗，才進一步檢查轉送、防火牆接管、策略路由與 DNS。

Redir、TProxy 與 TUN 的差異

Redir：開啟監聽連接埠，不代表已完成流量接管

redir-port 是透明代理入口，不是供應用程式填入的 HTTP 代理連接埠。Linux 上的 Redir 通常用於 TCP，不能據此宣稱 UDP 也已透過代理傳送。若只部署 TCP 重新導向，QUIC、遊戲或語音的 UDP 流量可能會直連或連線失敗，實際情況取決於其他防火牆規則。

TProxy：需透過策略路由將封包導向本機

TProxy 可處理 TCP 與 UDP，並保留原始目的地資訊。部署時必須標記指定流量，再透過 ip rule 與對應的路由表將封包導向本機透明監聽埠。只有 tproxy-port: 7893 而沒有這些系統規則，終端裝置的流量不會自動進入 mihomo。

防火牆也必須排除區域網路、廣播、多點傳播、必要的本機服務，以及核心本身的對外連線，以免形成代理迴圈。標記值與路由表編號必須避開系統中既有的 VPN、分流或多 WAN 規則；不能直接照抄其他設備的數值，就認定一定可用。

TUN：另一種接管方式，不是可直接疊加的開關

TUN 需要系統提供可用的 TUN 裝置與相應權限。tun.auto-route 用於自動設定路由；在支援的 Linux 環境中，tun.auto-redirect 也會涉及防火牆接管。不要將這些功能與管理外掛現有的透明代理規則任意疊加。旁路由應先選定一種主要接管方式，再依該方案設定排除規則與還原方式。

DNS 轉發：dnsmasq 與 mihomo 分別監聽不同連接埠

OpenWrt 通常由 dnsmasq 透過 53 連接埠，提供 DNS 服務給 LAN。若 mihomo 也在相同位址的 53 連接埠監聽，就會發生衝突。一種方便檢查的架構是：終端裝置查詢旁路由的 53 連接埠，再由 dnsmasq 將請求轉送至本機 mihomo 的 1053 連接埠。

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

這段設定用來說明本機的轉送關係，列出的上游是一般 DNS，不保證適用於所有網路。dnsmasq 的上游可設為 127.0.0.1#1053；也應確認是否仍會讀取其他上游，避免請求繞過預期路徑。不要再讓 mihomo 的上游指向 dnsmasq 的 53 連接埠，否則會形成 DNS 解析迴圈。

redir-host 與 fake-ip 必須搭配接管方式

redir-host 會向終端裝置回傳真實位址；fake-ip 則會回傳映射位址，並由核心在接管連線時還原網域對應關係。使用 fake-ip 時，取得映射位址的終端裝置必須能將後續連線交回 mihomo。若已切換 DNS，透明接管卻尚未完成，可能會出現「網域解析正常，但所有連線都失敗」的情況。

• 先用一台終端裝置測試 DNS 路徑，確認記錄中出現對應查詢，再擴大套用範圍。
• 若使用以網域名稱指定的加密 DNS 上游，還需依設定處理上游網域的引導解析。
• 終端裝置的私人 DNS 或瀏覽器安全 DNS 可能繞過 DHCP 下發的 DNS 伺服器，請分別確認。
• 修改 DNS 或 fake-ip 模式後，請清除測試終端裝置的 DNS 快取並重新建立連線，避免舊的解析結果影響判斷。

閘道設定、回程路徑與 IPv6

先修改單一終端裝置，再調整 DHCP

在 LuCI 的「網路」→「介面」中確認旁路由的 LAN 位址為 192.168.10.2，IPv4 閘道為 192.168.10.1。介面欄位可能因版本或管理外掛而異，請以介面位址與路由表為準。先在測試電腦手動將閘道與 DNS 設為旁路由位址，確認運作正常後，再考慮對全網下發設定。

若 DHCP 仍由主路由器負責，可在主路由器設定選項 3 為 192.168.10.2、選項 6 為 192.168.10.2，兩者分別代表 IPv4 閘道與 DNS 伺服器。同一個廣播網域內，不要同時啟用兩個未經規劃的 DHCP 服務；修改後還需讓終端裝置更新租約，既有租約不會立即全部更新。

同網段的回程流量不一定會經過旁路由

在單網路介面的旁路由架構中，直連流量從旁路由送往主路由器後，主路由器可能直接將回應交給終端裝置，形成非對稱路徑。部分部署會在旁路由送往主路由器的流量上使用來源 NAT，讓回應經由旁路由返回，但也會隱藏終端裝置的來源位址。是否需要 SNAT 或 masquerade，取決於網路拓撲、狀態追蹤與接管方式，不應一律要求「全部啟用」。

同網段轉送時也要留意 ICMP Redirect：終端裝置可能收到改走較直接路徑的提示，進而改變後續流量路徑。若流量一開始經過旁路由，之後卻繞過旁路由，請一併檢查終端裝置的路由快取與旁路由相關的核心參數。

設定 IPv4 閘道不會接管 IPv6

主路由器透過 RA 下發的 IPv6 預設路由可能仍然有效。即使設定中寫了 ipv6: false，也不代表整個區域網路的 IPv6 已停用。若要代理 IPv6，應另外規劃 IPv6 路由、防火牆與 DNS；尚未部署時，可先在測試終端裝置上限制 IPv6 的使用範圍，並分別測試 IPv4 與 IPv6，避免將流量繞過誤判為規則失效。

驗證步驟與還原檢查

排除問題時，請依序檢查「本機、明確代理、單一終端透明代理、全網設定」。每次只修改一個環節，並記錄修改前的閘道、DNS 與防火牆狀態。管理介面可以開啟，只能證明本機連線可到達旁路由，不能證明對外轉送正常。

1. 檢查程序與設定。執行 mihomo -t，並在前景查看啟動錯誤；確認沒有第二個執行個體占用 7890、7892、7893 或 1053。
2. 檢查旁路由本身的網路連線。執行 ip -4 route，核對預設下一跳；並確認系統時間與 DNS 正常，避免系統時間錯誤導致 HTTPS 請求失敗。
3. 檢查明確代理。使用前述 curl --proxy 指令發出請求，查看記錄中的規則與實際出口，不要只確認網頁能否開啟。
4. 檢查透明接管。關閉測試終端裝置的明確代理，並將閘道設為旁路由；檢查 ip rule show、ip route show table all 與防火牆規則計數。
5. 檢查 DNS 與協定範圍。執行 nslookup example.com 192.168.10.2；確認 TCP 正常後，再測試所需的 UDP 應用程式，最後另外測試 IPv6。

進入常駐執行階段後，使用 procd 管理自動啟動、異常結束與記錄，並確認所需網路與檔案都已就緒。規則更新、provider 下載與訂閱更新都可能產生額外網路請求，請確認這些請求不會再次遭到錯誤接管。快閃記憶體容量有限的設備，避免長期保存大量診斷記錄。

旁路由部署的驗收重點，不是單一開關顯示「執行中」，而是閘道設定、DNS 轉發、透明代理入口與出口規則都能逐層對應。若要查詢設定欄位，請參閱設定參考；若要先在電腦上測試同一份訂閱，可先使用用戶端，確認設定有效後再移轉至 OpenWrt。