mihomo 旁路由設定教學：OpenWrt 透明代理與部署重點

一、先確認旁路由負責哪些流量

mihomo 是代理核心，不會自動完成 OpenWrt 的所有網路設定。訂閱提供節點與規則，核心負責選擇出口；裝置流量能否進入核心，仍取決於預設閘道、路由表、防火牆與 DNS 流程。只把 YAML 放到路由器上執行，不代表區域網路裝置已接上透明代理。

本文以明確的 IPv4 網路為例：主路由器為 192.168.10.1/24，負責寬頻連線與 DHCP；旁路由為 192.168.10.2/24，預設閘道指向主路由器；測試電腦為 192.168.10.100/24。這些位址僅供說明，實際部署前請替換成目前網路使用的位址，並確認沒有與 DHCP 位址池衝突。

二、部署 OpenWrt 前的檢查項目

確認系統架構與防火牆後端

透過 SSH 記下系統版本、CPU 架構與可用儲存空間。OpenWrt 22.03 起預設使用 firewall4 與 nftables，但升級、客製韌體或第三方外掛可能改變實際環境。請勿將舊版 iptables 規則直接貼到 nftables 環境，也不要同時執行兩套會接管相同流量的透明代理外掛。

ubus call system board
uname -m
df -h /overlay
free -m
command -v fw4
command -v nft
ip route show
ip -6 route show

uname -m 的輸出只能協助辨識架構，仍須依裝置的 CPU 特性選擇 mihomo 版本。有些舊裝置不支援較新的指令集。若啟動後立即結束或出現非法指令錯誤，應先確認執行檔版本是否符合架構，而不是一再修改訂閱內容。

分開管理核心、設定檔與服務

建議分開管理執行檔、工作目錄與服務指令碼。例如將核心放在 /usr/bin/mihomo，設定檔放在 /etc/mihomo/config.yaml，並交由 OpenWrt 的 procd 服務管理執行狀態。以下路徑是部署慣例，不代表系統已預先安裝相關檔案。

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

第二個指令用來檢查設定檔能否載入，並非完整的網路連線測試。使用規則集、GeoIP 或 GeoSite 資料的設定，還需要相應的資源；請確認外部資源能否下載、目錄是否可寫入，以及首次啟動是否依賴尚未建立的代理連線。服務指令碼應設定啟動順序、異常重啟與記錄檔輸出，避免 SSH 工作階段結束後，程序也跟著退出。

三、先用手動代理驗證訂閱與規則

建議依序部署：「核心啟動 → 手動代理可用 → DNS 可用 → 透明代理接管」。如此可區分節點無法使用與路由設定錯誤。以下片段僅供基本連線測試，沒有代理節點，最後一條規則會讓所有流量直連；它不能取代訂閱，也無法用來判斷代理出口是否可用。

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

rules:
  - MATCH,DIRECT

將片段合併到實際設定時，每個頂層欄位只能保留一份。啟用區域網路監聽後，請在 OpenWrt 防火牆中只允許可信任的 LAN 存取 7890，不要對 WAN 開放，也不要設定公網連接埠轉送。監聽位址必須是旁路由實際持有的位址。

1. 先在測試電腦將 HTTP 代理設為 192.168.10.2:7890，確認要求能送達核心。
2. 接著載入有效的 Clash 格式訂閱，確認代理群組中有可用節點，並選取目標節點。
3. 查看連線記錄中的命中規則與出口。規則模式的結果取決於規則順序，與代理群組名稱是否包含「自動」無關。
4. 關閉電腦上的手動代理，再測試透明代理，避免兩種連線方式同時啟用而造成誤判。

在已安裝 curl 的測試電腦上，可執行 curl -I --proxy http://192.168.10.2:7890 https://example.com。此指令用來驗證 HTTP 代理的要求流程；若要確認流量是否經過節點，還需查看命中規則、出口記錄，以及可信任的出口查詢結果。

四、TProxy、redir 與 TUN 的適用範圍

redir 主要處理 TCP

設定 redir-port: 7892 只會建立監聽連接埠，還需要透過防火牆將符合條件的 TCP 流量重新導向該連接埠。UDP 無法透過此入口以相同方式進行透明接管。若網頁可正常開啟，但遊戲、語音或 QUIC 異常，請先檢查 UDP 的實際流向，而不是直接調高逾時時間。

TProxy 需要搭配標記與策略路由

tproxy-port: 7893 可作為 TCP 與 UDP 的透明代理入口，但必須備妥對應的核心模組、防火牆規則與路由表。系統會透過 fwmark 與 ip rule，將標記過的封包送往本機接收路徑。標記值與路由表編號必須避開現有的 VPN、多 WAN 與其他外掛，不能假設某個固定數字在所有裝置上都未被使用。

TUN 不只是開啟一個選項

mihomo 的 TUN 可搭配 auto-route 等欄位建立路由，但仍須確認 OpenWrt 的轉送策略、介面辨識與 IPv6 路由。較新版本的 mihomo 也在 Linux 上提供 auto-redirect 相關功能，實際行為請以已安裝核心版本的文件為準。不要同時啟用不同教學中的自動重新導向功能與手動設定的 TProxy 規則。

五、閘道、回程與防火牆轉送

使用單網卡旁路由時，測試電腦的預設閘道應指向 192.168.10.2，旁路由本身的預設路由則仍應指向 192.168.10.1。請勿讓主路由器與旁路由的預設路由互相指向對方。若 DHCP 仍由主路由器提供，可先手動修改電腦；確認可用後，再透過 DHCP 選項 3 派發閘道、選項 6 派發 DNS。

