平台部署 預計閱讀 15 分鐘

路由器與旁路由部署 Clash 核心概覽：OpenWrt、樹莓派方案與 DNS 接管思路

整理主路由與旁路由兩種拓撲下直接執行 Clash 核心的完整思路，比較 OpenWrt 外掛與樹莓派裸機方案，並說明透明代理與 DNS 接管的注意事項。

先確認拓撲：主路由部署還是旁路由部署

將 Clash Meta（目前常用的核心名稱為 mihomo）放進家庭網路，與在電腦上執行桌面客戶端有明顯差異。桌面客戶端通常只處理本機流量；路由器方案則需要同時處理轉發、策略路由、DNS、IPv4 與 IPv6，並避免代理程式再次接管自身的上游連線。部署前先釐清資料路徑，比直接安裝外掛更重要。

方案一：Clash 核心執行於主路由

主路由直接負責撥號、DHCP、NAT、防火牆與透明代理。終端裝置的預設閘道自然指向這台設備，不需要逐台修改網路設定。以 OpenWrt 為例，路由器 LAN 位址可以是 192.168.10.1，DHCP 位址池為 192.168.10.100–192.168.10.249，用戶端閘道與 DNS 都由 DHCP 自動下發為 192.168.10.1。

  • 優點：流量入口統一，終端接入後即可套用規則，訪客網路與獨立 VLAN 也能分別控管。
  • 限制：代理、撥號、無線與 NAT 共用同一台設備的 CPU 與記憶體，設定錯誤可能影響整個區域網路。
  • 適合：已有充足效能的 x86 OpenWrt、小型軟路由，或四核心 ARM64 路由設備。

方案二：Clash 核心執行於旁路由

旁路由與主路由位於同一個 LAN。假設主路由為 192.168.10.1，旁路由為 192.168.10.2，旁路由自身的預設閘道仍指向 192.168.10.1。需要代理的終端裝置則將預設閘道與 DNS 設為 192.168.10.2。資料先進入旁路由，經透明代理判斷後，再由主路由連上網際網路。

這種單臂旁路由只有一個乙太網路介面，進站與出站流量會經過同一張網卡。千兆網路中的一次網際網路轉發會在該介面上產生雙向收發，但通常不會因此直接減半；實際瓶頸更多來自加密吞吐量、規則比對、USB 網卡品質與主路由回程路徑。

比較項目 主路由執行 旁路由執行
終端變更 通常不需要 需修改閘道、DNS 或 DHCP 下發設定
故障影響 可能影響全網出口 可將閘道切回主路由恢復
硬體選擇 受路由設備規格限制 可使用樹莓派、迷你主機或舊電腦
網路複雜度 轉發路徑直接 需檢查回程、DHCP 與 IP 轉發

如何選擇 OpenWrt 外掛與樹莓派裸機方案

OpenWrt 外掛方案會將核心、設定訂閱、規則更新、防火牆接管與執行記錄集中在同一個管理介面中。樹莓派裸機方案則通常直接執行 mihomo 二進位檔，再以 systemd、nftables 與 dnsmasq 組成完整鏈路。兩種方案的核心能力相近，差異主要在維護方式與故障定位的細緻程度。

OpenWrt 外掛方案

以 OpenWrt 24.10 系列與 OpenClash 管理介面為例，常見操作路徑是「服務」→「OpenClash」→「設定檔訂閱」，新增訂閱網址並設定更新時間；接著進入「服務」→「OpenClash」→「外掛設定」，選擇執行模式、DNS 接管方式與存取控制。不同外掛版本的選單名稱可能略有不同，但設定邏輯大致一致。

  1. 確認設備架構，例如 x86_64、aarch64_cortex-a53 或 mipsel_24kc，核心檔案必須與架構相符。
  2. 預留持久化空間。規則集、Geo 資料、記錄與多個設定檔可能佔用 80 MB 以上，只有 16 MB 快閃記憶體的舊設備不適合長期保存大量資料。
  3. 先以規則模式啟動，再分別測試 TCP、UDP 與 DNS；不要一次啟用所有實驗性選項。
  4. 在「執行狀態」或「除錯記錄」中確認設定解析完成、透明代理規則寫入成功，且 DNS 監聽連接埠沒有衝突。

