OpenWrt 路由器與旁路由部署 mihomo：設定方式總覽

選擇部署方式：先確認閘道路徑，再決定流量接管方式

在 OpenWrt 上執行 mihomo，得先釐清兩件事：核心要在哪台裝置上執行，以及區域網路連線如何進入核心。分開判斷，才能確認問題出在設定檔、DNS，還是路由與防火牆。

mihomo 是 Clash Meta 專案沿用的核心名稱，負責解析設定、比對規則並選擇出站路徑。LuCI 管理外掛則屬於管理層，通常也會產生設定、安裝防火牆規則及管理程序。只把核心複製到路由器，不會自動接管家中所有裝置的流量。

硬體架構：確認指令集、記憶體與儲存空間

先在 OpenWrt 的 SSH 終端查看系統資訊，再選擇相符的 Linux 核心檔案。不要只憑路由器外殼型號或處理器宣傳名稱猜測架構；同系列裝置也可能採用不同晶片。

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

• x86_64 通常對應 amd64，但仍須確認發布檔案要求的 CPU 指令集等級；較舊的處理器不一定支援較新的最佳化版本。
• aarch64 通常對應 arm64；32 位元 ARM 還要確認 ARM 版本與浮點運算支援，不能直接使用 arm64 檔案。
• MIPS 裝置要確認大小端序與具體建置條件。OpenWrt 套件的架構名稱不一定與上游二進位檔名稱完全相同。
• /tmp 通常位於記憶體檔案系統，重新開機後內容會清除。下載、解壓縮與記錄檔都會占用可用記憶體，不能把剩餘快閃儲存空間當成可用記憶體。

依實際負載評估容量

訂閱節點數量、規則集大小、連線數、DNS 快取與記錄檔層級都會影響記憶體用量，無法用單一門檻保證一定能執行。先載入實際設定觀察，再考慮設為開機啟動；大型規則集可能還需要額外的下載空間與持久儲存空間。

如果程序啟動後很快就消失，請查看 logread 是否有記憶體不足或程序遭終止的記錄。出現 Exec format error 時，優先檢查架構及壓縮檔是否已解壓縮；出現 Illegal instruction 時，則應優先確認 CPU 指令集是否相容。

核心與設定：先驗證檔案，再交由服務管理

以下路徑僅供手動部署參考：將核心放在 /usr/bin/mihomo，工作目錄設為 /etc/mihomo，主要設定檔為 /etc/mihomo/config.yaml。若已安裝 LuCI 管理外掛，請使用外掛指定的核心目錄與設定入口，不要再啟動第二個執行個體。

手動部署檢查順序

1. 先備份現有網路、防火牆與 DNS 設定，並確認可透過有線網路重新登入路由器。
2. 將符合架構且已解壓縮的核心上傳至 /tmp/mihomo；設定檔請另外準備，以免覆蓋原本可用的設定。
3. 確認目標目錄有足夠空間，再複製核心並設定執行權限。
4. 先查詢版本並測試設定；測試通過後，再以前景模式啟動並查看記錄。

mkdir -p /etc/mihomo
cp /tmp/mihomo /usr/bin/mihomo
chmod 755 /usr/bin/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

執行前請確認 config.yaml 已存在。-v 用來確認實際版本，-t 用來測試設定；測試成功不代表上游節點連線正常，也不代表區域網路流量已進入核心。部分設定還需要規則集、地理資料或外部檔案；首次測試失敗時，也要一併檢查工作目錄與下載記錄。

最小直連設定：僅驗證程序與監聽

以下是獨立的測試檔，不含代理節點，所有連線最後都會直接連線。這份設定用來排除 YAML、連接埠與程序啟動問題，不能用來驗證代理出口。

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

external-controller: "127.0.0.1:9090"

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

rules:
  - MATCH,DIRECT

7890 是本例的 HTTP/SOCKS 混合代理入口，9090 是控制介面，1053 是 DNS 監聽連接埠，三者不能互相取代。完成前景模式驗證後，再透過管理外掛或 OpenWrt 的 procd 服務管理功能啟動、停止與重新啟動；不要同時透過外掛、自建服務和背景指令啟動同一個核心執行個體。

