選擇部署方式：先決定閘道位置，再選擇接管方式

主路由效能足夠，且需要統一管理所有網路裝置時，可直接在 OpenWrt 上執行 mihomo；若要保留現有主路由，只讓部分裝置接入，旁路由更適合分批測試。初次部署建議先測試手動代理，再接入 DNS，最後啟用透明代理，避免同時修改三處設定而無法判斷故障來源。

mihomo 是從 Clash Meta 發展而來的代理核心，負責協定連線、規則比對和 DNS 等功能。它不是路由器韌體，也不附帶完整的路由管理介面。OpenWrt 外掛通常負責產生設定、管理程序、安裝防火牆規則並提供 LuCI 頁面；若直接執行二進位檔，則需要自行處理這些工作。

部署位置接入方式主要維護項目
OpenWrt 主路由在統一出口接管 LAN 流量防火牆、DNS、硬體流量卸載
OpenWrt 旁路由指定裝置將閘道設為旁路由回程路徑、DHCP、同網段轉送
Linux 小主機手動代理或設為閘道服務管理、轉送、路由與防火牆
容器中的 mihomo先提供明確代理，再評估透明接管網路命名空間、裝置映射與權限

硬體需求：確認架構、可用記憶體與儲存空間

以作業系統架構為準

先透過 SSH 執行以下指令。CPU 支援 64 位元，不代表目前安裝的韌體也是 64 位元；下載二進位檔時，必須符合實際的系統架構。ARM 還要留意指令集等級，MIPS 則須區分大端序與小端序。需要較新指令集的版本，不能直接用在較舊的處理器上。

uname -m
cat /etc/openwrt_release
free -m
df -h /overlay
df -h /tmp

例如，aarch64 通常代表 ARM64，x86_64 則代表 64 位元 x86。若啟動後出現非法指令，請先確認版本的硬體需求；若顯示無法執行，也要檢查檔案架構、執行權限和執行環境，不要一再更換訂閱。

依執行餘裕規劃容量

  • 256 MB 記憶體裝置：屬於資源吃緊的情況。應減少規則集和訂閱規模，並在更新規則時留意剩餘記憶體，不能只看啟動後的使用量。
  • 512 MB 記憶體裝置：可作為輕量家庭部署的評估起點，但還要扣除無線服務、檔案分享和其他外掛所占用的資源。
  • 1 GB 以上記憶體：較適合同時執行多項服務或使用較大的規則集，仍須依實際連線數觀察資源使用量。
  • 儲存空間：初步規劃時建議至少預留 100 MB 可寫入空間，用來存放核心、設定、規則資料和更新暫存檔；這並非適用於所有設定的最低需求。

OpenWrt 的 /tmp 通常使用記憶體檔案系統。將大型檔案放在其中會占用記憶體，重開機後也可能消失。傳輸效能則同時受 CPU 單核心效能、加密協定、網卡驅動程式和透明代理路徑影響，不能只憑千兆網路埠就推定代理速度一定可達千兆。

安裝方式：外掛管理、原生服務與容器

OpenWrt 外掛：透過單一管理介面設定

選擇符合目前韌體版本和防火牆架構的外掛。較新的 OpenWrt 通常使用 firewall4 與 nftables，較舊環境可能仍使用 firewall3 與 iptables；安裝前應查看外掛文件，不要將舊版防火牆指令碼直接套用到新系統。

  1. 備份目前的網路、DHCP 和防火牆設定，記下路由器 LAN 位址及 SSH 登入方式。
  2. 透過外掛安裝 mihomo 核心，或選擇符合架構的版本，再加入支援該核心的訂閱設定。
  3. 先關閉透明接管，只確認設定能載入、節點可連線，再逐項啟用 DNS 和流量接管。
  4. 確認外掛是否會重新產生設定。需要長期保留的修改，應放在外掛提供的覆寫或附加設定欄位。

外掛的選單名稱會隨專案和版本而異，不能一律照著桌面用戶端的設定路徑操作。也不要讓兩個代理外掛同時接管 DNS 或透明轉送，否則可能造成連接埠衝突、規則互相覆蓋或重複代理。

原生二進位檔：自行管理程序與開機啟動

以下範例假設核心已安裝於 /usr/bin/mihomo，設定檔儲存於 /etc/mihomo/config.yaml。先檢查語法，再以前景模式啟動並查看記錄：

