OpenWrt 路由器與旁路由安裝 mihomo 核心：部署方式與硬體需求總覽

先釐清核心、管理介面與透明代理

mihomo 是延續 Clash 設定架構的代理核心，早期常稱為 Clash Meta。它會讀取 YAML 設定，處理節點連線、代理群組、DNS 與分流規則。OpenWrt 則負責網路介面、路由、防火牆與服務管理。把執行檔放進路由器，不代表區域網路裝置的流量已經經過代理。

在路由器上部署時，必須分別確認三個環節：服務能否啟動、終端流量能否進入核心，以及核心是否選到正確的出口。LuCI 管理外掛通常會整合這三個部分；手動安裝核心則需要自行串接。

• 手動設定代理：在電腦或瀏覽器指定路由器位址及 HTTP、SOCKS 連接埠。只有遵循這項設定的應用程式會使用代理。
• 透明代理：由閘道透過重新導向、政策路由或 TUN 接管流量，終端不必逐一填寫代理位址。
• DNS 分流：決定由哪個解析器回覆網域名稱，並提供規則比對所需資訊；這與流量轉送有關，但並非同一項功能。

主路由與旁路由的拓撲差異

主路由部署：流量集中，影響範圍也較大

主路由直接連接上游網路，通常也負責撥號、DHCP、DNS 轉送與 NAT。終端的預設閘道指向主路由，因此透明代理的接管路徑較明確。設定更新、規則載入與代理程序也會和撥號、無線網路及其他服務競用資源。

網際網路
  │
OpenWrt 主路由：LAN 192.168.1.1
  │
交換器 / 無線基地台
  │
電腦：192.168.1.100，閘道 192.168.1.1

適合已有支援 OpenWrt 的裝置，且需要集中管理全網流量的環境。正式啟用前，請保留本機管理管道；代理服務異常時，基本轉送是否恢復直連，取決於外掛的防火牆清理與故障處理方式，不能預設會自動恢復。

單網卡旁路由：逐台測試，留意回程路徑

常見的旁路由只有一個 LAN 介面，並與主路由接在同一個交換網路。主路由仍負責連線；測試電腦將預設閘道改為 192.168.1.2，旁路由本身的預設閘道則仍為 192.168.1.1。旁路由必須啟用 IP 轉送，並設定允許相應轉送流量的防火牆規則。

主路由：192.168.1.1，負責連網與原有 DHCP
  │
同一個 LAN 交換網路
  ├─ 旁路由：192.168.1.2，預設閘道 192.168.1.1
  └─ 測試電腦：192.168.1.100，預設閘道 192.168.1.2

在這種拓撲中，可能發生去程經過旁路由、回程卻由主路由直接送回終端的情況。是否需要在旁路由進行來源 NAT，應依外掛需求與連線追蹤結果判斷。啟用 SNAT 可讓部分回程流量經過旁路由，但也會隱藏原始終端位址；不要把「所有介面都啟用偽裝」當成通用解法。

三種部署方式與維護成本

外掛通常更方便管理訂閱、代理群組與執行記錄，但必須確認它支援的核心版本與防火牆後端。OpenWrt 22.03 起預設使用以 nftables 為基礎的 firewall4；若舊版外掛只會產生傳統 iptables 規則，不能只憑「安裝成功」就認定透明代理可用。客製韌體也可能更換元件，請確認實際環境。

原生執行適合需要掌控設定來源與升級時程的使用者。可先執行核心的設定檔測試指令，再交由 procd 管理服務。若訂閱檔沒有路由器端的 DNS、監聽與流量接管設定，還需要合併本機設定；否則更新一次就可能覆蓋本機設定。

容器適合資源較充足的裝置，但不會讓透明代理變得簡單。TUN 通常需要可用的 /dev/net/tun 與相應的網路管理權限；橋接網路中的監聽位址也不等於主機的 LAN 位址。不要只為了讓容器啟動，就直接授予所有權限。

# 假設核心已放在 /usr/bin/mihomo
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

