OpenWrt 旁路由部署 Clash 核心：透明代理、TProxy／Redir 與 DNS 閘道設定

部署範圍：核心啟動不代表透明代理已生效

在 OpenWrt 上直接執行 Clash 類核心，必須分別處理程序、流量入口與 DNS。程序成功啟動，只表示設定檔能載入；用戶端流量還必須經過旁路由，再由防火牆導入透明代理連接埠。本文以 mihomo 為例，說明這三個環節如何串接。

• 程序層：選用符合裝置架構的執行檔，將設定檔放在 /etc/mihomo/config.yaml，並交由 OpenWrt 的 procd 管理服務。
• 轉送層：將用戶端的預設閘道設為旁路由，並確保旁路由能將直連流量繼續轉送至主路由。
• 流量接管層：由防火牆選取需要代理的連線，並透過明確設定的本機解析鏈處理 DNS。

如果裝置已安裝代理管理外掛，先確認它是否負責啟動核心、產生設定檔及寫入防火牆規則。同一台路由器再手動啟動另一套流量接管機制，容易造成連接埠衝突、重複重新導向或設定遭覆寫。直接執行核心與使用管理外掛，應擇一作為主要管理方式。

網路拓撲：先讓單一裝置經過旁路由

以下位址僅供單網卡、同網段旁路由的情境參考，實際設定請依現有網段調整。主路由繼續負責網際網路出口與 DHCP；旁路由使用固定 IP，並只修改測試電腦的閘道與 DNS。

檢查 OpenWrt 介面與轉送設定

在 LuCI 的「網路」→「介面」→「LAN」→「編輯」中檢查固定 IP。不同主題的標籤可能略有差異，請以介面、IPv4 位址與閘道欄位為準。不要誤將主路由 IP 填入旁路由自己的預設閘道欄位。

ip -4 addr show
ip -4 route show
sysctl net.ipv4.ip_forward
ping -c 3 192.168.10.1

路由表應包含指向 192.168.10.1 的預設路由；轉送功能應設為 1。也要確認防火牆允許相關介面間的轉送。單網卡旁路由的流量可能從同一個 LAN 介面進出，不能直接套用雙網卡的 LAN→WAN 規則。

同網段轉送也要考慮回程路徑：直連連線可能經旁路由送出，卻由主路由直接回傳到電腦。非對稱路徑、ICMP Redirect 與連線追蹤策略都可能影響結果。在部分網路拓撲中，來源 NAT 可讓回程流量重新經過旁路由，但也會隱藏原始用戶端 IP。是否啟用應依實際路由與防火牆設定判斷，不要直接照抄成固定開關。

核心檔案：確認架構、設定目錄與啟動參數

先執行 uname -m 查看硬體架構，再執行 ubus call system board 查看系統資訊。架構名稱相近不代表執行檔一定相容，還需確認 CPU 指令集與發布檔案的執行需求。不要將桌面用戶端安裝檔當成路由器核心執行。

uname -m
ubus call system board
df -h /overlay
free -m

確認裝置有足夠的永久儲存空間與記憶體。規則集、地理資料庫和連線數量都會增加資源用量，沒有適用於所有設定的固定記憶體門檻。唯一的設定檔副本不要放在重新開機後會清空的 /tmp。

以下命令假設已取得符合裝置架構的 mihomo 執行檔，並儲存為 /usr/bin/mihomo，完整 YAML 設定檔也已放入指定目錄。先測試設定，再啟動服務：

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-v 用來確認目前實際使用的核心版本；-t 用來檢查設定檔。若日誌顯示缺少規則檔、資料庫或下載失敗，請先補齊相關資源。設定檔測試通過，不代表遠端節點可用，也不代表防火牆已完成流量接管。

Redir、TProxy 與 TUN：依流量類型選擇入口

本文主要介紹 Redir 與 TProxy。Redir 的 TCP 入口不能取代通用的 UDP 接管；只設定 Redir 時，QUIC、遊戲或語音應用的 UDP 流量不會自動經過代理。TProxy 可接管 UDP，但仍須確認所選節點協定與伺服器支援相應轉送。

