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

先確認旁路由的工作範圍

旁路由是一種部署角色，不是特殊的代理協定。常見做法是在既有主路由器旁接上一台 OpenWrt 裝置，讓指定終端將它設為預設閘道。主路由器繼續負責寬頻連線、無線網路與對外出口，OpenWrt 則依規則處理經過它的流量。

mihomo 是從 Clash Meta 專案發展而來的代理核心，負責讀取設定、比對規則並建立連線，本身不是完整的路由管理介面。將核心複製到裝置上，只完成部署的一部分；透明代理還需要路由、DNS 與防火牆規則配合。

選擇一種流量接管方式

• 手動設定代理：在終端輸入 HTTP 或 SOCKS 代理位址。適合確認訂閱與節點是否可用，但只有遵循代理設定的應用程式會使用代理。
• 透明代理：由 OpenWrt 攔截或路由終端流量。可使用 TProxy，或搭配 mihomo 的 TUN 虛擬網卡實作；兩種方式對核心模組與路由設定的需求不同。
• 整合管理外掛：由外掛管理核心、設定與防火牆。適合需要 LuCI 圖形介面的使用者，但應先確認外掛支援目前的 OpenWrt 版本。

選定一種方案管理透明代理。不要讓兩個外掛同時修改 DNS 攔截、策略路由與防火牆規則；外掛自動產生設定後，也不要直接修改暫存中的執行檔。

規劃 IP 位址、預設閘道與 DHCP

以下以單網路埠、同一子網路為例：主路由器為 192.168.10.1，OpenWrt 為 192.168.10.2，測試用 Mac 為 192.168.10.50，子網路遮罩皆為 255.255.255.0。這些是部署範例，實際操作前請換成家中使用的網段，並確認位址尚未被占用。

先設定 OpenWrt 本身的上游連線

1. 使用網路線連接主路由器的 LAN 埠與 OpenWrt 的 LAN 介面。請以目前的網路設定確認裝置埠位用途，不要只看機殼上的標示。
2. 在 LuCI 開啟「網路」→「介面」→「LAN」→「編輯」，設定固定 IPv4 位址、子網路遮罩，以及指向主路由器的 IPv4 閘道。
3. 為 OpenWrt 設定可用的上游 DNS，確保在代理啟動前，仍能下載核心、解析代理伺服器網域名稱及更新訂閱。
4. 如果主路由器繼續提供 DHCP，請在 OpenWrt 對應 LAN 的「DHCP 伺服器」→「一般設定」中勾選「忽略此介面」。這只會停用該介面的 DHCP 位址分配，不代表 DNS 服務也會停用。

DHCP 服務會自動分配 IP 位址、閘道與 DNS。同一個廣播網域中，不要任意啟用兩套互相衝突的位址分配服務，否則終端可能這次取得主路由器的閘道、下次卻取得旁路由的閘道，導致網路時好時壞。

接著修改測試用 Mac

開啟 macOS「系統設定」→「網路」→目前使用的網路服務→「詳細資料」→「TCP/IP」，先記下原有設定，再依表格填入測試位址、子網路遮罩與「路由器」位址；在「DNS」頁面填入 192.168.10.2。先確認測試位址不在 DHCP 配發範圍內，或已設為位址保留，以免發生衝突。

若要套用到整個區域網路，可由主路由器的 DHCP 發送選項 3（預設閘道）與選項 6（DNS 伺服器），兩者都指向旁路由。有些家用路由器無法分別設定這兩個選項，這時逐台設定較容易復原。修改 DHCP 後，終端需要重新取得租約；已取得的舊租約不會立即全部更新。

確認 CPU 架構與資源餘裕

路由器安裝的是 Linux 核心程式，不是 macOS 應用程式安裝包。先透過 SSH 查看系統資訊，再從 mihomo 的發布檔案中選擇相符的架構。不能只根據「64 位元處理器」判斷：處理器支援 64 位元，不代表目前韌體的使用者空間也是 64 位元。

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

精簡韌體可能未包含 getconf，可參考系統板卡資訊與韌體目標判斷。常見的 x86_64 對應 AMD64 架構，aarch64 對應 ARM64；MIPS 裝置還要確認位元組序、指令集與浮點數呼叫慣例。執行時若出現 Exec format error，應先檢查架構，不要反覆增加執行權限。

