把OpenClash跑在OpenWrt 軟路由上，本質是把 Clash Meta（Mihomo）核心插進路由器系統裡，由 iptables / nftables、dnsmasq 以及可選的 TUN 介面一起把區網流量按規則分流。對零基礎用戶而言，真正的難點往往不在「點幾下菜單」，而在於設備與韌體是否匹配、拓撲是主路由還是旁路由、核心與依賴是否一次性裝齊。本文按「從刷好可用的 OpenWrt 到 LuCI App 裡訂閱更新成功」的真實順序寫，避免把 WAN、LAN、DNS 與閘道混成一坨。
先選場景：主路由還是旁路由
在開始下載任何 .ipk 之前，先畫清楚家裡的拓撲。主路由模式下，OpenWrt 設備直接撥號或接數據機，絕大多數終端的預設閘道就是它，OpenClash 掛在 LAN 出口即可統一劫持 DNS 與 TCP。旁路由（閘道旁掛）下，OpenWrt 並聯在交換機或主路由 LAN 口後面，常見做法是讓需要代理的設備把閘道改成旁路由地址，而 DHCP 仍由主路由發放；也可以反過來由旁路由管 DHCP，但這時要特別注意避免雙重 NAT 與地址段衝突。
旁路由還能細分為「僅閘道旁掛」與「僅 DNS 旁掛」等變體：有的用戶只把 DNS 指到 OpenWrt 上跑 AdGuard Home，再讓 OpenClash 接手上遊解析；也有用戶全程依賴 OpenClash 內建 DNS 模組。無論哪種，請在紙上寫出三段信息：LAN 網段（例如 192.168.1.0/24）、旁路由靜態 IP、主路由 LAN 地址。裝完 OpenClash 後若網頁突然打不開，優先回到這張草圖核對閘道與 DNS，比在 LuCI 裡亂勾選項更有效。
第二步：機型、分區與 OpenWrt 韌體
OpenWrt 不是單一鏡像，同一晶片不同版型也可能不通用。去 OpenWrt 硬體資料庫或你信任的韌體發行頁面，核對：Flash 大小是否足夠裝下後續核心與地理／離線資料庫（例如 Geo／GeoIP）、是否需要合入閉源無線驅動、當前主線版本與你計劃裝的 OpenClash 依賴是否相容（過舊的 OpenWrt 往往缺庫，過新的 snapshot 又可能還沒完全相容於某些 LuCI 套件）。
刷寫方式因廠而異：有的機型先用原廠恢復界面上傳 sysupgrade.bin，有的必須先 TFTP 救磚。本文刻意不寫「一鍵通用線刷命令」，原因很簡單——錯誤鏡像或中途斷電足以把設備送進維修臺。請完整閱讀針對你機型的教學，至少做到：備份原廠分區、確認是 factory 還是 sysupgrade 包、知道如何進 failsafe。若你暫時不想動分區，也可以先在 x86 軟路由或虛擬機裡練熟 OpenWrt 終端機與 LuCI，再上真機。
第三步：先把「乾淨的 OpenWrt」跑穩
剛刷完的 OpenWrt 建議先完成基礎網路：WAN 能拿到地址或撥號成功、LAN 能管理、系統時間與 NTP 正常、軟體包列表能更新。在 SSH 裡執行 opkg update 若連續失敗，多半是上遊鏡像不可達或 TLS 憑證鏈不全，先把這一條修好；否則後面 OpenClash 在核心與規則資料下載階段會反覆出現錯誤訊息。
順手檢查 /overlay 可用空間。OpenClash 會拉取 `/etc/openclash` 下的組態、核心二進位，以及可能很大的 GeoIP／ASN 資料庫。空間捉襟見肘時，更新會寫到一半失敗，LuCI 上表現為「進度條卡住」或「服務啟動失敗」。必要時刪除無用語言包、把日誌級別調低，或換更大 Flash 的機型。
第四步：安裝 OpenClash（LuCI App）與依賴思路
OpenClash 一般以 LuCI 應用程式 + 後端腳本 + 可替換核心的形式分發。獲取途徑可能是軟體源裡的 opkg install luci-app-openclash，也可能是作者 Release 頁提供的 .ipk 組合包。不同通道版本節奏不一致：請閱讀你使用渠道的「安裝說明」，核對最低 OpenWrt 版本、所依賴的 shell 工具、防火牆後端（fw3 還是 fw4）。
常見依賴族包括：coreutils、bash、curl、ca-bundle、dnsmasq-full 或相容的 DNS 方案、以及能支撐腳本下載校驗的工具鏈。若 LuCI 安裝後菜單裡是空白頁，經常是 luci-compat 或相關 Lua 依賴缺失。不要用「網上複製的一大串 opkg」盲目重裝，應對照錯誤訊息逐條補齊套件，否則容易把系統包管狀態攪亂。
核心：為什麼預設討論 Mihomo / Clash Meta
OpenClash 歷史上的 Premium 核心與當下的 Meta lineage 並存於各種舊貼中，容易讓新手困惑。簡言之：新用戶應優先跟隨發行版預設通道準備 Meta 核心，以獲得較新的協議與規則特性；在 LuCI 裡通常有「核心更新」「核心類型」或類似選項，按架構（aarch64_generic、x86_64 等）下載，若自動源失敗，可改用手動上傳與權限設定（chmod +x）。
核心與設定檔是一體兩面：訂閱裡的節點類型、規則裡的 GEOSITE / GEOIP 動作、以及 DNS 層的 fake-ip 行為，都依賴核心實現。若你匯入的設定檔要求 Meta 專有欄位，卻跑了過舊二進位，會直接解析失敗。遇到此類問題，先看執行日誌裡是否出現 unsupported 或欄位缺失提示，再決定是否升級核心或精簡設定。
第五步：LuCI 中首次拉起 OpenClash
打開 服務 → OpenClash（不同漢化可能略有出入），第一輪建議只做三件事：選好核心、開啟一次「更新訂閱」所需的下載通道、關閉所有花哨外掛級選項。例如 DNS 旁路、第三方面板、一鍵測速等，都可以等主路徑通了再開。
關注以下面板區塊（命名隨版本會變，但邏輯恆定）：
- 運作模式：
Redir-Host、Fake-IP、TUN與混合模式各有適用面；家庭主路由若希望透明代理，多數教學會走向 Redir 或 TUN，具體取決於你的韌體核心是否支援tun模組、以及你是否需要抓取部分 UDP。 - DNS 設定：錯位是最常見的「能 ping 不能上網」原因。若開啟
fake-ip，務必理解它與區網真實解析之間的差異，並避免在主路由上再疊一層不相容的「強制 HTTPS DNS」。 - 依離線地理資料進行區段略過／分流的相關開關：不同中文版介面上的標籤可能略有出入，你若看到與「略過／繞過大陸 IP」類似的敘述，通常都屬同一類對應。它會依賴較大型的規則集並對 CPU／Flash／記憶體尖峰要求高，效能不足的裝置建議別一次全載；可先沿用訂閱提供的精簡規則跑通路由，再逐步提高規則精細度。
第六步：訂閱接入與組態整併
在「組態訂閱」區域新增服務提供者給定的 訂閱 URL，名稱僅供辨識，更新間隔不宜過密以免碰到限流策略。順利拉回後，外掛通常會將遠端 YAML 或轉換結果併入主執行組態；若偏好手寫規則，亦可上傳完整設定檔，惟須評估路由器記憶體餘裕。
策略組與規則維護的通用原則可參考本站《Clash 完整設定教學》：路由器場景下額外記住兩點——儘量控制規則條數與定時更新頻率，以及留意日誌旋轉別把快閃記憶體寫穿。訂閱只是入口，真正決定「哪些流量走代理」的仍是規則與 DNS。
第七步：把 WAN、LAN、DNS 與旁路由對齊
主路由下，重點檢查 WAN 口 DNS 是否仍指向電信業者；若你希望整體走加密 DNS，應在 OpenClash 面板與 dnsmasq 轉發鏈之間建立一致邏輯，避免「客戶端以為用了路由器 DNS，實際劫持沒發生」。同時注意 IPv6：若上遊下發了 PD，而你沒有在 OpenClash 裡正確處理 IPv6 策略，會出現「測速 IPv4 正常、部分應用走 IPv6 掉線」的怪象。
旁路由下，務必在主路由上為旁路由設靜態 DHCP 綁定，防止地址漂移；需要代理的終端預設閘道指向旁路由，DNS 既可以也指向旁路由，也可以指向主路由再由旁路由劫持——兩路都要自洽。若你在主路由還跑著家長控制或企業準入，確保它們不會因為「閘道不是主路由自己」而把設備踢下線。
防火牆、硬體加速與效能預期
OpenClash 不是魔法：在百元級 ARM 盒子上強行開 TUN、全量 GEOSITE、並拉高併發連線，CPU 會瞬間打滿，表現為延遲飆升與斷流。若你追求「全家 4K 同時跑在代理鏈上」，硬體預算要前置，而不是只靠改兩個 UCI 選項。
部分韌體整合 Flow Offloading：與某些精細化流量劫持方案可能衝突。遇到更新韌體後突然失效，可把硬體加速逐項關閉做 A/B。日誌在 /tmp/openclash*.log 一帶（隨版本變化）以及系統核心日誌裡，善用 logread -f 比在論壇發問更快。
常見故障的快速排查順序
- 服務是否真的在跑？
/etc/init.d/openclash status與 LuCI 頂部狀態是否一致。 - 核心與架構是否匹配？升級韌體後有時需要重新下一遍核心。
- 訂閱能否在路由器上直接
curl拉到？若不行，優先修復 HTTPS 或時間同步。 - 規則模式是否誤設為整體對外，導致區內站點也繞遠路超時。
- 旁路由場景下，客戶端閘道與 DNS 是否與草圖一致。
- 關掉其它同類透明代理或廣告過濾套件，排除雙劫持。
常見問題（正文速查）
刷完機找不到 LuCI？ 可能尚未安裝 luci 對應主套件群或防火牆擋住了 80 埠；先用 SSH 檢查 uhttpd 與監聽地址。
更新離線對應的地理資料（Geo／GeoIP）很慢？ 換成可達的鏡像來源，或改在離峰時段更新；必要時將檔案手動複製進指定路徑並重新校對校驗和。
想與桌面共用同一套 YAML？ 可以互相參考，但路由器側請刪減巨型規則、關掉不必要的面板與實驗特性，並實測記憶體峰值。
為什麼仍建議在路由器之上了解 Clash 桌面客戶端
路由器方案的最大優點是「完成一次組態，全屋終端預設受益」；但它的缺點是排障門檻高、與硬體和核心綁定緊。不少閉源「軟路由一鍵包」把訂閱與規則封在黑盒裡，出問題時你只能重裝鏡像；而某些老舊發行版長期不跟進 Meta 特性，訂閱明明在電腦上能用，上了路由器卻解析失敗。相比之下，長期在維護的 Clash 系桌面客戶端（配合開放的 YAML 工作流）讓你能在本機先看懂日誌、調好策略組與 DNS，再把成熟組態縮影遷移到 OpenWrt；這種「先在桌面驗證，再上軟路由放大」的路徑，往往比第一次就對著 LuCI 盲勾更省時間。若你更常帶著筆記本在行動環境對外連線或跨區取用服務，僅仰賴家用路由器並不足以涵蓋所有終端情境。
如果你正在尋找一套跨平臺一致、規則結構清晰、社群資料豐富的代理工具，不妨在把 OpenClash 跑穩的同時，在電腦或手機上裝好同一生態的 Clash 客戶端做對照學習；兩邊共享同一套關鍵詞與組態思維，維護成本會低很多。