/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

設定檢查通過，不代表遠端節點可以連線，也不代表透明轉送已生效。以前景模式完成驗證後，OpenWrt 應交由 procd 管理服務；使用 systemd 的 Linux 則建立對應的服務單元，設定工作目錄和重新啟動策略。避免只透過 SSH 在背景啟動，否則離開終端機或重開機後，服務可能就不再執行。

容器：明確代理比透明閘道容易部署

一般橋接網路搭配連接埠映射，可先提供 HTTP 或 SOCKS 代理。TUN 通常還需要存取 /dev/net/tun、網路管理權限，以及適當的網路模式。容器中的路由只影響其所在的網路命名空間，不會自動接管主機或整個 LAN。不要為了排查問題就直接開放所有權限，應先確認流量需要在哪一層進入核心。

旁路由拓撲：分別確認閘道與 DNS

以實際網路為例：主路由為 192.168.50.1，旁路由固定使用 192.168.50.2，兩者子網路遮罩皆為 255.255.255.0。旁路由本身的預設閘道指向主路由。初次測試時只修改一台電腦，其他裝置維持原有設定。

測試模式終端設定驗證目標
手動代理閘道仍為 .1，應用程式代理指向 .2:7890核心、訂閱與節點連線
透明代理預設閘道改為 .2，DNS 指向已設定的 LAN DNS 服務轉送、規則與 DNS 接管
還原原有網路閘道與 DNS 還原為 .1，或恢復原本的 DHCP 設定區分旁路由故障與上游故障

只修改 DNS，無法讓所有連線自動經過旁路由；只修改閘道，也不能保證網域名稱解析正常。透明代理還需要系統允許 IP 轉送，並設定正確的防火牆與回程路徑。單網卡旁路由尤其要留意：直連流量可能從旁路由轉送至主路由，但回應流量卻由主路由直接送回終端，形成非對稱路徑。

部分方案會使用來源位址轉換來確保回程路徑穩定，但這會改變上游看到的來源位址，不應不加判斷地複製一條 NAT 指令。請依照所用外掛的拓撲說明進行設定。確認單台裝置正常後，再考慮透過 DHCP 發送閘道選項 3 和 DNS 選項 6；同一廣播網域中不要任意啟用第二個 DHCP 服務。

設定重點：先開放受限的區域網路代理入口

以下是前述網路的基本設定片段，並非完整訂閱，只用來說明監聽位址、混合代理連接埠和 DNS 入口之間的關係。節點、策略群組與規則仍須來自有效設定；若使用外掛，請透過外掛支援的方式設定，避免直接修改產生的檔案。

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

dns:
  enable: true
  listen: 192.168.50.2:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • mixed-port: 7890 同時提供 HTTP 和 SOCKS 代理入口。這個連接埠不是透明代理入口，終端必須明確設定代理才能使用。
  • allow-lan: true 允許區域網路裝置連線，但防火牆仍應限制只有可信任的 LAN 可以存取。不要將 7890 連接埠轉發到公網。
  • bind-address 綁定範例中的旁路由位址。實際部署時，該位址必須存在於本機網路介面上。
  • 1053 是範例中的 DNS 上游監聽連接埠；一般終端預設會向 53 連接埠查詢，無法只透過 DHCP 指定 1053。

在 OpenWrt 上，可讓 dnsmasq 繼續透過 53 連接埠提供 LAN DNS 服務，再將查詢轉送至 mihomo 的 1053 連接埠。此時必須檢查轉送鏈：dnsmasq 指向 mihomo，而 mihomo 的上游不能再指回同一個 dnsmasq，以免形成 DNS 迴圈。範例中的公用 DNS 解析器僅用來展示格式，實際設定應依據本地網路的可連線性和分流需求調整。

透明代理與 TUN：避免重複接管同一批流量

常見的透明代理方式包括防火牆重新導向、TProxy 和 TUN。重新導向通常用於 TCP；TProxy 可處理 TCP 與 UDP，但需要相應的核心功能、策略路由和防火牆規則。TUN 則透過虛擬網路介面將流量交由核心處理，不代表路由和 DNS 問題都會自動解決。