主路由直接執行：集中接管並串接 DNS

主路由部署的優點是終端本來就會經過這台裝置，不必逐台修改閘道；但風險也會集中在這裡：防火牆或 DNS 設定錯誤，可能影響整個區域網路。因此應先只選一台測試裝置或一個測試網段，再逐步擴大接管範圍。

先在 LuCI 核對現有設定

• 前往「網路」→「介面」→「LAN」→「編輯」，記下 LAN 位址與子網路遮罩。
• 在 LAN 的「DHCP 伺服器」中檢查位址池與 DHCP 選項，確認沒有其他裝置同時派發互相衝突的閘道設定。
• 前往「網路」→「防火牆」，確認 LAN 到 WAN 的既有轉送規則沒有被誤刪。
• 前往「狀態」→「系統記錄」，檢查核心與 DNS 服務記錄。不同韌體的翻譯或佈景主題可能略有差異。

常見的 DNS 路徑是終端向路由器的 53 連接埠發出查詢，再由 dnsmasq 轉送至 mihomo 的本機 1053 連接埠。此時必須確認上游沒有反向指回 dnsmasq，否則可能形成解析迴圈。只設定 dns.listen 不會讓終端自動使用該服務，還需要明確設定轉送或接管規則。

旁路由閘道：用一台終端確認去程與回程

單網路埠旁路由通常與主路由位於同一網段。此例中，主路由為 192.168.50.1/24，旁路由為 192.168.50.2/24，測試終端為 192.168.50.100/24。這些位址僅供拓撲示範；部署前請避開現有 DHCP 位址池及其他位址。

1. 為旁路由設定固定 LAN 位址 192.168.50.2，並將預設上游閘道指向 192.168.50.1。
2. 暫時只讓主路由提供 DHCP，避免兩台裝置在同一廣播網域爭相派發位址。
3. 先在一台測試終端上，手動將預設閘道改為 192.168.50.2。
4. 如果旁路由已提供區域網路可用的 DNS 服務，再將測試終端的 DNS 設為 192.168.50.2；否則先單獨驗證路由。
5. 確認旁路由允許相應的轉送路徑，並檢查直連流量的回程是否符合設計。

在這種同網段架構中，直連流量可能先經旁路由到達主路由，回應封包卻由主路由直接送回終端，形成非對稱路徑。是否需要來源位址轉換、主路由靜態路由或不同子網路，應依防火牆狀態追蹤與網路拓撲判斷。不能一概以「旁路由一律關閉 NAT」或「一律啟用 NAT」取代實際判斷。

分別驗證閘道與 DNS

修改閘道只會決定 IP 封包的下一個躍點，不保證網域名稱查詢也會經過旁路由。瀏覽器的加密 DNS、終端設定的靜態 DNS，以及 IPv6 路由通告，都可能形成其他路徑。先檢查測試終端實際取得的 IPv4 閘道、IPv6 預設路由與 DNS 位址，再判斷是否需要接管。

單機驗證成功後，才考慮由主路由透過 DHCP 選項 3 指定 IPv4 預設閘道，並以選項 6 指定 DNS。部分家用主路由不支援細項派發；此時保留手動設定或使用獨立測試網段，比直接切換全網更容易復原。

透明代理：REDIRECT、TPROXY 與 TUN 的適用範圍

明確代理需要應用程式主動連線至 7890 等代理連接埠；透明代理則由路由與防火牆將原始連線送入核心。兩種入口可以並用，但要避免多組規則重複接管同一連線。

OpenWrt 22.03 起，常見的預設環境使用 firewall4 與 nftables。舊教學中的 iptables 規則不能未經確認就直接貼到新環境；還要檢查韌體是否採用自訂防火牆後端，以及是否已安裝所需模組。

啟用 TUN 不代表區域網路流量已完成接管