區分建議容量與實際用量

• 記憶體：256 MB 的裝置需要審慎評估；512 MB 以上通常較有餘裕，可供規則集、DNS 快取與多個並行連線使用。這是規劃建議，不是核心固定的最低需求。
• 儲存空間：檢查 /overlay 的可用空間。核心、規則資料庫，以及更新時的新舊檔案都會占用空間，不能只根據壓縮檔大小估算。
• 處理器：代理加密、規則比對與大量連線都會耗用 CPU。寬頻標示 1000 Mbps，不代表路由器啟用代理後也能達到相同速度。

安裝後執行 mihomo -v 記錄實際版本，排查問題時也一併記錄韌體版本、接管方式與規則規模。分別在閒置、載入訂閱後，以及持續傳輸 10 分鐘後，查看 top 與 free -m。留意程序常駐記憶體與系統可用記憶體；Linux 用於快取的記憶體不能直接視為記憶體洩漏。

分別設定代理核心、透明接管與 DNS

OpenWrt 22.03 及後續常見版本預設使用 firewall4，並透過 nftables 產生防火牆規則。舊教學中的 iptables 指令不能直接當成通用設定貼上使用。使用外掛時，請確認支援的防火牆後端；手動部署時，則要確認目前韌體是否提供 TProxy 或 TUN 所需模組。

先檢查設定，再接管終端流量

將執行設定與資源目錄固定保存。以下指令假設核心已安裝至 /usr/bin/mihomo，設定檔位於 /etc/mihomo/config.yaml；只有實際使用這些路徑時才執行。

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

設定檢查成功只代表設定檔可載入，不代表訂閱能更新、節點能連線，或透明代理已生效。請繼續確認所選策略群組、最終兜底規則，以及節點伺服器網域名稱是否可解析。訂閱 URL 通常含有存取憑證，分享記錄或截圖前請遮蔽完整網址。

確認各連接埠的用途

若設定了 mixed-port: 7890，7890 是供應用程式手動連線的 HTTP/SOCKS 混合代理入口；若設定了 tproxy-port: 7893，7893 則是透明轉發規則使用的入口。這些都是可修改的範例值，不是啟動核心後一定會存在的連接埠。只開放 7890 不會自動接管區域網路流量。

TUN 是虛擬網路介面，需要裝置支援、相應權限與路由設定。即使啟用自動路由，仍須檢查 LAN 轉送、防火牆區域與 DNS 入口，不能以為它會自動完成所有旁路由設定。TProxy 通常則依賴流量標記與策略路由，將攔截到的資料交由本機代理處理。

讓 DNS 維持單向查詢路徑

常見的查詢路徑是：終端向旁路由的 53 連接埠送出請求，由 dnsmasq 接收後，再轉送至 mihomo 的本機 DNS 監聽位址，例如 127.0.0.1:1053。1053 必須與實際設定一致。不要讓 dnsmasq 將查詢轉給 mihomo 後，mihomo 又把同一筆查詢送回 dnsmasq，形成循環。

• 使用 fake-ip：核心會回傳供位址映射使用的 IP，之後再依映射還原網域名稱。常見的位址池為 198.18.0.0/16，應避開既有網路與 VPN 使用的網段。
• 解析節點網域名稱：為代理伺服器本身保留可用的初始 DNS 解析路徑，避免發生必須先連上代理才能解析代理伺服器的循環依賴。
• 檢查加密 DNS：瀏覽器自訂的 DoH 可能會繞過區域網路 DNS，使網域規則與 fake-ip 映射結果不如預期。測試時請先統一 DNS 查詢路徑。

旁路由回傳 fake-ip 後，終端的連線必須繼續經過同一套核心。若 DNS 指向旁路由、閘道卻仍使用主路由器，主路由器通常無法處理這些映射位址，常見狀況是網域名稱解析成功，網頁卻無法開啟。

處理單臂路由、IPv6 與安全性

單臂旁路由只有一個主要 LAN 介面，接收封包與將封包送往主路由器可能都經過同一介面。直連流量的去程經過旁路由，回程卻可能由主路由器直接送給終端，形成非對稱路徑。是否需要在旁路由進行來源位址轉換，須依連線追蹤、防火牆與上游路由情況判斷。

