先確認流量會經過哪台設備

在 OpenWrt 上啟動 mihomo，只代表代理核心已在執行，不代表區域網路裝置已經使用透明代理。完整流量路徑至少包含三個部分：終端裝置將流量送往旁路由，旁路由再把符合條件的連線交給核心，核心則依規則選擇直接連線或透過代理連線。DNS 也需要另外規劃，不能只修改預設閘道就認為設定完成。

mihomo 是由 Clash Meta 延續發展而來的代理核心，不是附有圖形介面的桌面用戶端。路由器外掛通常負責下載核心、產生設定檔、建立防火牆規則及管理服務；直接部署核心時，這些工作都需要自行處理。已由外掛接管網路的裝置，不建議再疊加另一套手動設定的透明代理規則。

先用一台終端裝置驗證

保留主路由器原有的 DHCP 設定，只修改一台測試電腦的閘道與 DNS。確認管理頁面、區域網路連線和代理連線都正常後，再考慮套用至整個網路。操作前請保留本機管理入口，避免透過正在調整的代理路徑遠端修改網路。

三種常見部署位置

部署方式流量入口主要檢查項目
主路由器執行核心終端裝置的預設閘道就是 OpenWrtWAN 出口、轉送區域、DNS 與路由接管
同網段單臂旁路由將旁路由設為終端裝置的預設閘道同介面轉送、回程路徑、ICMP 重新導向
獨立網段旁路由終端裝置連線至旁路由的下游網段上游靜態路由或 NAT、下游 DHCP、跨網段存取

主路由器方案的路徑直接，但故障影響範圍較大；同網段單臂方案方便分批測試，卻更容易發生去程經過旁路由、回程直接返回終端裝置的情況；獨立網段方案的網路邊界清楚，但需要額外管理路由或 NAT。選擇方案時應以現有網路拓樸為依據，而不是看設備有幾個網路埠。

閘道與 DNS 的指向方式

以下使用一組示意 IP 位址，不代表實際測量結果：主路由器為 192.168.10.1，OpenWrt 旁路由為 192.168.10.2，測試終端裝置為 192.168.10.100，子網路遮罩皆為 255.255.255.0。旁路由的預設路由仍指向主路由器，測試終端裝置的預設閘道則指向旁路由。

測試終端裝置 192.168.10.100
  預設閘道：192.168.10.2
  DNS：192.168.10.2
        ↓
OpenWrt 旁路由 192.168.10.2
  預設閘道：192.168.10.1
        ↓
主路由器 192.168.10.1
        ↓
網際網路

閘道決定流量路徑，DNS 決定查詢入口

  • 只修改 DNS：網域名稱查詢可能會送到旁路由，但業務連線仍可能直接經過主路由器，不能因此認定透明代理已生效。
  • 只修改閘道：業務流量可能會經過旁路由，但終端裝置仍向原本的 DNS 伺服器查詢，依網域名稱判斷與解析的策略可能不如預期。
  • 同時修改：較容易建立一致的測試路徑，但仍須確認旁路由允許轉送，且已實際接管流量。

在常見的 LuCI 介面中，可前往「網路」→「介面」→「LAN」→「編輯」檢查靜態位址；預設閘道與 DNS 的設定分頁則因韌體版本而異。若由主路由器負責 DHCP，通常要透過 DHCP 選項 3（預設閘道）和 6（DNS 伺服器）設定全網參數。請勿讓主路由器與旁路由在同一個廣播網域中，同時啟用未協調的 DHCP 服務，否則不同終端裝置可能取得不同的閘道。

同網段單臂轉送也應檢查 ICMP 重新導向：某些路由行為可能會提示終端裝置直接使用主路由器，因而繞過原先規劃的路徑。是否需要來源位址轉換，取決於回程路由與接管方式；「啟用偽裝」並非通用的修正方法。這會改變核心或上游設備看到的來源位址，也可能影響依終端裝置區分的規則與記錄。

部署前檢查系統與核心

先確認處理器架構、可用儲存空間與防火牆系統，再選擇執行檔。OpenWrt 套件的架構名稱與上游發佈套件名稱不一定完全相同，不能只看設備商品名稱來選擇。ARM 設備還要區分 32 位元、64 位元與具體指令集；x86 設備也應確認處理器是否支援所選的版本。

ubus call system board
uname -m
df -h /overlay
free
command -v fw4
command -v nft
ls -l /dev/net/tun
ip route show
ip -6 route show

以官方 OpenWrt 23.05、24.10 系列常見環境為例，防火牆通常由 firewall4 透過 nftables 管理。第三方韌體可能會修改相關元件，應以設備上的檢查結果為準。舊版教學中的 iptables 指令不能直接視為目前系統的正確做法，尤其不要讓兩套規則同時管理同一批連線。

