部署範圍：核心執行、流量接管與設備閘道
在 OpenWrt 上啟動 mihomo，只代表路由器中有代理核心程序。若要讓手機、電視和電腦的流量經過它，還得處理流量入口、路由與 DNS。設定檔能載入、控制面板能開啟，都不能單獨證明區域網路流量已被接管。
mihomo 沿用 Clash Meta 的設定架構，負責代理協定、規則比對與連線處理；OpenWrt 則負責介面、路由、防火牆和服務管理。LuCI 外掛可將這些操作整合在介面中，但外掛、核心與訂閱設定仍是需要分別更新的三個項目。
- 手動設定代理：在設備或應用程式中填入代理伺服器位址與連接埠，適合先測試設定；不支援代理設定的應用程式不會自動經過核心。
- 透明代理：由路由器透過防火牆與策略路由接管經過的流量，終端通常不必逐一設定 HTTP 代理。
- TUN：核心透過虛擬網路介面處理 IP 流量，仍須搭配系統路由、防火牆轉送及排除回環流量等設定。
主路由與旁路由：先確認實際流量路徑
主路由部署
主路由直接負責連外，區域網路設備的預設閘道通常就是主路由。流量自然會經過這台設備，因此較容易統一接管；但核心重新啟動、規則重新載入或 DNS 設定錯誤，影響範圍也更大。保留直連出口與管理位址的例外，比一次接管所有連線更重要。
同網段旁路由部署
以下位址僅供說明網路拓樸，並非實際測試數據：主路由為 192.168.10.1，旁路由為 192.168.10.2，測試電腦為 192.168.10.100/24。旁路由的上游預設路由指向主路由，測試電腦的預設閘道則指向旁路由。
| 設備 | 範例設定 | 確認事項 |
|---|---|---|
| 主路由 | 192.168.10.1 | 負責上游出口；初期保留原有 DHCP 服務 |
| 旁路由 | 192.168.10.2/24 | 上游閘道為 192.168.10.1，並允許所需的轉送流量 |
| 測試電腦 | 192.168.10.100/24 | 預設閘道為 192.168.10.2，DNS 指向已設定的解析入口 |
旁路由與終端位於同一網段時，直連連線的回程流量可能由主路由直接送回終端，造成非對稱路徑。是否需要來源位址轉換、如何處理 ICMP 重新導向，應依連線追蹤與實際路由判斷；不能把「啟用 NAT」當成所有拓樸都適用的標準答案。採用雙網卡、獨立下游網段的旁路由則更接近一般路由器，流量路徑通常較清楚。
- 只將終端的 DNS 改指向旁路由，不代表網路連線也會經過旁路由。
- 透過 DHCP 下發閘道與 DNS 時，對應的 IPv4 選項通常是 3 和 6；修改後需讓用戶端重新取得租約。
- 同一個廣播網域內，不要未經規劃就啟用第二台 DHCP 伺服器，否則不同設備可能取得不同的閘道。
- IPv6 預設路由通常由路由通告提供；只修改 IPv4 閘道，不會自動改變 IPv6 流量路徑。
架構與系統檢查：選擇可執行的 mihomo 檔案
下載前先確認 OpenWrt 版本、CPU 架構與可用儲存空間。OpenWrt 23.05、24.10 的常見官方映像使用 firewall4 與 nftables；第三方韌體可能修改相關元件，因此應檢查實際環境，不要只憑韌體名稱選擇安裝指令碼。
ubus call system board
uname -m
opkg print-architecture
df -h /overlay /tmp
free -m
command -v fw4
command -v nft
test -c /dev/net/tun && echo "TUN device available"上方的 opkg 指令適用於使用 opkg 的韌體；若系統採用其他套件管理工具，請依該韌體的說明查詢。uname -m 顯示的是執行環境架構，不能取代 CPU 指令集與發行檔說明的確認。
- x86_64：屬於 amd64 架構；不同最佳化版本可能要求不同的 CPU 指令集，較舊的軟路由應確認發行檔標示。
- aarch64：通常對應 arm64；若硬體支援 64 位元，但韌體執行於 32 位元環境，請以實際系統為準。
- ARM、MIPS：還要確認 ARM 世代、浮點運算需求，以及 MIPS 的位元組順序，不能只看產品宣傳的晶片系列。
- 儲存空間與記憶體：核心、規則集和地理資料庫都會佔用空間；
/tmp通常位於記憶體中，重新啟動後內容不會保留。
出現 Exec format error 時，先檢查架構；出現 Illegal instruction 時，確認指令集需求。檔案存在卻無法執行，也可能是載入器或權限問題，不應直接判定為訂閱失效。
部署方式：LuCI 外掛、獨立程序與容器
方式一：透過 LuCI 外掛統一管理
適合需要訂閱更新、開機啟動及透明代理規則整合的環境。請選擇明確支援目前 OpenWrt 防火牆架構與 mihomo 的外掛，並閱讀對應版本的文件。不同外掛的選單、覆寫機制和核心更新來源各不相同，不能直接套用其他外掛的設定步驟。
外掛執行時通常會產生最終設定檔。若手動編輯產生的檔案，下次更新訂閱或重新啟動服務時，修改可能會被覆蓋。請使用外掛提供的持久覆寫功能，並避免再啟動第二個獨立核心，以免搶用相同連接埠。
方式二：獨立二進位檔與 procd 服務
適合希望明確控制執行參數與防火牆規則的使用者。以下範例將核心放在 /usr/bin/mihomo，資料目錄設為 /etc/mihomo；這是本文使用的範例路徑，不代表所有外掛的預設路徑。先放入確認過的設定檔，再以前景模式執行並查看錯誤訊息。
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml-t 用於測試設定；即使測試通過，仍須確認 DNS、出口與轉送狀況。以前景模式確認執行穩定後，再建立位於 /etc/init.d/ 的 procd 服務，設定啟動指令、標準輸出、異常重新啟動與停止時的清理程序。不要反覆執行背景指令來取代服務管理，否則容易留下多個程序與舊規則。
方式三：在容器中執行
容器適合已有容器管理環境的軟路由，但會額外引入網路命名空間、資料卷與權限隔離。TUN 需要容器能存取對應裝置，並取得必要的網路管理權限；透明代理也必須釐清規則是在主機端還是容器內安裝。只映射 7890 連接埠，通常只能提供手動設定的代理，無法自動接管整個區域網路。
透明代理與 TUN：選擇一套流量接管規則
透明代理是要達成的流量接管方式，TUN 則是其中一種實作途徑。另一種常見作法是 REDIRECT 或 TPROXY：REDIRECT 常用於重新導向 TCP；TPROXY 可處理 TCP、UDP，但需要策略路由、封包標記及相應的核心模組。採用哪種方式，應依外掛支援、韌體元件與網路拓樸決定。
| 流量入口方案 | 系統配合項目 | 檢查重點 |
|---|---|---|
| 手動設定 HTTP / SOCKS 代理 | 在應用程式中設定代理位址 | 確認是否有應用程式繞過代理；另須確認是否支援 UDP |
| REDIRECT / TPROXY | 防火牆規則，並視需要設定策略路由 | TCP、UDP 接管範圍、mark 衝突與回環排除 |
| TUN | TUN 裝置、路由與轉送規則 | 確認介面是否建立、流量是否進入介面，以及 DNS 是否被接管 |
使用 TUN 前，可在 LuCI 的「系統」→「軟體套件」中確認是否已安裝與目前核心相符的 kmod-tun，並檢查 /dev/net/tun。模組不能任意安裝到不同韌體核心版本上。裝置檔案存在只代表具備基本條件，不表示後續路由設定正確。
- 確認路由由哪一方負責：若外掛會產生流量接管規則，就不要再照搬另一份會啟用自動路由的獨立設定。
- 排除核心本身的代理出口連線、路由器管理位址、上游閘道及必要的區域網路網段，避免連線反覆進入核心。
- 在 LuCI「網路」→「防火牆」中確認區域與轉送關係，不要用全域放行來掩蓋規則錯誤。
- 排查時可暫時關閉軟體或硬體流量卸載，再重新測試；卸載功能可能改變後續封包的處理路徑。
DNS 接管：監聽連接埠、上游解析與 Fake-IP
OpenWrt 通常由 dnsmasq 提供區域網路 DNS。較容易理解的查詢流程是：終端向路由器的 53 連接埠發出請求，再由 dnsmasq 將需要交給核心的請求轉送至本機 127.0.0.1:1053。這樣可保留 dnsmasq 對本地主機名稱的處理，但須依實際設定避免核心的查詢又被轉回自身。
以下僅展示 mihomo 的 DNS 設定片段，並非可直接執行的完整路由器設定。範例使用一般上游解析服務，以說明連接埠的關係；正式部署時，還須依網路可達性、隱私需求及代理伺服器網域名稱的解析方式選擇上游。
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- 指定唯一的 53 連接埠入口。若 dnsmasq 已監聽區域網路的 53 連接埠，mihomo 就不應再繫結相同的位址與連接埠。
- 設定轉送。LuCI「網路」→「DHCP/DNS」中的 DNS 轉送可使用
127.0.0.1#1053這種 dnsmasq 位址格式；也要確認是否仍使用上游下發的解析伺服器。 - 避免形成循環。mihomo 的上游解析伺服器不能再指回這個 dnsmasq 入口。代理伺服器網域名稱也必須有可用的初始解析路徑。
- 涵蓋實際的 DNS 查詢。傳統 DNS 使用 UDP 與 TCP 的 53 連接埠；應用程式內建的 DoH 使用 HTTPS，不會只因重新導向 53 連接埠就自動採用相同的解析流程。
Fake-IP 回傳的是對應位址，核心再透過位址對應網域名稱。若終端取得 198.18.0.0/16 範圍內的位址，卻將連線送往未接管該位址範圍的閘道，就會出現「DNS 查得到，但網頁打不開」的狀況。因此，Fake-IP、DNS 下發與流量入口應一起測試。
印表機、螢幕投放及依賴區域網路名稱探索的應用程式都需要額外測試；必要時可使用精確的 Fake-IP 過濾規則與本地域名解析規則。也應一併檢查 IPv6 的 DNS 下發、AAAA 回應與出口路徑；不能只因 IPv4 測試成功，就認定所有連線都已接管。更多欄位說明請參閱完整手冊的 DNS 章節與Fake-IP 術語說明。
驗證順序：從設定檔測試到區域網路實際連線
依固定順序逐步檢查，才能將問題限縮在單一層面，避免同時修改規則、DNS 與防火牆。以下連接埠皆為本文範例：混合代理為 7890，核心 DNS 為 1053；若需啟用控制介面，可限制在 127.0.0.1:9090。
- 核心層：執行設定檔測試並檢查執行記錄。獨立 procd 服務可搭配
logread查看啟動錯誤；使用外掛時，優先查看外掛的記錄頁面。 - 監聽層：若已安裝
ss，請執行ss -lntup；否則使用韌體提供的同等工具，確認 7890、1053 等連接埠的監聽位址與協定。 - 手動代理層：在允許區域網路存取，且防火牆已限制來源的前提下，讓測試電腦透過旁路由的 7890 連接埠要求載入網頁，先確認訂閱與出口可正常使用。
- DNS 層：從測試電腦向預期的 DNS 入口發出查詢，觀察核心記錄與回應結果，分辨解析逾時、映射正常或上游循環等狀況。
- 路由層：關閉測試電腦的手動代理，只保留測試閘道與 DNS，確認連線是否仍會進入核心。並在路由器上查看
ip route show、ip rule show及相關路由表。 - 協定層：分別測試一般網頁、影片、UDP 應用程式與 IPv6 連線；TCP 成功不代表 UDP 或 IPv6 也採用相同路徑。
若要在終端執行手動代理測試，請先確認終端已安裝 curl，且旁路由確實依照上述範例開放區域網路代理入口。範例網址僅作為測試目標，不代表它一定會符合預期的代理規則。
curl --proxy http://192.168.10.2:7890 --connect-timeout 10 -I https://example.com/
nslookup example.com 192.168.10.2不要只看公網 IP 是否改變：規則模式下，有些目標原本就會直連。應搭配連線記錄中的目標、命中規則、策略群組與最終出口判斷。軟路由沒有通用的「標準吞吐量」；加密協定、單核心效能、MTU、線路品質與記錄量都會影響結果，應在同一台設備、同一個目標間比較直連與代理。
長期維運：更新、權限與故障復原
- 更新設定：更新訂閱後，先檢查語法與資源載入，再替換目前使用的設定。保留上一份可用設定，持久修改則放在外掛覆寫功能或自行維護的檔案中。
- 更新核心：先確認新版核心支援目前使用的欄位、規則與啟動參數，更新後重新執行設定檔測試；更新訂閱並不會一併更新程式。
- 管理介面：控制介面應優先繫結回環位址。若確實需要從區域網路存取，請設定存取憑證並限制來源；不應在 WAN 端開放代理或控制連接埠。
- 儲存管理：避免長時間開啟大量偵錯記錄並寫入快閃記憶體；更新規則資源時也要考量下載失敗與剩餘空間，不要將唯一的設定檔放在暫存目錄。
- 停止與清理：停止服務時，應撤除由該服務建立的接管規則、路由與 DNS 轉送，避免程序停止後仍將流量送往已失效的入口。
復原時，先將測試終端的閘道與 DNS 還原為原本設定，再撤除旁路由的流量接管；若部署在主路由，則應使用事先準備好的停止服務與還原規則流程。保留本機有線管理方式，比故障後依賴已中斷的遠端連線可靠。
若只需要讓一台電腦使用訂閱，可以先透過桌面用戶端完成設定測試，再考慮由路由器接管流量。路由器部署的重點不在複製核心檔案，而在於確保流量入口、網域名稱解析、代理出口與回程路徑彼此一致。