外掛適合希望透過 LuCI 管理訂閱與存取控制的環境。升級 OpenWrt 前應記錄外掛設定、設定檔位置與自訂防火牆規則，因為防火牆 3 與防火牆 4 的底層實作不同。OpenWrt 22.03 之後的主流版本採用 firewall4 與 nftables，舊教學中的許多 iptables 指令不能直接照搬。

樹莓派或 Debian 裸機方案

樹莓派 4B、樹莓派 5，以及執行 Debian 12 的 ARM64 迷你主機，都可以擔任旁路由。建議使用 64 位元系統、有線網路連接埠與穩定電源。樹莓派 4B 的內建千兆網路連接埠適合一般家庭鏈路；若接上 USB 3.0 網卡，應確認晶片驅動穩定，並持續觀察丟包與重新連線記錄。

裸機方式可將 mihomo 放在 /usr/local/bin/mihomo，設定目錄設為 /etc/mihomo，透過 systemd 常駐執行。以下服務檔案展示必要結構，實際部署時還應建立專用使用者，並讓該使用者擁有設定目錄的讀寫權限：

[Unit]
Description=mihomo proxy core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

儲存為 /etc/systemd/system/mihomo.service 後，可依序執行 systemctl daemon-reload、systemctl enable --now mihomo 與 journalctl -u mihomo -n 100。寫入透明代理規則前，先執行 mihomo -t -d /etc/mihomo 檢查 YAML 語法。解析失敗時不要繼續寫入開機防火牆規則，否則可能出現流量已被重新導向、核心卻尚未監聽的斷網狀態。

透明代理：REDIRECT、TProxy 與 TUN 的差異

路由器部署的關鍵不是開放一個 HTTP 或 SOCKS 連接埠，而是讓不支援手動代理的電視、遊戲主機與 IoT 設備也能套用規則。常見實作包括 REDIRECT、TProxy 與 TUN。三者都需要正確排除區域網路位址、核心自身連線與代理伺服器位址，否則容易產生代理迴圈。

REDIRECT：主要處理 TCP

REDIRECT 會將經過防火牆的 TCP 連線重新導向至 mihomo 的透明代理連接埠，例如 redir-port: 7892。實作簡單，適合先驗證網頁與應用程式的 TCP 流量。它無法完整涵蓋所有需要保留原始目標資訊的 UDP 情境，因此語音、遊戲與 QUIC 可能仍需使用 TProxy 或 TUN。

TProxy：同時處理 TCP 與 UDP

TProxy 通常使用獨立連接埠，例如 tproxy-port: 7893，並依賴策略路由、封包標記與核心模組。防火牆先為流量設定 fwmark，再透過 ip rule 與本機路由表將資料交給 mihomo。UDP 透明代理、DNS 查詢與部分即時通訊對規則完整性的要求更高。

  • 必須排除回環位址、組播位址、區域網路網段與路由器管理位址。
  • 必須讓代理節點伺服器的連線直接通往上游，不能再次進入透明代理。
  • 應排除 mihomo 程序自身的流量，或透過路由標記區分已處理的封包。
  • 需要確認核心是否包含 TPROXY、策略路由與 nftables 的相應支援。

TUN：由虛擬網卡接收 IP 流量

TUN 模式會建立虛擬網路介面，由 mihomo 接收 IP 層流量。它在桌面系統上較常見，在旁路由上也可以使用，但仍需要轉發、路由與 DNS 相互配合。基本設定可能包含以下部分：

mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  strict-route: true

mixed-port: 7890 用於顯式 HTTP 與 SOCKS 代理測試；透明代理則使用 REDIRECT、TProxy 或 TUN 鏈路。管理介面繫結至 127.0.0.1:9090，可避免直接暴露給整個 LAN。若確實需要從其他設備存取控制介面，應透過防火牆僅允許管理網段，並設定控制器金鑰。