先驗證設定，再啟動服務

以下假設核心位於 /usr/bin/mihomo，工作目錄為 /etc/mihomo，設定檔為 /etc/mihomo/config.yaml。這是本文採用的本機路徑，並非所有外掛的預設目錄。規則檔、地理資料與快取也應依實際設定放置，避免只複製 YAML 卻忽略執行所需的其他檔案。

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

-v 用來確認實際核心版本，-t 用來測試設定檔。測試通過只代表核心接受設定及相關載入條件，並不代表終端裝置的路由與防火牆設定已正確。初次排查時可先在前景啟動，確認記錄後再交由 OpenWrt 的 procd 管理；若核心由外掛維護，請使用外掛的服務入口，避免啟動第二個核心程序。

先建立本機代理與 DNS 基準

建議先驗證明確指定的代理，再接入透明代理。以下設定只建立本機監聽與直連基準，不包含代理節點，也不會讓終端裝置自動透過代理連線。實際部署時，應合併至一份有效設定檔，不要在檔案末尾新增第二個同名的頂層欄位。

mixed-port: 7890
allow-lan: false
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:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - MATCH,DIRECT
  • mixed-port: 7890：供明確指定的 HTTP/SOCKS 代理使用，並非透明代理入口。若要讓測試電腦連線至此連接埠，還需另外設定 LAN 監聽與嚴格的存取限制。
  • allow-lan: false：此基準設定不會向區域網路開放明確指定的代理服務。TUN 接管轉送流量，與開放此連接埠是兩回事。
  • 127.0.0.1:9090：控制介面僅在本機監聽。如需遠端管理，應另外規劃驗證機制與存取範圍，不要直接對公網開放。
  • 127.0.0.1:1053：DNS 僅接收本機轉送的查詢。此處未使用 53 連接埠，是為了避免直接與 dnsmasq 的監聽服務衝突。
  • MATCH,DIRECT：所有未符合規則的連線都直接連線，先用來驗證網路路徑。若要使用代理出口，仍須新增有效節點、策略群組與對應規則。

若設備已安裝 curl 和 nslookup，可分別在旁路由上測試明確指定的代理與 LAN DNS。範例網域僅用於檢查連線，回應時間不能代表代理節點的品質。

curl --proxy http://127.0.0.1:7890 -I https://example.com
nslookup example.com 192.168.10.2

為 DNS 選擇單一轉送路徑

一種容易檢查的設計是：終端裝置向旁路由的 53 連接埠查詢，再由 dnsmasq 轉送至本機 mihomo 的 1053 連接埠。常見的 LuCI 設定路徑為「網路」→「DHCP/DNS」→「一般設定」→「DNS 轉送」，填入 127.0.0.1#1053；同時檢查是否仍從上游取得其他解析伺服器。若要讓所有外部查詢都經過核心，須依韌體介面調整「忽略解析檔」等設定，並保留必要的本機網域處理。

避免 DNS 迴圈

dnsmasq 已將查詢轉送給 mihomo 時，mihomo 的上游 DNS 就不能再指回同一條 dnsmasq 轉送路徑。此處使用的數值 IP 上游僅為說明連線路徑，並非一體適用的建議。若改用以網域名稱設定的加密 DNS，還須考慮上游網域的引導解析，以及上游連線要直接連線還是透過代理。

透明代理的三種接管方式

透明代理是指終端應用程式不必逐一填入代理位址，並不代表所有通訊協定都會自動具備代理能力。實際涵蓋範圍取決於接管方式、核心支援、節點協定與防火牆規則。UDP、IPv6 與區域網路目的位址都必須分別檢查。

方式基本原理部署注意事項
REDIRECT防火牆將連線重新導向至透明代理監聽連接埠常用於 TCP；不能把 TCP 重新導向規則直接當成完整的 UDP 接管方案
TPROXY透明通訊端搭配流量標記與策略路由可用於 TCP 與 UDP，但需要相符的核心模組、路由與防火牆規則
TUN透過虛擬第三層網路裝置將 IP 流量交給核心需要 TUN 支援與相應權限，並須確認路由和 LAN 轉送是否進入接管路徑

選定一種主要方案後再進行設定，不要為了「涵蓋更完整」而同時啟用外掛 TPROXY、自訂 REDIRECT 和另一套 TUN 自動路由。這類設定疊加可能導致連線重複進入核心、標記衝突或路由迴圈，通常會出現部分網站能開啟、部分連線持續逾時的情況。

TUN 欄位範例