上述路徑僅為手動部署範例，並非所有外掛都使用的固定目錄。測試時應使用外掛實際呼叫的設定檔；部分外掛會在暫存目錄產生最終設定，而非直接使用下載的訂閱檔。

架構選擇與記憶體、儲存空間規劃

先確認 CPU 與韌體目標，再選擇核心檔案

ubus call system board
uname -m
cat /proc/cpuinfo
free -m
df -h /overlay /tmp

可用 ubus call system board 查看裝置與韌體目標資訊，並以 uname -m 輔助判斷執行架構。常見對應包括 aarch64 對應 ARM64、x86_64 對應 AMD64。MIPS 還要區分大小端與軟浮點等建置差異，不能只看到「MIPS」就選檔案。

ARMv7 以及要求特定 CPU 指令集的 x86 建置版本，也必須符合硬體條件。出現 Exec format error 時，優先檢查架構與檔案格式；出現 Illegal instruction 時，則檢查指令集需求。這兩種狀況都無法透過修改訂閱連結解決。

容量數據僅供規劃，並非效能保證

這些數據僅供容量規劃參考，並非實測吞吐量或最低系統需求。實際用量取決於規則來源、地理資料格式、連線數、DNS 快取與外掛實作。不要只因為 free 顯示「空閒」記憶體偏低就認定記憶體不足，應一併查看可用記憶體、程序常駐用量與核心記錄。

• 儲存空間：規劃時須納入目前的核心、設定與規則資料；更新期間也可能同時保留舊檔、下載套件與解壓縮檔。
• 暫存目錄：OpenWrt 的 /tmp 通常使用記憶體檔案系統，下載大型檔案會與執行中的程式競用記憶體。
• 寫入頻率：避免將持續產生的除錯記錄寫入容量有限的快閃記憶體；平時使用適當的記錄層級，排查問題時再短暫開啟詳細記錄。
• CPU：代理加密、使用者空間轉送與規則比對都會消耗運算資源。有千兆網路連接埠，不代表所有代理協定都能達到千兆傳輸速率。

閘道、DNS 與連接埠的設定界線

釐清每個位址的用途

在上述旁路由範例中，測試電腦的閘道是 192.168.1.2。若旁路由提供 LAN DNS，電腦的 DNS 也可設為這個位址，但前提是旁路由確實在 LAN 的 53 連接埠監聽。只變更 DNS 不會讓一般外網流量自動經過旁路由；只變更閘道，也不保證 DNS 查詢會走核心的解析流程。

常見的設計方式是由 dnsmasq 在 53 連接埠提供 LAN DNS，再將需要的查詢轉送至核心的 127.0.0.1:1053。此時必須避免查詢繞回自身：例如核心把 dnsmasq 設為上游，而 dnsmasq 又把所有請求送回核心，就會形成解析迴圈。若管理外掛已接管 DNS，請透過外掛設定調整，不要再另外加入一組相同規則。

fake-ip 與 IPv6 必須一併確認

fake-ip 模式通常會使用 198.18.0.0/16 這類保留位址池回傳對應位址。取得這類位址本身不代表解析失敗，但後續連線必須由同一套代理接管機制處理。如果終端收到 fake-ip，卻繞過旁路由直接連線，就可能出現網域名稱解析正常、連線卻逾時的情況。

變更 IPv4 閘道不會自動接管 IPv6。主路由仍可能透過路由器通告向終端發布 IPv6 預設路由與 DNS，讓部分連線改走其他路徑。請選擇完整設定 IPv6 接管，或在測試階段明確限制測試終端使用 IPv6，再分別驗證；不能只憑一次 IPv4 測試成功，就認定雙協定堆疊流量都已接管。

透明代理、TUN 與防火牆的協作方式

常見的流量接管方式包括 TCP 重新導向、TPROXY 與 TUN。TCP 重新導向主要處理 TCP；TPROXY 可用於 TCP、UDP，但需要相應的核心模組、政策路由與防火牆規則。TUN 透過虛擬網路裝置接收 IP 封包，同樣需要正確設定路由、權限與轉送。