三個環節都要檢查

  1. 接入：LAN 轉送流量是否進入預期的規則鏈或 TUN 路由。只接管路由器自身流量，不能證明 LAN 裝置也已接入。
  2. 排除：代理節點伺服器位址、區域網路位址和核心本身的對外流量，是否已正確排除，以免再次進入代理而形成迴圈。
  3. 回程：策略路由、防火牆標記與連線追蹤是否一致，UDP 和 TCP 是否都經過預期路徑。

mihomo 的 TUN 可透過 auto-route 等選項協助建立路由；在支援的 Linux 環境中，auto-redirect 也可協助重新導向。是否啟用應依照外掛設計。不要同時啟用外掛的 TProxy 接管與另一套獨立的 TUN 自動接管，並期待兩者自行協調。

排查問題時，可暫時關閉軟體或硬體流量卸載，再比較行為。某些加速路徑可能會繞過必要的處理鏈。若只有 QUIC 影片或遊戲發生異常，應另外檢查 UDP 轉送和節點協定支援，不能只用瀏覽器開啟網頁就認定所有流量都正常。

DNS、Fake-IP 與 IPv6：確保解析和連線路徑一致

Fake-IP 會為網域名稱回傳映射位址，範例使用 198.18.0.0/16。mihomo 必須識別這些位址並將其對應回網域名稱，不能把它們當成公網目標直接交給上游路由器。因此，終端取得 Fake-IP 後，其連線也必須進入同一套代理接管路徑。

  • 區域網路網域名稱：印表機、NAS 和路由器管理介面的網域名稱應保留本地解析。必要時可搭配 Fake-IP 過濾和 DNS 策略處理，不能只加入過濾規則就忽略本地解析來源。
  • 應用程式內建的加密 DNS：瀏覽器的 DoH 可能繞過系統 DNS。傳統的 53 連接埠接管無法涵蓋這類查詢，測試時應確認瀏覽器是否另行設定了解析器。
  • IPv6：終端可能透過路由器公告取得另一條預設路由。若只修改 IPv4 閘道，IPv6 連線仍可能直接連出。
  • 還原設定：停用 Fake-IP 或切換 DNS 後，應清除終端與應用程式的快取，避免繼續使用舊的映射位址。

範例停用了 mihomo 的 IPv6 使用和 AAAA 回應，但這不代表整個 LAN 的 IPv6 都已停用。部署前應先決定：完整設定 IPv6 接管，或在測試網路中暫時停用 IPv6 路由公告及相關服務。不要把遺漏 IPv6 路徑誤判為規則隨機失效。

驗收與復原：依連線路徑逐層定位

每次只修改一個變數，並記錄修改前後的設定。以下指令分別用於查看程序記錄、監聽連接埠、路由和 DNS；依系統已安裝的工具選擇執行，不必為了一次排錯就把所有工具都裝齊。

logread | grep -i mihomo
ss -lntup
ip route show
ip rule show
nslookup example.com 192.168.50.2
curl -I -x http://192.168.50.2:7890 https://example.com

nslookup 這個指令測試的是旁路由 53 連接埠的 LAN DNS 服務，不是範例中的 1053 監聽連接埠。若未部署前端 DNS 服務，就不能據此判定 mihomo 的 DNS 模組故障。curl 測試的是明確設定的 HTTP 代理，與透明代理是兩種不同的驗證路徑。

現象優先檢查項目下一步
設定無法載入縮排、欄位型別、核心相容性執行設定檢查，找出具體錯誤行
手動代理也無法連線監聽位址、LAN 防火牆、節點連線狀態先確認單一代理入口可正常連線
手動代理正常，修改閘道後失敗轉送功能、接管規則、回程路徑檢查路由與防火牆計數
部分網域名稱異常DNS 快取、Fake-IP、本地域名解析比較系統與應用程式使用的解析來源
IPv4 正常，部分連線直接連出IPv6 預設路由與接管範圍分別驗證 IPv4 和 IPv6 路徑

驗收完成後再啟用開機啟動，並重新開機一次，確認設定、規則資料和防火牆都能依序還原。若測試失敗，先將終端的閘道和 DNS 還原為原本的主路由，再透過外掛關閉接管並還原相關防火牆設定；只停止核心可能會留下指向失效介面的規則。保留一個不經過旁路由的管理入口，可降低設定錯誤導致整個網路中斷的風險。