1 為何選「路由器級」透明代理
在單一裝置上安裝 Clash 用戶端，解的是該裝置的瀏覽器、應用程式與系統代理需求；但家中還有大量無法或不方便裝 App的設備：智慧電視、機上盒、遊戲主機、掃地機器人韌體更新等。若每一台都要手動指向 SOCKS／HTTP 代理，維護成本極高，也容易漏設定。把代理與規則引擎搬到路由器，並以透明代理方式攔截轉發，客戶端通常無需感知代理存在，就能讓 TCP／UDP（視模式與核心能力而定）依規則決定直連或走節點，這正是「區網全局代理」在實務上最常指涉的情境。
OpenClash是 OpenWrt 生態中圍繞 Clash 核心（含 Mihomo／Clash.Meta分支）整合度最高的 LuCI 外掛之一：提供訂閱管理、規則與策略組編輯、執行模式切換、日誌與連線檢視等，對已熟悉 YAML 概念的使用者相對友善。相較於在伺服器裸跑核心，路由器方案多了硬體效能、散熱、韌體相容與無線驅動等變數，因此本文會反覆強調「先釐清拓樸與 DNS，再談節點速度」，避免一開始就陷入單一測速數字。
若您手邊訂閱仍為非 Clash 格式，可先參考訂閱轉換完全指南，把機場連結整理成相容的 YAML，再匯入 OpenClash；規則集與 Rule Provider 的觀念則可延伸閱讀ACL4SSR 規則訂閱配置詳解，與路由器端設定互相呼應。
2 拓樸：主路由、旁路由與 DHCP 角色
透明代理要生效，前提是流量會經過執行 OpenClash 的那台設備。常見兩種拓樸：第一種是單一路由器直連數據機或光貓，OpenWrt 本身就是區網閘道與 DHCP 伺服器，OpenClash 在本機轉發，概念最直覺。第二種是旁路由：原有 ISP 或廠牌路由器繼續負責撥號與 Wi‑Fi，另有一台 OpenWrt 以區網內的一個 IP存在，您讓特定裝置的「預設閘道」或「DNS」指向旁路由，或僅在主要路由器上為特定裝置設定靜態路由，使流量繞經旁路由上的 Clash。
旁路由模式的關鍵在於誰發 DHCP、誰是預設閘道：若兩台設備同時開 DHCP，容易造成重複分配 IP或閘道混亂。實務上多數家庭會選擇「主路由關閉 DHCP、全權交給旁路由」，或「主路由仍發 DHCP，但將閘道與 DNS 指到旁路由」，兩者皆可，但只能採用一套一致邏輯，並在調整後重啟客戶端網路或釋放租約，否則會出現「部分裝置走代理、部分直連」的假性故障。
3 OpenWrt 與 OpenClash：定位與期待
OpenWrt是針對嵌入式路由器的開源 Linux 發行版，提供套件管理與防火牆框架；OpenClash則是在其上以 Shell 與 LuCI 介面包裝 Clash 核心的專案，負責下載核心、合併設定檔、啟動服務與套用 iptables／nftables 規則（依版本與核心而定）。您可以把 OpenClash 理解為「讓路由器也能跑與桌面類似的策略路由與規則鏈」，但實際轉發能力仍受 CPU、是否硬體卸載（offload）、以及是否開啟 TUN 等因素影響。
不同機型與韌體分支（穩定版、快照版、第三方編譯）在套件名稱、核心 libc、核心模組上可能有差異；安裝前請先確認剩餘儲存空間與記憶體，並優先查閱您所用 OpenClash 版本與 OpenWrt 大版本對應的說明。本文不綁定特定下載鏡像，避免連結過期；請以專案 Release、套件倉庫或可信社群維護的教學為準，並在更新韌體前備份設定。
4 安裝、磁碟空間與依賴套件
在 LuCI「系統 → 軟體」或命令列中安裝 OpenClash 時，常會一併拉入 DNS、iptables／nft 相關元件與核心二進位檔。若路由器使用小型 Flash，可能需要外接 USB 儲存並把 /overlay 擴充後再裝；否則容易在解壓核心或寫入規則快取時空間不足。建議預留數十 MB 以上可用空間給訂閱快取、GeoIP 與規則集，長期運行較穩定。
安裝完成後，先在服務是否成功啟動、LuCI 頁面是否可開啟兩點驗證；若核心下載失敗，多半是網路連線、時間不同步（TLS 憑證驗證失敗）或儲存空間不足。時間同步可檢查 NTP 與時區設定，這在之後訂閱 HTTPS 更新時同樣重要。
5 訂閱、設定檔與核心選擇
OpenClash 通常以訂閱網址定期拉取遠端 YAML，再與本機覆寫合併。請在介面中為每條訂閱命名清楚，並設定合理的更新間隔，避免過短觸發機場頻率限制。若機場提供多個訂閱（專線、家寬、內容解鎖），可善用策略組把不同用途拆開，並在 Rule 模式下讓規則決定落入哪一組。
核心方面，社群常見 Mihomo（Clash.Meta）與原版 Clash 系列的分支差異；功能集合、TUN 能力與規則語法支援度可能不同。選定後請前後一致地檢查規則與特性是否相容，避免混用僅 Meta 支援的關鍵字卻在舊核心上執行。初次上線建議以較保守的規則集開始，確認區網基本連線與 DNS 正常後，再逐步加入細緻分流。
6 透明代理：Redir、TUN 與「誰被接管」
「透明」在此脈絡指客戶端無需手動設定系統代理，路由器以防火牆規則將符合條件的流量導向本機 Clash 監聽埠。實作上可能使用Redir類型轉發、TUN虛擬網卡、或依版本組合的混合方案；差異在於哪些流量可被攔截、與UDP／遊戲封包的相容程度，以及對路由器 CPU 的負擔。
一般瀏覽與應用程式 HTTPS 流量，在規則與 DNS 對齊後大多可預期行為；但部分裝置會使用硬編碼 DNS或 QUIC，導致「看起來像沒走代理」。遇到此類情況，需要回到DNS 劫持／轉發策略與是否允許 UDP 相關選項，逐步縮小範圍，而不是先更換節點。
7 DNS、FakeIP 與防洩漏思路
路由器上的透明代理幾乎永遠與 DNS綁在一起：若客戶端仍向 ISP DNS 查詢，可能出現「規則以為要代理某網域，但解析結果卻不利於匹配」的錯位。Clash 系常見的 FakeIP與本機 DNS 監聽，目的是讓網域—策略—出口在同一條邏輯鏈上完成；細節與 YAML 層級設定可對照徹底防止 DNS 洩漏：Meta 核心 DoH + FakeIP 最佳實踐，再把觀念對應到 OpenClash 介面中的對應選項（實際欄位名稱隨版本而異）。
實務上建議在變更 DNS 模式後，用區網內手機或筆電以固定測試站交叉驗證：同時觀察路由器連線日誌與客戶端解析結果，避免只依賴單一「DNS 洩漏測試網站」截圖就下定論。
8 旁路由組網時最容易踩雷的三件事
第一，閘道與 DNS 是否一致指向旁路由：只改 DNS 而不改閘道，或反之，都會造成「部分 App 走代理、部分直連」。第二，主路由與旁路由的區段是否衝突：例如雙 NAT 下的連接埠轉發、UPnP、遊戲主機對戰等，需要額外評估；若您的主機遊戲仍以手動 HTTP 代理為主，亦可參考Switch／PS5 區網代理閘道教學理解兩種路徑的取捨。第三，硬體轉發是否與流量特徵衝突：某些晶片在開啟特定 offload 時與自訂規則不相容，除錯時可暫時關閉 offload 做對照測試。
9 驗證步驟與除錯順序
建議以由近到遠的順序排查：先確認 OpenClash 服務與核心行程正常、本機可解析訂閱；再在路由器上測試本機 curl 或內建工具連線；最後才用區網客戶端訪問測試站。若只有特定裝置異常，優先檢查該裝置是否使用私人 DNS、VPN 描述檔或其他加速器；若全屋異常，則回到閘道、DNS 與防火牆規則。
- 連線日誌：觀察規則命中與策略組是否與預期一致，避免只看節點延遲。
- 分層測試：先 Rule 再 Global 做對照，確認問題在規則還是節點。
- 時間與憑證：訂閱 HTTPS 更新失敗時，先排除系統時間錯誤。
- 硬體負載：CPU 長期頂滿可能導致斷流，需降規則複雜度或升級設備。
10 與「電腦當閘道」相比：何時升級到路由器
讓桌上型電腦或筆電開 Clash 並以 Allow LAN 分享給主機或電視，是門檻較低的起手式，缺點是電腦必須開機、睡眠即中斷，且無線覆蓋與防火牆規則較難做到全家一致。當您希望全天候、低維運地讓區網裝置共享同一套規則，並願意投入硬體與學習 OpenWrt，路由器透明代理會是更「一次到位」的方向；若您已在伺服器或 VPS 上跑過 Mihomo，亦可延伸閱讀Linux 安裝 Mihomo 與 systemd，對照守護行程與設定檔思路。
相較於僅依賴單一裝置上的封裝工具，Clash／Mihomo 生態的可視化規則、策略組與訂閱管理，在路由器與桌面之間可以共用同一套方法論：差別主要在部署位置與除錯工具。欲在電腦上先熟悉介面與訂閱，可從本站下載頁選擇對應平台，再與本文路由器方案互相印證。
11 總結
在 OpenWrt 上使用 OpenClash 實作透明代理，本質是把 Clash 的規則與策略能力搬到區網閘道：手機、電視、遊戲主機才能在不逐台設代理的前提下，盡量共用同一套分流邏輯。成功的關鍵往往不是「哪一個節點最快」，而是拓樸是否單一且一致、DNS 是否與規則對齊、以及模式與硬體負載是否匹配。當旁路由、IPv6、硬體 offload 與 QUIC 等變數交錯時，請用可重現的對照實驗縮小範圍，會比頻繁更換訂閱或盲目套用別人的完整設定檔更穩健。
若您同時在 Windows、macOS 或 Linux 上使用圖形化 Clash 用戶端，整體體驗會比「路由器與電腦各用一套互不相通的邏輯」更容易維護；在相同節點與規則條件下，Clash 生態的分流可視化與多設定檔管理，往往也比零散 App 更容易沿用。欲取得與站內教學一致的桌機版本，建議從本站下載頁開始選擇平台。