mihomo 的 tun.auto-route 用於自動設定相關路由，auto-redirect 則涉及 Linux 的自動重新導向功能；是否可用，須確認核心版本與系統相依項目。這些設定並不保證能「接管所有 LAN 裝置」，尤其已有外掛產生規則時，不應再同時啟用另一套自動路由方案。

• 保留區域網路管理與必要私有網路流量的正確路徑，避免連路由器管理介面的流量也被送往代理出口。
• 確保代理節點本身的連線不會再次進入同一個接管入口，否則可能形成流量迴圈。
• 確認軟體與硬體流量卸載是否會繞過目前的接管方案；先停用卸載進行基準測試，再依外掛的相容性說明恢復。
• 只執行一套透明代理管理服務。兩個外掛可能會爭用 DNS 連接埠、覆寫路由或重複攔截同一條連線。

# 在 OpenWrt 查看目前狀態；實際指令取決於已安裝的元件
ip route show
ip rule show
nft list ruleset
logread | grep -i mihomo
dmesg | grep -i -E 'oom|out of memory'

ip route show 預設主要顯示主路由表；若政策規則參照其他路由表，還要查看對應的表。記錄顯示服務啟動成功，只能證明程序正在執行，不能證明 LAN 轉送、DNS 或 UDP 連線都已通過測試。

逐台終端驗收，並預先規劃回復方式

1. 保存基準設定。備份 OpenWrt 設定，記下主路由、旁路由、DHCP 範圍與管理位址。保留一台閘道仍指向主路由的管理裝置。
2. 先驗證核心。執行設定檔測試，確認訂閱載入成功、代理群組有可用節點，且服務不會不斷停止。節點連線也需要時間同步及上游網路暢通。
3. 先測試手動代理。若已啟用範例連接埠 7890 並允許 LAN 存取，請在測試電腦執行下方的請求，區分節點問題與透明代理接管問題。
4. 再變更測試電腦的閘道。設為 192.168.1.2，並依實際 DNS 方案設定解析位址；確認區域網路管理、直連網站與代理規則都運作正常。
5. 檢查規則與連線。在管理面板查看目標網域、命中的規則、代理群組與最終節點。網頁能開啟不代表流量一定經過代理，也可能是符合 DIRECT 規則。
6. 最後再擴大範圍。測試 UDP、IPv6、規則更新與裝置重新啟動。全部通過後，再調整 DHCP 發送策略或移轉更多終端。

# 在測試電腦執行；請先啟用對應的 HTTP 代理入口
curl -I --proxy http://192.168.1.2:7890 https://example.com/

# 確認旁路由已提供 LAN DNS 後，再執行
nslookup example.com 192.168.1.2

第一個指令用來驗證 HTTP 代理連線，不代表所有應用程式、UDP 與透明代理都已可用。第二個指令只驗證指定的 DNS 伺服器能否回覆，不代表回覆結果來自預期的上游；請搭配核心查詢記錄與實際連線記錄交叉確認。

回復設定時，先將測試電腦的閘道與 DNS 還原，再停用代理服務，並確認外掛已清除接管規則。若先前調整過 DHCP，請讓終端重新取得租約。不要只結束核心程序，卻留下指向已關閉連接埠的防火牆重新導向規則。

部署前的選擇建議

若已有穩定且資源充足的 OpenWrt 主路由，集中部署可減少額外閘道的維護工作。若希望分批測試並保留原有連網架構，可先採用旁路由，但必須處理終端閘道設定、DNS 配置與回程路徑。旁路由不是自動接管全網的裝置類型，而是一種特定的轉送拓撲。

選擇部署方式前，先確認 CPU 架構、可用記憶體與持久儲存空間，再挑選與韌體防火牆相容的管理方式。正式啟用時，依序進行「手動代理 → 單台透明代理 → DNS 與雙協定堆疊 → 擴大至全網」。每個階段都有明確界線，遇到問題也能回到已驗證的前一階段，不必同時修改訂閱、閘道與防火牆。