mihomo 連接埠設定範例

以下是合併至現有設定檔的片段，並非可獨立完成代理部署的訂閱設定。請保留原有節點、策略群組與規則，避免在 YAML 頂層重複定義相同鍵名。兩種透明代理入口可以同時監聽，但同一股流量應明確交由一條防火牆路徑處理。

mode: rule
log-level: info
redir-port: 7892
tproxy-port: 7893

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

此處以較容易觀察的 redir-host 作為起點，DNS 會回傳真實 IP。223.5.5.5 是上游解析器範例，請依所在地的連線狀況與解析需求選擇，並確認可直接連線。網域分流所需的解析策略、節點網域解析及加密 DNS，應在基本連線穩定後再分別設定。

若改用 fake-ip，也要確保用戶端連往合成位址範圍的連線會被核心接管，並依應用程式相容性需求設定過濾項目。不要只切換 DNS 模式，卻讓合成位址流量繞過旁路由。

防火牆接管：區分 firewall4 與舊版規則系統

先執行下方唯讀命令，確認裝置使用的防火牆工具。OpenWrt 22.03 起官方預設改用 firewall4 與 nftables，但實際裝置可能採用不同韌體或經過修改，請以本機查詢結果為準。

command -v fw4
command -v nft
command -v iptables
nft list ruleset
ip -4 rule show
ip -4 route show table all

不要將網路上的 iptables 接管指令碼直接加入 firewall4 設定。即使系統提供相容命令，也要確認規則實際寫入哪套規則集，以及防火牆重新載入後是否仍然存在。TProxy 還需要相應的核心模組與使用者空間運算式支援，只有監聽連接埠並不足夠。

流量接管規則至少要處理四件事

1. 限制來源：首次只比對測試電腦 192.168.10.100，不要直接接管整個 LAN，更不要比對來自 WAN 的任意流量。
2. 先排除再接管：保留本機管理位址、區域網路目的位址，以及必要的廣播與多點傳送流量。IPv4 與 IPv6 的排除範圍必須分開規劃。
3. 比對流量入口：TCP Redir 導向 7892；TProxy 導向 7893，並設定相符的策略路由，將已標記的流量送至本機。
4. 避免迴圈：核心本身連往節點、DNS 與直連目的地的輸出連線，不能再次進入同一套接管規則。路由器本機的 OUTPUT 接管應另外規劃。

TProxy 常見設定需要搭配 fwmark、ip rule 與路由表中的本機路由。標記值、遮罩、規則優先順序及路由表編號，都要避開現有 VPN 與策略路由外掛使用的設定。沒有適用於所有裝置的安全固定編號，因此本文不提供可直接覆蓋正式環境的完整規則。

首次測試時，先關閉相關流量卸載選項並觀察計數器。硬體或軟體卸載可能改變後續封包的傳輸路徑；不能只憑第一條連線成功，就認定所有流量都已正確接管。

DNS 接管：將 dnsmasq 的 53 連接埠轉送至核心的 1053

建議先讓 dnsmasq 繼續負責區域網路的 53 連接埠，並讓 mihomo 只監聽回送位址 127.0.0.1:1053。如此可避免兩個程序爭用相同的監聽位址，也不必將核心的 DNS 連接埠直接開放給區域網路。

1. 在「網路」→「DHCP/DNS」中找到 DNS 轉送設定，新增 127.0.0.1#1053。這是 dnsmasq 指定伺服器連接埠的寫法，不是 YAML 語法。
2. 檢查其他轉送伺服器及 resolv 檔案的來源。若希望查詢只經過 mihomo，請停用從上游 resolv 檔案讀取其他伺服器的設定，避免與本機轉送並行。
3. 確認 mihomo 的上游 DNS 不是旁路由本身的 53 連接埠，否則會形成「dnsmasq → mihomo → dnsmasq」的解析迴圈。
4. 重新載入服務後，在測試電腦執行 nslookup example.com 192.168.10.2，並同時查看核心日誌與 DNS 監聽狀態。

