許多使用者在手機與電腦上已熟悉單機安裝 Clash 客戶端，但一旦家庭成員裝置變多、或希望電視盒、平板、訪客網路也沿用同一套規則與節點策略，逐台設定就顯得冗長且難以統一維護。此時把OpenWrt 軟路由或迷你主機放在區域網路中擔任旁路由，並在裝置上跑 Clash Meta（Mihomo），即可透過閘道模式讓內網流量先經過旁路由，再搭配透明代理與 DNS 導向，達成「免在每台裝置裝客戶端」的體驗。本篇聚焦拓撲規劃、閘道與透明代理的觀念銜接、以及區網分流的實務注意事項；若您需要的是單機 Linux 上以命令列啟用 TUN，可另參考站內的 Linux Clash 教學，兩者互補而不重複。
一、為什麼選旁路由，而不是直接換掉主路由？
實務上常見兩種情境：一是電信業者提供的光纖數據機／Wi-Fi 一體機已能穩定撥號，您不想動原有設定；二是主路由仍負責家長控制、訪客 SSID 或公司 VLAN，只想外加一層可程式化的出口策略。旁路由的作法，是把 OpenWrt 設備接到主路由的區網內，取得一組固定區網位址，之後由您決定「哪些裝置要把閘道指到旁路由」。這樣做的好處是回滾簡單：出問題時把客戶端改回自動取得或指回主路由即可恢復上網，不必整屋重設。
與「整機取代主路由」相比，旁路由的取捨在於：您需要清楚 DHCP 由誰發放、以及預設閘道與 DNS是否一致指向旁路由。只要這兩件事在拓撲圖上畫清楚，後續 Clash 規則才有穩定的流量入口可依附。
二、拓撲與位址：先畫出「誰是誰的閘道」
一個典型家庭拓撲如下：主路由對外撥號或 DHCP，區網網段例如 192.168.1.0/24；OpenWrt 旁路由的 WAN（實際上接到區網交換器或主路由 LAN）取得 192.168.1.2，並關閉與主路由衝突的 DHCP 伺服器，除非您刻意要讓旁路由對某一子網單獨發位址。多數入門情境會選擇仍由主路由發 DHCP，只在需要走代理的裝置上手動或透過 DHCP 靜態指派，把預設閘道設為 192.168.1.2，DNS 亦指向旁路由或可信的上游。
若您希望「全屋預設都走旁路由」，則可把主路由的 DHCP 選項中，將預設閘道與 DNS改為旁路由位址；此時務必確認旁路由本身能穩定轉發至主路由、且 Clash 異常時仍有繞過或直連規則，避免整屋斷線。進階使用者亦可能採單臂路由或多介面拓撲，本篇以常見雙機區網為例，觀念可類推到其他接法。
三、OpenWrt 上部署 Clash Meta：圖形外掛與核心分工
OpenWrt 生態中，常見做法是透過 Luci 外掛（例如社群熟悉的 OpenClash 類方案）封裝訂閱更新、核心下載與防火牆規則注入；底層仍多為 Mihomo／Clash Meta 核心讀取 config.yaml。無論您使用哪種前端，請把握三件事：核心版本與訂閱格式相容、設定檔路徑與服務啟動順序正確、以及日誌可讀以便對照規則命中。若您想先建立規則、DNS 與 Provider 的全貌，建議搭配閱讀 Clash Meta 配置指南，再把同一套邏輯搬到路由器上。
硬體方面，旁路由 CPU 與記憶體會同時承受NAT、加密代理與規則運算；若節點協議較重或同時在線裝置多，請預留餘裕。儲存空間須容納規則集快取與訂閱檔，並留意長期寫入對快閃的影響，可將快取目錄掛到外部儲存或記憶體檔案系統（依裝置與套件支援而定）。
四、閘道模式：讓區網流量「先找旁路由」
閘道模式在此指的是：區網客戶端把預設閘道設為旁路由 IP，使得非區網直連目標的封包會先送到旁路由，再由系統轉送。對 Clash 而言，這提供了集中入口：不論是瀏覽器、遊戲主機還是 IoT，只要走預設路由，就有機會進入本機的透明代理鏈。
實務上請同步檢查IPv6：若區網同時啟用 IPv6 且客戶端優先走 v6，可能繞過您為 IPv4 設計的閘道與 DNS。可選擇在旁路由或主路由上對策略性停用、或為 v6 規劃對應轉送與 DNS，避免「以為走了代理，實際仍從主路由直出」的落差。
五、透明代理：為什麼光有閘道還不夠？
僅設定閘道，客戶端應用仍可能不依 HTTP 代理環境變數行為；因此要讓「沒設定代理程式」的裝置也能被規則接管，需在旁路由上啟用透明代理（常見實作為 iptables／nftables 將流量導向本機 Clash 的紅色連接埠或 TPROXY）。Clash Meta 在路由器場景常與 tun 或透明轉發搭配，重點是避免迴圈：本機管理介面、區網鄰居與內網服務應列入直連或繞過清單，否則管理後台可能無法開啟。
以下為概念性防火牆思路（實際鏈名與連接埠請依您使用的外掛與核心為準）：
# Concept only — chains and ports depend on your OpenWrt / Clash build
# - Mark LAN client traffic toward Clash redir port
# - Exclude router management IP and RFC1918 targets if needed
# - Match UDP for DNS or TPROXY when using advanced setupsDNS 部分，若客戶端仍向主路由或公網 DNS 查詢，可能出現分流與解析不一致。常見作法是在旁路由提供DNS 轉發或劫持，讓查詢進入 Clash 的 dns 區塊，與 fake-ip、nameserver-policy 等設定對齊；細部語法可再對照 規則語法專文 中的思路，把「網域→規則→出口」串起來。
六、全家裝置分流：用規則表達「誰走哪條路」
當流量已進入 Clash，分流可透過 RULE 模式下的網域、地理與規則集完成。家庭場景常見需求包括：串流服務走特定區域節點、遊戲或金融網站直連減少延遲、以及將 AI 或開發者站點導向穩定出口。您可在 proxy-groups 中建立策略組，並依 rule-providers 維護長清單，減少手動逐條維護的成本。
若希望裝置級差異（例如家長手機與兒童平板不同策略），可在上游訂閱或本機規則中，以來源 IP／MAC 對應不同策略組的思路處理（實際欄位依核心與版本支援為準）；較輕量的做法則是固定 DHCP 指派，讓特定 IP 永遠對應特定裝置，再在規則裡針對該 IP 分流。這比要求每位使用者安裝客戶端更符合「家庭閘道」的定位。
七、與主路由協同：NAT、埠轉發與回連
旁路由通常再經主路由對外，需注意雙層 NAT對遊戲連線、P2P 或遠端存取的影響。一般網頁與串流多可正常運作；若您需要從網際網路連回家中服務，請在主路由設定埠轉發時，目標指向正確的內網主機，並理解封包實際經過的跳數。Clash 規則中的直連與本機繞過亦應涵蓋區網管理與印表機等裝置，避免誤轉發造成異常。
八、常見問題與排查方向
1. 部分裝置正常、部分不走代理：檢查該裝置的閘道與 DNS 是否真為旁路由；檢查是否使用 IPv6 繞路；檢查是否固定了舊的 DNS。
2. 能開網頁但串流或 App 異常：對照日誌中規則命中與 DNS 回應；嘗試為相關網域調整策略組或直連；確認時間與憑證是否正常。
3. 旁路由管理後台打不開：多為透明代理或路由迴圈，請將路由器管理 IP、區網段列入直連／繞過，並檢查防火牆鏈是否誤轉發本機流量。
4. 整體速度不如預期：評估硬體解密能力、節點頻寬與線路品質；必要時改為較輕協議或分流減少全量加密負載。
九、結語：把「單機經驗」收斂成「家庭出口」
OpenWrt 旁路由搭配 Clash Meta，本質上是把您在桌面與手機上累積的規則思維，搬到區網邊界：閘道決定誰把流量交給您，透明代理與 DNS 決定未裝客戶端的裝置是否仍能被規則覆蓋，策略組與規則集則決定全家裝置分流是否長期可維護。相較於每台裝置各自訂閱與更新，閘道式部署在一致性與故障還原上通常更勝一籌；若您同時需要筆電外出獨立使用，仍可保留單機 Clash 客戶端作為補充。
若您希望先取得適合各平台的 Clash 用戶端與整理好的下載入口，再與家中路由器方案並行規劃，歡迎造訪本站下載頁；集中取得安裝包與版本脈絡，能減少從零散來源拼裝所造成的相容性問題。