tun.auto-route 用來自動設定相關路由，但實際效果會受到系統、版本與網路架構影響；不能只看這個欄位，就推斷所有轉送流量都會進入 TUN。tun.auto-redirect 也有平台與版本限制，並非所有 Linux 環境都能直接套用。如果路由器上的接管規則由外掛管理，應交由外掛統一產生，不要再疊加另一套手動規則。

• 排除路由器管理位址、必要的本機網段，以及核心連線至上游代理伺服器的流量，避免形成迴圈。
• 使用 fake-ip 時，請確認 DNS 回傳的虛擬位址範圍有對應的路由與接管路徑，否則可能出現解析成功、連線卻失敗的情況。
• 需要 UDP 的應用程式，必須一併檢查入口機制、節點協定支援與伺服器端能力；網頁可透過 TCP 開啟，不代表 UDP 運作正常。
• 分別檢查 IPv4 與 IPv6。只設定 IPv4 透明代理，不會自動涵蓋 IPv6 連線。

區域網路接入：先設定明確代理，再檢查規則比對

正式接管前，可先讓一台終端使用明確代理，藉此排除網路轉送問題。若要讓區域網路使用測試設定的 7890，需將 allow-lan 改為 true，並將 bind-address 設為實際 LAN 位址，例如 "192.168.50.2"。同時透過防火牆，只允許可信任的網段存取。

不要透過 WAN 連接埠轉送公開代理連接埠或控制介面。讓 external-controller 維持在本機監聽，通常更容易控管存取；若確實需要遠端管理，請設定強式 secret，並限制來源位址。控制介面的驗證設定與混合代理連接埠的驗證設定不同，不能互相取代。

逐層縮小問題範圍

1. 程序層：確認設定測試通過、核心持續執行，且沒有第二個執行個體爭用連接埠。
2. 入口層：確認終端能連上 LAN 位址的代理連接埠。連線遭拒時優先檢查監聽位址；逾時則優先檢查防火牆與網路路徑。
3. 出站層：換成實際可用的節點與策略群組，檢查驗證資訊、協定與上游連線。前述直連測試檔不會提供代理出口。
4. 規則層：確認 mode: rule，再查看記錄中比對到的規則與出站策略。規則由上而下比對，太早出現的兜底規則會遮蔽後續規則。
5. 接管層：明確代理可用、透明代理卻無法運作時，優先檢查 DNS、策略路由、防火牆與 IPv6，不要一開始就反覆更換訂閱。

也要分開判斷核心資源用量與節點速度：網頁首次載入較慢可能與 DNS 或連線建立有關；大型檔案傳輸較慢，則可能受 CPU、加密處理、線路頻寬與壅塞影響。記下具體時間、測試終端、目標服務與比對到的策略，比只寫「旁路由變慢」更容易重現問題。

更新與復原：保留可用設定與獨立管理入口

訂閱更新、核心升級與防火牆變更應分開進行。更新訂閱可能覆蓋節點、策略群組與規則；管理外掛也可能在啟動時重新產生執行設定。需要長期保留的修改，應寫入外掛支援的覆寫或自訂規則入口，而非只修改暫時產生的檔案。

• 升級前記下 mihomo -v 的輸出，並保留可用的核心、主要設定檔與自訂規則。
• 先停止舊程序再替換二進位檔，接著測試設定，最後啟動服務；不要直接覆寫正在執行的檔案。
• 透過 logread 檢查啟動結果，確認規則資源已成功載入，再驗證 DNS、TCP 與所需的 UDP 應用程式。
• 保留一台能直接連線至管理位址的裝置。旁路由故障時，將測試終端的閘道與 DNS 還原為原本的主路由；若曾修改 DHCP 派發設定，也要還原選項並讓終端重新取得租約。

如果只需要讓一台電腦或手機使用代理，先執行對應平台的用戶端通常更省設定步驟。只有需要統一管理電視、遊戲裝置或多台終端時，再將閘道、DNS 與透明代理接管移至路由器。YAML 的基本結構與規則順序，請參閱設定檔結構及規則欄位說明。