以下片段適用於支援相應欄位的 Linux mihomo 版本，用來說明 TUN 的接管方式，並非適用於所有 OpenWrt 韌體的一鍵設定。請先使用實際的核心測試設定，並檢查執行記錄、產生的規則與路由；較舊版本可能不接受部分欄位。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack: []
  • enable：啟用 TUN。系統需要可用的 TUN 裝置與相應的網路管理權限。
  • stack: mixed：選擇混合協定堆疊，不代表同時啟用多個透明代理入口。
  • auto-route：由核心設定相關自動路由。這不能取代 LAN 的閘道設定，也不保證韌體中的所有轉送策略都允許流量通過。
  • auto-redirect：在支援的 Linux 環境中，搭配自動路由建立接管所需的規則。是否與 firewall4、現有外掛及策略路由相容，仍須實際檢查。
  • strict-route：限制接管路由的行為，但不代表已完成 IPv6 與所有繞行路徑的檢查。
  • dns-hijack: []：此範例不透過 TUN 劫持 DNS，繼續使用前面明確設定的 dnsmasq 轉送路徑，避免初次部署時疊加兩套 DNS 接管方式。

若改由 TUN 接管 DNS，請重新檢查查詢入口、上游解析與排除規則，不要只複製 any:53 就結束設定。傳統 UDP/TCP 53 查詢、應用程式內建的 DoH 和系統私人 DNS 是不同的路徑，接管 53 連接埠不會自動涵蓋應用程式內的加密解析。

IPv6、回程路徑與防火牆界線

IPv4 測試成功，不代表雙堆疊終端裝置的所有連線都會經過旁路由。主路由器可能仍會透過 IPv6 路由通告，向終端裝置提供預設路由；終端裝置連線至具有 AAAA 記錄的網站時，就可能改走另一條路徑。只調整 DHCPv4 的 3 和 6 選項，無法控制這條 IPv6 路徑。

  1. 先在測試終端裝置查看 IPv4、IPv6 的預設路由，確認實際的下一個躍點。
  2. 明確選擇完整接管雙堆疊，或先將測試範圍限制在 IPv4；不要只停用 mihomo 的 IPv6 DNS 結果，就認為系統的 IPv6 已停用。
  3. 檢查 LAN 到上游的轉送權限、同介面轉送與相關防火牆區域。不要為了排除問題，就直接將所有區域的輸入與轉送政策設為允許。
  4. 確認路由器管理位址、內部網路網段，以及代理伺服器本身連線的繞行設定，避免出口連線又被送回接管入口。

可使用 nft list ruleset 檢視防火牆規則，並使用 ip rule show 和 ip route show table all 檢視策略路由。命令輸出應搭配現有外掛與韌體判讀；不同實作的命名方式與優先順序可能不同，不要只依固定的表格編號或規則名稱判斷是否成功。

分層驗證並安全復原

排除問題時，應從入口到出口逐層確認，每次只變更一個變數。能開啟網頁只代表某條路徑可用，無法判斷流量是直接連線、明確指定代理，還是透明代理。應搭配終端裝置路由、核心連線記錄及實際套用的策略一併判斷。

現象優先檢查下一步
終端裝置無法開啟旁路由管理頁面位址、遮罩、位址衝突、輸入規則先恢復區域網路管理，不要繼續修改透明代理
IP 可連線，但網域名稱解析失敗53 與 1053 連接埠監聽、dnsmasq 轉送、解析迴圈分別驗證 LAN DNS 入口與核心上游
本機明確指定的代理運作正常，但終端裝置沒有連線記錄預設閘道、IPv6、轉送與接管規則確認流量是否真的進入旁路由
TCP 正常，但遊戲或語音異常UDP 接管、節點 UDP 支援、防火牆使用相應的通訊協定重新測試，不要以網頁測試結果代替
重新載入防火牆後連線失效自動接管規則是否仍然存在透過所屬服務重建規則，並檢查服務啟動順序

依序復原：先終端裝置，再服務

測試失敗時，先將測試終端裝置的預設閘道恢復為 192.168.10.1，DNS 恢復為原本有效的設定，再停止新增的服務，並清除該服務建立的接管規則。也要檢查 TUN 結束後的路由清理，不能只刪除執行檔。若已修改全網 DHCP，請恢復原設定，並讓終端裝置更新租約。

部署穩定後，再設定 procd 自動啟動、記錄容量與設定更新流程。每次更新設定前先執行測試，確認節點名稱與策略群組引用一致，再重新載入服務。若更新涉及防火牆與路由，也應重新驗證終端裝置的 DNS、TCP、UDP、IPv6 與區域網路存取。欄位說明請參閱設定參考，基本匯入與用戶端操作則可參考安裝與設定教學。