電腦的 DNS 欄位只填 192.168.10.2，不要填 192.168.10.2:1053。一般作業系統的 DNS 設定通常不支援這種連接埠寫法；DHCP 的 DNS 選項也只會發送伺服器位址。

若 dnsmasq 與核心都啟用了快取，變更設定後也要考慮舊記錄。先指定伺服器進行查詢測試，再清除用戶端快取；不要把快取命中誤認為新的解析鏈已生效。

使用 procd 設定開機啟動：先管理程序，再設定流量接管

直接執行核心時，可使用 OpenWrt 的 procd 管理服務。將以下內容存為 /etc/init.d/mihomo。這是最基本的程序服務範例，不會自動安裝防火牆規則，也不會修改用戶端閘道。

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=99
STOP=10

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo
netstat -lnptu

確認監聽清單中有 7892、7893 與 127.0.0.1:1053。可用命令取決於韌體內附的工具；如果 netstat 不支援所需參數，可改用已安裝的 ss -lnptu 檢查。不要讓管理 API 監聽公網介面。

範例服務以系統預設權限啟動。透明代理與路由操作涉及系統權限，設定檔和服務指令碼應僅允許管理員修改。防火牆規則應透過相容於目前防火牆系統的機制持續載入，並明確規劃停止服務時如何解除接管；否則核心結束後，用戶端仍可能被導向沒有程序監聽的連接埠。

驗證順序：依序檢查路由、DNS、流量接管與遠端連線

1. 先測試基本路由：尚未啟用透明接管前，確認測試電腦以旁路由作為閘道時仍可正常上網。若此時連線失敗，應先修正轉送與回程路由。
2. 接著測試 DNS：明確查詢 192.168.10.2。若逾時，先檢查 dnsmasq、1053 連接埠監聽與解析迴圈；查得到 IP 不代表一定能連上對應網站。
3. 再測試 TCP 接管：在測試電腦上連線至 HTTPS 網站，查看相關防火牆計數器與 mihomo 連線日誌，確認來源位址、比對規則與最終策略一致。
4. 另外測試 UDP：使用確實需要 UDP 的應用程式，搭配 TProxy 計數器與連線日誌觀察。一般網頁能正常開啟，不代表 UDP 代理可用。
5. 檢查雙協定堆疊：分別測試 IPv4 與 IPv6。若 IPv6 仍直接經主路由連出，應明確規劃 IPv6 接管、DNS 發送與防火牆策略，不要將雙協定堆疊的行為當成偶發錯誤。
6. 最後測試重新載入與重新啟動：測試防火牆重新載入、核心重新啟動及整台裝置重新開機，確認沒有重複規則、DNS 可恢復，並且核心停止後有明確的復原方式。

依照問題現象排查，不要反覆更換節點

• 修改閘道後完全無法上網：優先檢查 IP 轉送、防火牆轉送、主路由出口與回程路由，不要先懷疑訂閱。
• IP 可連線，但網域無法開啟：檢查電腦實際使用的 DNS、dnsmasq 上游、核心 DNS 日誌及瀏覽器安全 DNS。
• 網頁正常，部分應用程式失敗：檢查 UDP、IPv6、規則比對結果與遠端協定支援，並分辨流量未被接管，還是已接管但連線失敗。
• 只有路由器本身無法連線：檢查 OUTPUT 規則與核心自身流量的排除設定，避免代理連線再次被接管。
• 重新開機後失效：檢查服務是否已啟用、相依檔案是否存放於永久目錄，以及防火牆是否重新載入對應規則。

擴大至全網之前，先記錄一台裝置的驗證結果：IP 位址、閘道、DNS、透明代理連接埠、命中策略與重新啟動結果。確認穩定後再調整 DHCP；租約不一定會立即更新，部分裝置需要中斷連線後重新連線。若要復原，先讓用戶端改回主路由閘道與原本的 DNS，再撤銷透明接管，最後停止核心，避免全網流量陷入無法使用的轉送路徑。