主路由與旁路由：先確認流量會經過哪裡
在 OpenWrt 上執行 mihomo，關鍵不只是安裝二進位檔，而是確保目標流量會經過它。mihomo 是 Clash Meta 後續採用的核心名稱；核心負責代理協定、規則比對與連線處理，OpenWrt 則負責網路介面、路由、防火牆及服務管理。設定檔通過語法檢查，不代表區域網路裝置已經由它接管。
主路由通常直接負責對外連線、NAT 和 DHCP。旁路由則是區域網路中的另一台裝置，主路由仍負責撥號或連接上游網路。本文以單網路埠、同網段旁路由為例；雙網路埠串接的裝置，必須依實際介面重新規劃轉送區域，不能直接套用同網段設定。
| 項目 | 主路由部署 | 旁路由部署 |
|---|---|---|
| 對外連線出口 | OpenWrt 直接連接上游網路 | 保留現有主路由作為出口 |
| 終端預設閘道 | OpenWrt 的 LAN 位址 | 要接管的終端改指向旁路由 |
| DHCP 服務 | 通常由 OpenWrt 提供 | 可繼續由主路由提供 |
| 故障影響範圍 | 可能影響所有終端 | 可先限定一台測試終端 |
| 主要難點 | 出口防火牆與資源負載 | 閘道、回程路徑與 DNS 一致性 |
同網段範例位址
- 主路由：
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 伺服器設定固定租約，並避免與動態位址池重疊。兩台裝置不可在同一廣播網域內，同時發送未經協調的 DHCP 設定。
部署前檢查：架構、儲存空間與韌體支援
先在 OpenWrt 的「狀態」→「概覽」查看韌體資訊，再透過 SSH 確認 CPU 與系統架構。商品名稱標示的「64 位元處理器」不能代表韌體架構：同一硬體可能執行不同位元數的使用者空間。
ubus call system board
uname -m
cat /etc/openwrt_release
df -h /overlay /tmp
free -mx86_64 通常對應 amd64 版本，aarch64 通常對應 arm64 版本。ARM 32 位元還需確認指令集；MIPS 則要分辨位元組序與浮點 ABI。不同版本的發佈檔案命名可能變動，請依 mihomo 發佈說明選擇，不能只憑檔名含有「linux」就判定可用。
套件管理工具與核心模組
- 使用 opkg 的韌體可透過
opkg print-architecture查看套件架構；使用 apk 的韌體則可用apk --print-arch輔助判斷。請勿混用兩種套件管理工具的安裝指令。 - TUN 方案需要韌體支援 TUN，常見相關套件為
kmod-tun；TPROXY 則需要相應的防火牆與核心模組支援。 - OpenWrt 22.03 起，預設防火牆通常為 firewall4，底層採用 nftables。舊教學中的 iptables 規則不宜直接複製到 firewall4 環境。
- 核心模組必須與目前執行的韌體核心版本相符。若套件庫無法使用或版本不一致，應先處理韌體與軟體來源的相容問題。
直接執行核心：先測試設定與一般代理
常見部署方式有兩種：透過 OpenWrt 外掛管理核心，或直接執行 mihomo。外掛通常會一併管理服務腳本、防火牆、DNS 與訂閱更新；直接執行則需要逐一設定這些功能。同一個執行個體應擇一管理，避免外掛啟動的核心與手動程序爭用監聽埠。
以下假設已將符合架構的核心解壓縮至 /usr/bin/mihomo，並將完整設定檔放在 /etc/mihomo/config.yaml。這是本文使用的路徑，不是所有外掛的預設路徑。若訂閱內容只有節點清單，還需要補上代理群組、規則等完整設定。
chmod 0755 /usr/bin/mihomo
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml-v 用來確認程式能否執行並查看實際版本，-t 用來測試設定檔。若出現 Exec format error，優先檢查架構是否相符、檔案是否已解壓縮；若出現 YAML 解析錯誤，應先修正縮排、欄位型別或引用的規則集，不要急著疊加網路設定。
使用 7890 埠測試代理連線
可先將以下片段合併至完整設定檔。範例只允許監聽旁路由的區域網路位址；其他裝置能否連線，還取決於防火牆設定。啟用 allow-lan 後，請勿將該埠暴露於公網。
mixed-port: 7890
allow-lan: true
bind-address: 192.168.10.2
mode: rule
log-level: info測試通過後，可在 SSH 前景啟動核心，方便觀察錯誤訊息。此時不要同時啟動另一個相同執行個體。
/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml在測試電腦上將 HTTP 代理設為 192.168.10.2:7890，或使用以下指令發出 HTTPS 請求。若連線成功，表示一般代理入口、節點與目標網站之間的基本路徑可用，但不代表 UDP 或透明代理已生效。
curl -I --proxy http://192.168.10.2:7890 https://example.com/前景測試完成後，再交由 procd 服務腳本管理，設定開機啟動與異常重啟。服務應使用絕對路徑，並將記錄寫入系統日誌；不要依賴關閉 SSH 後可能終止的暫時程序。
透明代理方案：REDIRECT、TPROXY 與 TUN
在終端手動設定代理，只會影響遵循該設定的應用程式。旁路由若要接管一般轉送流量，還需要透明代理入口及相應路由。以下三種方案並非可以任意同時啟用的開關；尤其要避免外掛規則與手動規則重複攔截同一批流量。
| 方案 | 主要入口 | 額外條件 |
|---|---|---|
| REDIRECT | redir-port: 7892，通常用於 TCP | 需要 NAT 重新導向規則，不能因此認定 UDP 也已接管 |
| TPROXY | tproxy-port: 7893，可處理 TCP 與 UDP | 需要透明通訊端支援、標記與策略路由 |
| TUN | 虛擬網路介面 | 需要 TUN 支援、路由與轉送權限，以及正確的防火牆設定 |
TUN 設定片段的適用範圍
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53這段設定展示 mihomo 的 TUN 設定方式，並不是完整的 OpenWrt 透明代理部署腳本。auto-route 可設定相關路由，但不代表所有 LAN 拓撲都已打通。仍須確認 LAN 轉送流量是否進入 TUN、對外連線能否抵達主路由，以及 firewall4 是否允許必要的轉送。
在多出口環境中，自動偵測可能選到非預期的出口，應檢查實際路由，必要時依核心設定文件指定介面。Linux 上的 auto-redirect 是另一項涉及 nftables 的選項，是否可用及其行為應以實際 mihomo 版本為準；不要將新版範例原封不動套用至舊版核心。
閘道與 DNS：分開設定、分別驗證
預設閘道決定一般流量的下一個節點，DNS 則決定網域查詢要送往哪裡。只改 DNS，網路連線仍可能繞過旁路由；只改閘道，終端也可能繼續使用先前快取的 DNS、IPv6 DNS，或應用程式自己的加密 DNS。
先用一台終端測試閘道
- 在 LuCI「網路」→「介面」→「LAN」→「編輯」中確認旁路由的位址與子網路遮罩。不同韌體的分頁名稱可能略有差異，請以實際畫面為準。
- 確認旁路由本身的預設路由經由
192.168.10.1對外連線，可執行ip route show default檢查。 - 只將測試終端的預設閘道改為
192.168.10.2，暫時不要修改主路由對整個網路發佈的 DHCP 設定。 - 確認終端能連上旁路由與主路由後，再測試外部網站。變更閘道後，舊連線可能仍會沿用原本的路徑。
若接著要透過 DHCP 大量發佈設定，IPv4 選項 3 是預設閘道，選項 6 是 DNS 伺服器。修改後須讓終端更新租約，並確認實際取得的參數。同網段旁路由可能造成直連連線的回程路徑不對稱及 ICMP 重新導向，應根據封包擷取結果，判斷是否需要對受控轉送流量執行來源 NAT。來源 NAT 會改變主路由看到的來源位址，不應將「啟用偽裝」視為所有拓撲都必須執行的步驟。
保留 dnsmasq 的 53 埠
一種方便分層排查的設定方式是：讓 dnsmasq 繼續監聽區域網路的 53 埠，mihomo DNS 則監聽 127.0.0.1:1053，再由 dnsmasq 將上游查詢轉送給 mihomo。以下片段需合併至現有設定，範例上游伺服器必須能從實際網路連線。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29採用常見 LuCI 版面的韌體，可前往「網路」→「DHCP/DNS」→「一般設定」，在 DNS 轉送欄位填入 127.0.0.1#1053。也要確認是否仍會查詢其他上游，避免查詢繞過預定路徑。若 mihomo 的上游又指回 dnsmasq，就會造成 DNS 迴圈。
Fake-IP 回傳的合成位址必須由透明代理路徑正確接管；在一般代理測試階段，先不要急著將全網 DNS 切換至這種模式。若遇到區域網路網域、印表機或特定應用程式的相容性問題，應依實際網域設定過濾規則或選擇合適的解析模式，而不是直接清除所有 DNS 設定。
範例上游是一般 DNS，只用來說明監聽與轉送關係，不代表查詢已加密。瀏覽器的安全 DNS、應用程式內建的 DoH，以及 Android 私人 DNS，也不會只因設定了 dns-hijack 就自動全部遭到攔截。
逐層排除問題：從程序到 IPv6
排查時保留一台尚未變更閘道的管理裝置，並記錄原始設定。依序檢查入口、路由、解析與規則，比反覆更換節點更容易找出問題。以下指令僅用於查看狀態，不能取代防火牆設定。
pgrep -af mihomo
logread -e mihomo
ip addr show
ip route show table all
ip rule show
nft list ruleset
nslookup example.com 192.168.10.2| 狀況 | 優先檢查項目 | 判斷方式 |
|---|---|---|
| 核心啟動後立即結束 | 設定測試、埠號占用、檔案權限 | 啟動記錄是否出現監聽失敗或設定錯誤 |
| 7890 可用，但透明代理無法使用 | 終端閘道、轉送路徑、策略路由 | 網路流量是否真的抵達旁路由 |
| 可連線至外部 IP，但無法瀏覽網域 | 53 與 1053 的監聽及上游轉送 | 查詢是否逾時，是否發生解析迴圈 |
| TCP 正常，但遊戲或 QUIC 異常 | UDP 接管、節點協定與伺服器支援 | 是否只有 TCP 被重新導向 |
| 少數應用程式仍使用原本的出口 | IPv6 預設路由、應用程式獨立代理或 VPN | 終端是否還有其他可用的網路路徑 |
IPv6 路由不會隨 IPv4 閘道一併變更
終端即使取得指向旁路由的 IPv4 閘道，仍可能透過主路由的 RA 取得 IPv6 預設路由。此時 IPv6 連線仍可直接經過主路由。請分別檢查 IPv4 與 IPv6 路由、DNS 及防火牆，並決定要完整接管 IPv6，或在測試網路中暫停發佈 IPv6 路由；只在 mihomo 關閉某個 IPv6 選項，無法移除終端已取得的路由。
測試傳輸速度不能只看延遲
旁路由的 CPU、加密協定、網路埠速率與虛擬機網卡都可能影響傳輸速度。先測試一般區域網路傳輸，再比較同一目標在一般代理與透明代理下的下載速度。測試時記錄 CPU 使用率、流量路徑與實際使用的節點，不能以單次延遲測試代替頻寬測試。排查期間可暫時停用軟體或硬體流量卸載，避免既有的快速轉送路徑干擾規則驗證。
正式部署與回復：一次只擴大一個範圍
- 保存基準設定。備份 OpenWrt 網路、防火牆、DHCP 與 mihomo 設定，並記錄主路由原有的閘道及 DNS 發佈方式。
- 確認一般代理正常。先確認核心、訂閱、代理群組與規則都能正常運作，再部署透明代理接管。
- 測試單一終端。分別測試網頁、DNS、UDP、區域網路裝置存取與 IPv6，不要只查看單一網站。
- 確認重新開機後可正常運作。確認介面就緒後服務能順利啟動，DNS 不依賴尚未啟動的代理路徑，重新載入防火牆後規則也仍然正確。
- 擴大 DHCP 發佈範圍。單一裝置運作穩定後，再逐步將旁路由位址發佈給其他裝置，並保留可直接管理主路由的裝置。
需要回復設定時，先將測試終端或 DHCP 發佈的閘道改回 192.168.10.1，同時恢復可用的 DNS，並讓終端更新租約。之後再停止透明代理服務並清除其管理的規則。若只停止 mihomo，卻保留指向它的 DNS 轉送與透明重新導向，終端仍可能無法連線。
旁路由部署的關鍵在於流量路徑一致：終端將流量交給正確的閘道，DNS 回傳的位址能沿著對應路徑處理，核心的對外連線也不會再次遭到攔截。確認這三點後，再加入規則集、訂閱更新與監控，部署流程會更容易重現，也更容易回復。想了解用戶端與核心的差異，可繼續閱讀名詞速查；跨平台安裝步驟請參閱全平台指南。