• IP 轉送：使用 sysctl net.ipv4.ip_forward 檢查 IPv4 轉送狀態。正常轉送時，數值應為 1。
• 防火牆區域：在 LuCI 的「網路」→「防火牆」→「一般設定」中，檢查介面所屬區域與轉送規則。介面文字會因版本而異，請以實際的區域與介面綁定為準。
• 同網段回程：主路由器可能會直接將回應封包送回電腦，造成非對稱路徑。因此，旁路由上的連線追蹤、過濾規則與統計結果可能不如預期。
• ICMP Redirect：在同一介面收發封包時，系統可能會通知終端改用更直接的閘道。請檢查旁路由是否會傳送重新導向訊息，以及終端是否接受這類訊息。

部分單網卡方案會使用受控的來源位址轉換，讓直連流量的回程重新經過旁路由。代價是上游看到的來源位址可能都變成旁路由位址，影響裝置用量統計與策略設定。請勿將「啟用所有區域的位址偽裝」視為通用解法；雙網卡、獨立下游網段與不同防火牆策略都需要分別規劃。

六、DNS：先釐清 53 與 1053 連接埠的用途

OpenWrt 通常由 dnsmasq 監聽 53 連接埠，提供 DHCP 與區域網路網域名稱解析。若讓 mihomo 同時監聽相同位址的 53 連接埠，就會產生衝突。較容易排查的架構是：終端向旁路由的 53 連接埠查詢，由 dnsmasq 轉送至 mihomo 本機的 1053 連接埠，再由 mihomo 查詢上游。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

這只是 DNS 設定範例。上游位址必須能從目前網路連線，且連線路徑須符合實際代理策略。在 LuCI「網路」→「DHCP/DNS」→「一般設定」的 DNS 轉送欄位中，可依目前版本支援的語法設定 127.0.0.1#1053；也要確認 resolv 檔案的來源，避免 dnsmasq 又將要求送回自身。

fake-ip 回傳的是用於連線映射的位址，並非目標網站的真實位址。只有當終端接著連線至該位址的流量也能由 mihomo 接收時，映射才有作用。若 DNS 已經經過旁路由，但閘道仍指向主路由器，就可能出現「網域解析成功，但所有網頁都逾時」的情況。

• 區域網路主機名稱建議先交由 dnsmasq 處理；若確實有相容性問題，再依網域設定 fake-ip 排除或網域解析策略。
• 重新導向 53 連接埠只能涵蓋符合條件的傳統 DNS。瀏覽器內建的 DoH、應用程式自帶的加密 DNS 與其他通道都需要另外檢查。
• 只設定 dns.ipv6: false 不會關閉終端的 IPv6，也不會接管 IPv6 流量。終端仍可能透過主路由器公告的 IPv6 預設路由直接連線。

建議先完成 IPv4 測試，再另外規劃 IPv6 的 RA、DNS 公告、預設路由與代理路徑。若要接管雙協定流量，應同時測試 AAAA 查詢與實際 IPv6 連線，不能只查看 IPv4 出口。

七、分層驗收與故障排查

每次只調整一個環節，並記錄調整前後的結果。依照以下順序檢查，可分辨「流量未到旁路由」、「已進入核心但規則不正確」與「節點本身故障」。

1. 基本網路：確認測試電腦可連線至主路由器與旁路由的管理位址；旁路由的預設路由正確，系統時間也準確。
2. 手動代理：透過 7890 連接埠存取測試網站，檢查連線記錄、代理群組選擇與出口錯誤。
3. DNS：執行 nslookup example.com 192.168.10.2，確認查詢進入預定的解析流程；若已啟用 fake-ip，也要確認映射結果。
4. 透明接管：關閉應用程式代理後建立新連線，確認 mihomo 仍可看到連線，且命中預期規則。
5. UDP 與 IPv6：分別測試需要 UDP 的應用程式與 IPv6 目標。TCP 測試成功，無法證明另外兩種流量路徑也正常。
6. 重新啟動後的狀態：重新啟動旁路由，檢查服務是否啟動、DNS 是否可用、防火牆規則是否恢復，以及節點網域是否能解析。

需要封包擷取時，可在已安裝 tcpdump 的裝置上執行 tcpdump -ni br-lan host 192.168.10.100，觀察測試電腦的流量；其中 br-lan 必須替換為實際的 LAN 介面。記錄檔若含訂閱網址、節點憑證或瀏覽網域，分享前請先移除敏感資訊。

八、設定維護與復原

訂閱更新、核心升級與防火牆修改應分開進行。請將裝置專用的 DNS、監聽位址、入口連接埠與路由策略保留在本機管理層，避免遠端訂閱更新覆蓋旁路由設定。若使用覆寫或設定合併功能，請檢查最後產生的 YAML，而不只是原始訂閱。

• 升級前請備份目前的核心版本、有效設定、服務指令碼與防火牆規則；先測試設定，再安排重新啟動服務。
• 修改主路由器 DHCP 的閘道與 DNS 設定時，請記下原始值。復原時應一併還原兩項，避免閘道已恢復，卻仍依賴已停止的 DNS。
• 控制介面只開放給必要的管理位址，並設定存取憑證；訂閱檔案應視為敏感設定管理，切勿放進公開儲存庫。
• 應預先規劃故障時的旁路方式。若終端仍指向已關機的旁路由，主路由器不會自動接手其閘道位址。

旁路由部署的關鍵，是讓流量入口、DNS 解析與對外連線三條路徑保持一致。先在單一裝置完成手動代理測試，再選擇一種透明接管方案，最後擴大 DHCP 派發範圍。若想了解規則模式、匯入訂閱與用戶端操作，請參閱Clash 使用教學；欄位說明請參閱完整文件。