有些方案會對轉送流量執行 SNAT 或 masquerade，讓主路由器看到的來源位址變成旁路由位址，使回程也經過旁路由。這能簡化部分單臂拓樸，但上游將無法區分各終端的來源。不要把「在 LAN 區域啟用位址偽裝」視為所有裝置都必須執行的步驟。

設定好 IPv4 後，也要另外檢查 IPv6

主路由器可能仍透過 RA（路由器公告）向終端發布 IPv6 預設路由。只修改 IPv4 閘道無法控制 IPv6 流量。請確認部署方案是否也接管 IPv6，並提供對應的 DNS 與轉送規則；測試時可暫時停用測試終端的 IPv6 作為比較，確認後再決定正式的雙堆疊策略。

將管理連接埠限制在可信任的範圍內

• 不要將代理連接埠、DNS 服務或控制介面轉送到公網。
• 若確實需要提供 LAN 代理，請檢查 allow-lan、監聽位址、用戶端驗證，以及防火牆的來源限制。
• 控制 API 優先只監聽回送位址；若需要遠端面板，請設定高強度密鑰，並限制可存取的管理裝置。
• 使用 OpenWrt 的 procd 服務機制或外掛內建的服務管理功能，讓程序持續執行，避免只在 SSH 工作階段中啟動。

依照網路路徑排查斷線與分流異常

排查時一次只修改一個環節。先確認位址與路由，再檢查 DNS，最後才判斷規則與節點。不要同時更換訂閱、修改閘道又重建防火牆，否則很難找出是哪個步驟造成影響。

在測試用 Mac 上檢查網路入口

route -n get default
scutil --dns
ping -c 3 192.168.10.2
dig @192.168.10.2 example.com
curl -I --connect-timeout 10 https://example.com

預設 IPv4 閘道應為範例中的 192.168.10.2；DNS 查詢應收到回應，而非持續逾時。系統 DNS 輸出可能包含 VPN 專用的解析網域，請依實際使用的網路服務判斷。單一目標沒有回應 ping，並不能證明網際網路已中斷；仍須檢查 DNS 與 HTTPS 結果。

在 OpenWrt 上檢查轉送與記錄

ip route
ip rule
ip route show table all
logread | tail -n 80
nft list ruleset

以下指令僅供檢視，不會清除現有規則。請確認是否有預期的預設路由、流量標記相關策略，以及從 LAN 到目標處理鏈的轉送入口。規則輸出可能包含區域網路位址與服務資訊，分享時只保留排查所需的部分。

若小型請求正常、大檔案傳輸卻卡住，接著檢查 MTU、路徑 MTU 探索與上游 PPPoE 封裝；不要一開始就強制將所有介面改成同一數值。測試傳輸速度時，先測量直連基準，再以相同終端和連線方式測試代理，避免將無線訊號變化誤判為核心效能問題。

保留復原方式，再擴大接管範圍

1. 保存初始狀態。備份 OpenWrt 設定，記下主路由器位址、DHCP 配發範圍，以及測試終端原本的自動取得設定。
2. 確認基本功能。確認直連網站、需要代理的連線，以及區域網路印表機與 NAS 的存取都符合規則預期。
3. 確認重新啟動後的狀態。分別重新啟動核心與旁路由，再讓 Mac 中斷網路後重新連線，確認仍使用正確的閘道與 DNS。
4. 演練旁路由離線情況。讓測試終端恢復使用主路由器閘道與原有 DNS，確認基本網路可以恢復。若使用 fake-ip，還要清除 DNS 快取或重新啟動相關應用程式。
5. 逐步擴大部署。先加入少數裝置，再調整 DHCP 設定。保留一台可直接連接主路由器管理介面的裝置。

同一網段的旁路由通常沒有內建的故障接管機制。終端仍將離線的旁路由設為預設閘道時，即使主路由器仍在線，也不會自動接手。請一併記錄位址規劃、DNS 路徑、服務自動啟動設定與復原步驟，才能在更新核心或更換訂閱後快速找出問題。

若只需要讓一台 Mac 使用代理，先採用桌面用戶端會更容易確認訂閱與規則；若確實需要讓電視、遊戲裝置或多台終端共用策略，再將規則移至 OpenWrt。兩種方式適用於不同範圍的流量接管需求，不必一開始就修改整個家庭網路。