TUN 的 auto-route 與 auto-redirect 可減少手動規則，但不代表所有路由器環境都能直接啟用。OpenWrt 外掛通常已有自己的防火牆管理邏輯，再疊加核心自動寫入路由，可能造成重複接管。部署時應明確由外掛、啟動腳本或 mihomo 本身負責路由，只保留一套控制來源。

DNS 接管：避免洩漏、污染與解析迴圈

透明代理只能決定連線如何轉發，DNS 則決定網域名稱先解析成哪個位址。若終端裝置仍直接查詢主路由或電信業者的 DNS，規則可能只能看到目標 IP，網域規則的命中率會下降；如果 DNS 請求在代理與直連路徑間反覆重入，也可能出現網頁長時間等待、部分網域間歇性失敗等問題。

建議的資料路徑

旁路由可讓 dnsmasq 監聽 LAN 的 53 連接埠，再將請求轉發至 mihomo 的 127.0.0.1:1053；也可以透過防火牆將終端裝置發往其他 DNS 的 TCP/UDP 53 請求重新導向至本機。mihomo 的 DNS 模組再依據網域規則選擇直連解析器或代理解析器。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

default-nameserver 使用 IP 位址，主要用於解析 DoH 伺服器自身的網域名稱，避免啟動階段出現先有網域名稱還是先有 DNS 的依賴迴圈。nameserver 是實際的查詢入口。更複雜的設定還可透過 nameserver-policy 為指定網域選擇不同解析器，但應先確認基礎解析穩定，再增加策略。

fake-ip 與 redir-host 的取捨

fake-ip 會從保留位址池回傳暫時位址，mihomo 依據對應關係還原原始網域名稱，因此網域規則比對更直接。範例中的 198.18.0.1/16 屬於基準測試保留網段，通常不會與公網位址衝突。區域網路網域、印表機探索、NTP，以及少數依賴真實 IP 的應用程式，都可以加入 fake-ip-filter。

redir-host 回傳真實解析結果，路徑相容性較直觀，但在透明代理階段可能更依賴嗅探或 IP 規則。遇到區域網路設備探索失敗時，不應立即關閉全部 DNS 接管，可以先檢查目標網域名稱並新增精確的過濾項目。

IPv6 需要另外驗證

只接管 IPv4、卻繼續向終端裝置下發 IPv6 預設路由，可能讓支援 IPv6 的應用程式繞過既有策略。處理方式不是簡單刪除所有 AAAA 記錄，而是依網路能力選擇：完整代理 IPv6、讓指定 IPv6 網段直連，或在尚未準備好時停止向測試網段下發 IPv6 預設路由。至少應分別執行 A、AAAA 查詢，並測試一個僅支援 IPv4 與一個支援 IPv6 的網站。

旁路由部署步驟：從單一設備測試到全網接管

旁路由適合分階段上線。先讓一台電腦使用旁路由，再逐步擴展至獨立設備群組，比直接修改全網 DHCP 更容易定位問題。以下範例繼續使用主路由 192.168.10.1、旁路由 192.168.10.2。

  1. 固定旁路由位址：將 LAN 位址設為 192.168.10.2/24，預設閘道設為 192.168.10.1，避免位址落入主路由 DHCP 動態分配範圍。
  2. 啟用 IP 轉發：Linux 可檢查 sysctl net.ipv4.ip_forward，結果應為 1。需要 IPv6 轉發時，再另外檢查對應參數。
  3. 驗證一般轉發：先不要啟動 Clash，將測試電腦的閘道改為 192.168.10.2。如果此時無法連上網際網路，應先修復路由、NAT 或回程，不能將問題歸因於代理設定。
  4. 驗證顯式代理：啟動 mihomo 後，在測試電腦手動將 HTTP 或 SOCKS 代理設為 192.168.10.2:7890，確認節點、訂閱與規則均可正常運作。
  5. 啟用透明代理：先處理 TCP，再測試 UDP。觀察記錄中的入站類型、目標位址、命中規則與最終代理群組。
  6. 接管 DNS：將測試電腦的 DNS 改為 192.168.10.2，使用 nslookup 或 dig 檢查回應伺服器、耗時，以及 A、AAAA 結果。
  7. 擴大範圍：確認穩定後，在主路由 DHCP 中將指定終端裝置的閘道與 DNS 下發為旁路由位址，或透過 VLAN 僅接管一個測試網段。

