OpenClash 软路由配置指南 2026：OpenWrt + 全屋分流实战
在家里给每台设备单独装代理客户端，头两台还算省事，设备一多就会失控：电视盒子和游戏机根本装不了客户端，智能家居设备只认网关，访客的手机总不能逐台帮忙导订阅，十几台设备各自维护一份节点列表更是灾难。软路由的思路是把代理从设备层挪到网络层——一台常开的小设备坐在网关位置上，全屋流量经过它时按规则自动分家：国内的直连、国外的走代理、广告直接拦掉，下游设备什么都不用装。
OpenClash 是这条路线上生态最成熟的方案。它跑在 OpenWrt 上，底层是 Clash 系内核，订阅、策略组、规则集都与单设备客户端相通。这篇指南不按菜单顺序逐项念设置，而是按真实的部署路径走：先定拓扑，再装对版本，然后导入订阅、理顺规则与 DNS，最后逐台验证全屋设备。单设备客户端与软路由怎么分工，可以先看 Clash 客户端横向对比 2026 再决定要不要折腾这一趟。
一、先定拓扑：主路由还是旁路由
拓扑选错，后面每一步都在还债。两种拓扑的区别不在性能参数，而在前提条件和出错时的波及范围。
| 对比项 | 旁路由 | 主路由 |
|---|---|---|
| 谁负责拨号 | 原主路由不变 | 软路由自己拨号 |
| 网口要求 | 单网口即可 | 至少两个网口（WAN/LAN 分开） |
| DHCP 归谁管 | 主路由（需改下发参数）或逐台手设 | 软路由 |
| 出错影响面 | 只影响走了旁路由的设备，改回网关即恢复 | 全家断网，直到修好 |
| 典型设备 | 单网口 ARM 盒子、二手 x86 | 双网口以上 x86 小主机 |
选旁路由的前提有两个：一是你能登录主路由后台改 DHCP 设置（或者愿意逐台设备手动指定网关），二是设备本身性能不需要承担全屋 NAT。选主路由的前提更硬：软路由至少双网口、你愿意在调试期承受全家断网、并且清楚拨号账号与光猫桥接怎么配。没有把握时先做旁路由——它最大的价值是可退：把设备网关改回主路由，一切复原，试错成本几乎为零。
设备形态顺带说清：x86 小主机网口多、性能富余，主旁通吃，还能顺带跑别的服务；斐讯 N1 这类二手 ARM 盒子便宜省电，但单网口决定了它只能做旁路由，规则开太多时处理器会先到瓶颈；华硕等路由器刷机是零新增设备路线，梅林固件下的玩法见 梅林固件 Clash 配置，各固件平台的取舍见 固件平台与软路由选型介绍；用 PVE/ESXi 把 OpenWrt 跑在虚拟机里同样可行，插件与 iStore 的实践可参考 OpenWrt 插件与 iStore 实践，只是要留意虚拟网卡的性能损耗，有条件就直通物理网卡。
二、部署前检查清单
动手之前逐项确认，缺哪项就先补哪项。这份清单里任何一条没落实，都会在后面变成一个具体的故障。
| 检查项 | 要确认什么 |
|---|---|
| 设备架构 | 记下 CPU 架构（x86_64 / arm64 / armv7），后面下内核要一一对应 |
| 存储与内存 | 系统分区有足够空间放内核与 GEO 数据；内存小的盒子别预设加载全部规则集 |
| 主路由权限 | 能登录主路由后台，能改 DHCP 的网关与 DNS 下发项 |
| 订阅形态 | 手里的订阅是 Clash 格式；只有 V2Ray 链接的话先找机场要 Clash 订阅或做转换 |
| 原网络参数 | 抄下主路由 IP、DHCP 地址池范围、现有 DNS，改坏时照单恢复 |
| 备用上网 | 留一条不依赖软路由的上网通道（手机热点即可），断网排查时用来查资料 |
| 电源与散热 | 常开设备供电稳定、通风正常，二手盒子的电源适配器别将就 |
| 系统时间 | 设备时间大致准确；时间偏差过大会让订阅拉取和证书校验莫名失败 |
三、装对版本：固件、插件、内核三件套
OpenWrt 固件分三类来源：官方版本最干净、更新最及时，代价是插件和依赖都要自己装； iStoreOS 这类国内发行版自带软件中心，对新手友好；第三方预编译版预装了常用插件，省事但必须认准可信来源——固件是全屋流量的入口，来路不明的固件没有省事可言。已经刷好固件的跳过这一层，直接装插件：
# 更新软件源后安装 OpenClash，依赖会一并拉取
opkg update
opkg install luci-app-openclash用 iStoreOS 的话在应用商店里搜 OpenClash 一键安装即可，效果一样。装完插件只完成了三分之一：OpenClash 本体是管理壳，真干活的是内核，还要配上 GEO 地理数据。进服务菜单的版本更新页下载内核——原来的 Clash 内核生态已经整体迁移到 Meta（mihomo）内核，不同版本的菜单里这一项叫法与位置略有出入，以 OpenClash 官方仓库与你的固件版本说明为准。下载时最常见的错是架构对不上：x86 机器下 arm 的内核、armv7 与 arm64 混用，都会直接无法启动，下之前回头看一眼检查清单里记下的架构。
# 内核文件应位于 core 目录且带执行权限
ls -lh /etc/openclash/core/clash_meta
# 查看服务状态
/etc/init.d/openclash status内核拉取失败多半是设备当时还没有可用的出国线路。可以先在电脑上从官方 Releases 下载与架构对应的内核文件，手动上传到 /etc/openclash/core/ 并赋予执行权限，再回面板确认状态。GEO 数据（GeoIP、GeoSite 等）是规则集判断域名与 IP 归属的依据，顺手在同一页更新到最新，缺了它分流规则等于没有地图。
除了 OpenClash，OpenWrt 上还有 Passwall、SSRPlus+ 等同类插件。选 OpenClash 的理由不是它功能最多，而是 Clash 订阅与规则集的生态最完整、社区资料最全；偏好更底层轻量方案的可以看 Sing-box 完整教程 2026，两条路线不必叠加安装。
四、接线与网络参数：旁路由的三件事
以旁路由落地为例。软路由这边要做的只有三件事：给它一个与主路由同网段、不与任何设备冲突的 LAN 地址；关掉它自己的 DHCP 服务器（两台 DHCP 同网段必然抢地址、发冲突参数）；用网线把它的网口接到主路由的 LAN 口。
# 旁路由模式示例：LAN 地址改为 192.168.1.2，关闭 DHCP
uci set network.lan.ipaddr='192.168.1.2'
uci set dhcp.lan.ignore='1'
uci commit network
uci commit dhcp
/etc/init.d/network restart
/etc/init.d/dnsmasq restart软路由就位后，要让流量真正经过它。做法有两档：全屋自动生效，是在主路由的 DHCP 设置里把默认网关与 DNS 都改填旁路由的地址，设备重新连网后自动走新网关；逐台手动，是在个别设备的网络设置里单独改网关，只让电视、游戏机这几台走旁路由，其余设备维持原状。起步阶段更建议后者或先小范围试点：一两台设备验证无误后，再放开到全屋，万一参数有误，影响面可控。
走主路由拓扑的把这一节反过来理解：软路由 WAN 口接光猫拨号、自己开 DHCP，原来的无线路由器退到 AP（桥接）模式只负责发 Wi-Fi，不要让两台设备同时做 NAT，双层 NAT 会让端口映射和游戏联机平白多一堆问题。
五、导入订阅，选对配置文件
在 OpenClash 的配置订阅页粘贴机场给的 Clash 订阅地址，更新配置，面板会把节点、策略组与规则一并拉下来，再到运行状态页启动服务。第一次启动后别急着改任何东西，先确认默认状态下能正常上网——后面所有调优都要有一个可回退的基线。
底层配置是一份标准 Clash YAML，关键区块就五处：监听端口、运行模式、DNS、节点列表、策略组与规则。手工维护时记住一条原则：不要直接改订阅生成的配置文件，它每次更新都会被覆盖；自己的调整走面板的覆写（配置覆写）通道，那一层才是给你留的。自建节点也能并进来——用 3X-UI 面板自建代理教程 搭的节点可以作为机场之外的保底线路，多订阅在面板里添加后会合并展示，或者用订阅聚合工具先合成一条再导入。
port: 7890
socks-port: 7891
allow-lan: true
mode: rule
log-level: info
proxies:
- name: "节点-A"
type: vless
server: example.com
port: 443
uuid: xxxx-xxxx
tls: true
proxy-groups:
- name: "PROXY"
type: select
proxies: ["节点-A", "节点-B", "自动选择"]
rules:
- "DOMAIN-SUFFIX,cn,DIRECT"
- "GEOIP,CN,DIRECT"
- "MATCH,PROXY"六、规则与分流：先懂匹配顺序，再谈规则集
分流的全部逻辑浓缩成一句话：规则从上往下逐条匹配，命中第一条就执行、不再往下看，最后一条 MATCH 是没人认领的流量的兜底去向。理解这条之后，很多「为什么这个站走了代理」的疑问都能自答——不是规则写错了，而是顺序里它先被别的规则认领了，或者压根没被认领、落进了兜底。
策略组是规则指向的目标，常见四种类型各管一件事：
| 类型 | 行为 | 典型用途 |
|---|---|---|
| select | 人工指定用哪个节点或下级组 | 总出口，手动拍板 |
| url-test | 周期性测速，自动用延迟低的 | 日常自动选择 |
| fallback | 按顺序试，第一个可用的顶上 | 流媒体等怕断的场景 |
| load-balance | 把连接摊到多个节点上 | 大流量下载 |
家庭场景的稳妥结构是三层：总出口用 select，里头放一个 url-test 的自动选择组兜底日常流量，再给流媒体单开一个 fallback 组指向解锁能力好的节点，国内流量则由规则直接送 DIRECT。规则本身不要手写几千条，用规则集：社区维护的规则数据按类别打包——国内域名与国内 IP 段、广告域名、流媒体各平台域名——在规则管理里按需勾选、定期更新即可。全勾只会拖慢小盒子，按家里实际用的服务选。
运行模式三档分清场合：rule 是日常模式；global 让全部流量走代理，只适合定位问题时临时开五分钟；direct 全部直连，是排查时用来确认「问题在不在代理这一层」的对照组。长期开着 global 等于放弃了分流的全部意义。
七、DNS：全屋分流最容易翻车的一环
DNS 值得单独一章，是因为解析走错会同时引发三种症状：查询泄露给运营商、流媒体判定地区错误、国内服务被绕远路。它不像断网那样显眼，往往是「能用但处处别扭」的根源。
内核的解析模式有两种：
| 模式 | 工作方式 | 长处 | 短处 |
|---|---|---|---|
| fake-ip | 给域名分配一个虚拟 IP 段内的假地址，连接时由内核接管还原 | 解析不外泄、判断归属最准 | 极少数老旧应用对假地址不适应 |
| redir-host | 用真实解析结果，靠路由规则把流量送进代理 | 兼容性宽松 | 配置稍有错位就泄露真实查询 |
推荐 fake-ip 并做分流解析：国内域名交给本地 DNS 就近解析，国外域名交给经代理链路出去的加密 DNS，两边各走各的路，运营商既看不到你查了什么，国内服务也不会因为解析到了海外地址而变慢。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- https://1.1.1.1/dns-query
fallback:
- https://8.8.8.8/dns-query三个高频坑提前点名。其一，设备侧的绕行：部分手机系统与浏览器自带加密 DNS，会越过网关自己解析，网关层配置再对也被架空，症状是同一网络下唯独某台设备泄露或不解锁，排查时先查这台设备自己的 DNS 设置。其二，IPv6 绕行：IPv6 流量若没被一并接管，就会从代理身边溜过去造成泄露与地区误判，处理只有两个干脆选项——在主路由与软路由关掉 IPv6 下发，全家走 IPv4；或者确认当前版本能把 IPv6 一并纳入接管再打开，最忌讳半开半不管。其三，旁路由拓扑下设备的 DNS 必须指向旁路由而不是主路由，否则分流判断拿到的解析结果对不上号，第六章的规则再精细也使不上劲。全部配完，去 dnsleaktest.com 跑一次：显示的解析出口应与代理落地一致，而不是运营商的服务器。
八、全屋设备验证：逐台过一遍再宣布完工
启动成功不等于全屋可用。按设备类型逐台验证，每类看的点不一样：
- 手机与电脑：先开一个国内应用确认加载速度没有变慢，再开国外站点确认可达，最后复查 DNS 泄露结果；
- 电视盒子与智能电视：打开流媒体应用，看片库是不是目标地区的、画质能不能顶到订阅档位，这是检验节点解锁能力的硬指标；
- 游戏机：看商店区域是否正确、联机 NAT 类型是否受限，下载速度顺带记一笔；
- 智能家居设备：它们不需要翻墙，只需确认联网稳定、没有因为网关变更掉线重连，这类设备出问题通常出在 DHCP 与网段，而不是代理规则；
- 访客设备：新设备连上后不做任何设置直接测试，验证 DHCP 下发是否真的把网关指对了。
验证时把基线记下来：每个主力节点的延迟量级、流媒体的解锁状态、国内站点的打开手感。日后出故障，第一步就是和基线对照，而不是凭感觉乱改参数。
九、故障排查表
先恢复可用、再定位原因，是排障的次序。下表按现象从最常见排起：
| 现象 | 先查什么 | 处理方向 |
|---|---|---|
| 全屋断网 | 旁路由是否死机；是否误开了它的 DHCP 与主路由冲突 | 先把主路由 DHCP 的网关改回主路由自身，全网恢复后再回头查旁路由 |
| 国内网站明显变慢 | 国内流量是否被规则误送代理；MATCH 兜底是否指向代理且国内规则集未生效 | 看连接日志里国内域名命中的是哪条规则，确认国内域名/IP 规则集已加载并排在前面 |
| 流媒体打不开或片库不对 | 节点落地地区；流媒体域名被分到了哪个策略组；DNS 是否泄露 | 换解锁组里的节点；把该平台域名明确指向流媒体组；按第七章复查解析出口 |
| 微信、银行、支付类应用异常 | 这些域名或其 IP 段被误判走代理 | 在覆写里给相关域名加 DIRECT 条目（见下方示例），或确认国内规则集生效 |
| DNS 检测显示运营商 | 是否启用 fake-ip；国外解析有没有走代理链路；个別设备是否自带加密 DNS | 逐项对照第七章的三个坑 |
| 游戏延迟高、跳 ping | 游戏流量走了绕路节点；加速类功能与代理是否互相干扰 | 游戏设备或域名改直连或指向低延迟节点；逐个开关相关功能做对照测试 |
| 订阅拉不到、节点全红 | 设备时间是否跑偏；订阅地址是否仍是 Clash 格式 | 先校时再更新订阅；仍失败就换个网络环境验证订阅本身是否有效 |
| 更新订阅后分流全乱 | 手工改动写在了订阅生成文件里、被更新覆盖；或覆写与新配置冲突 | 改动一律走覆写；乱了就先停用覆写回到默认配置，再逐条加回 |
给国内应用补直连条目要写在覆写里：
rules:
- "DOMAIN-SUFFIX,qq.com,DIRECT"
- "DOMAIN-SUFFIX,weixin.qq.com,DIRECT"
- "DOMAIN-SUFFIX,alipay.com,DIRECT"十、安全与日常维护
软路由是全屋流量的咽喉，安全基线只有几条但条条要紧：代理端口与管理后台绝不直接暴露到公网，需要远程管理就走 VPN 回家再操作；管理密码不要沿用固件默认值；防火墙保持 WAN 侧入站默认拒绝。
性能上留一个心眼：OpenWrt 的流量分载（Flow Offloading）类加速能显著降低转发时的 CPU 占用，但在某些版本与代理分流组合下会引发个别流量绕过规则的怪问题。原则是：开启后按第八章重新验证一遍分流与解锁，出现对不上的现象就先关掉它做对照，把变量收敛到一个。内存吃紧的盒子同理克制——规则集只勾用得上的，GEO 数据选二进制格式，日志定期清。
维护节奏建议固定下来：订阅与规则集开自动更新；内核与固件不追新，动手升级前先导出当前配置备份，确认新版本与你的设备架构、固件的兼容情况再操作——具体以 OpenClash 官方仓库与你的固件版本说明为准。协议层本身想再深入，可以看 科学上网协议对比 2026 与 WireGuard 自建 VPN 完整教程；全平台客户端的总览在 全平台科学上网客户端配置终极指南。
结语
回头看，OpenClash 落地成败很少取决于某个高级参数，而取决于四件基础事有没有做对：拓扑按前提选、内核与架构对版、规则的匹配顺序理顺、DNS 不绕行不泄露。这四件做对了，剩下的都是体验调优；做错任意一件，症状都会伪装成别的问题来误导你。排障时也回到这四件上逐项对照，比逐个菜单试参数要快得多。
延伸阅读
免责声明
本文仅供技术交流和学习参考。涉及第三方服务的链接可能包含 sponsored 标记，请自行核实服务条款、价格和可用性，并遵守当地法律法规。