測試時應記錄具體數值。區域網路到旁路由的有線延遲通常應低於 1 ms；若 DNS 首次查詢持續超過 2 秒，需要檢查 DoH 建立連線、上游路由與迴圈；規則切換後可連續進行 20 次解析與連線測試，確認沒有間歇性逾時。速度測試只能反映特定時間點的吞吐量，不能取代丟包、延遲與持續連線測試。

DHCP 下發的兩種方式

  • 全網下發：DHCP 選項 3 將預設閘道指定為 192.168.10.2，選項 6 將 DNS 指定為 192.168.10.2。適合旁路由已穩定執行的網路。
  • 依設備下發：為測試電腦、電視或遊戲主機建立靜態租約，只對這些設備分配旁路由閘道與 DNS。辦公設備與管理設備則繼續使用主路由。

部分家用主路由只允許統一下發閘道，不能依終端裝置個別設定。此時可以手動設定測試設備，或劃分獨立的訪客網路。不要同時使用重複 NAT、橋接與策略路由等多種方式修補同一個問題；鏈路層次越多，回程不一致就越難定位。

常見故障與檢查順序

終端裝置可存取旁路由，但無法連上網際網路

先停止 mihomo 與透明代理規則，只檢查基礎轉發。確認旁路由預設路由指向主路由、IP 轉發已啟用，且主路由知道如何返回終端網段。單臂旁路由通常仍處於同一個 /24 網段；若使用獨立子網，則需要在主路由新增靜態路由，或在旁路由執行來源位址轉換。

網頁可以開啟，但遊戲或語音失敗

這通常表示 TCP 路徑正常，但 UDP 未進入代理，或代理節點不支援所需的 UDP。檢查 TProxy 或 TUN 是否啟用、UDP 規則是否寫入、防火牆是否載入相關模組，並查看連線記錄中是否出現 UDP 入站。QUIC 使用 UDP 443，關閉瀏覽器 QUIC 只能用於定位問題，不能取代正確的 UDP 設定。

中國大陸網站繞路或區域網路設備無法存取

檢查規則順序。區域網路網段、路由器管理位址與私有位址應在兜底代理規則之前直連。規則會由上而下比對，末尾的 MATCH 會接收所有未命中的請求。若區域網路網域使用 .lan 或 .local，還應同步檢查 fake-ip 過濾與本機 DNS 轉發。

重新啟動後短暫斷網

可能是防火牆規則先載入，但 mihomo 尚未完成設定解析與 DNS 初始化。systemd 服務應等待 network-online.target，防火牆腳本也應在核心監聽連接埠可用後再接管流量。還要確認設定、Geo 資料與快取位於持久化儲存，而不是存放在重新啟動後會被清空的暫存目錄。

CPU 使用率高或吞吐量明顯下降

先區分加密效能、規則處理與記錄寫入。將記錄層級維持在 info，排查故障時再短暫切換至 debug；檢查是否啟用了大量正規表示式規則、持續連線嗅探或重複 DNS 查詢。千兆寬頻下，低頻雙核心路由器可能先達到單核心瓶頸，而記憶體使用量正常並不代表轉發效能充足。

部署結論：先確保路由正確，再擴展規則能力

OpenWrt 主路由部署的優勢是入口統一，適合硬體效能充足、希望集中管理全網策略的環境。OpenWrt 旁路由保留了 LuCI 與外掛管理能力，發生故障時也能將終端閘道切回主路由。樹莓派或 Debian 裸機方案提供更明確的 systemd、nftables 與記錄控制，適合願意維護 Linux 網路堆疊的使用者。

無論選擇哪一種方案，可靠的順序都是：先確認一般三層轉發，再驗證 7890 顯式代理，接著啟用 TCP 透明代理，繼續補充 UDP 與 DNS，最後處理 IPv6 與全網 DHCP 下發。Clash Meta 或 mihomo 只是資料路徑中的一個元件，真正決定穩定性的仍是閘道、回程、防火牆與 DNS 是否保持一致。

下載 Clash 客戶端