本文解决什么问题（以及刻意不写什么）

你已经在一台OpenWrt路由器上装好了OpenClash（或等价集成了 Clash Meta / mihomo 内核的 LuCI 套件），日常更希望对着网页后台完成三件事：订阅更新把机场节点拉到本地、在策略组里切换节点应付高峰线路，以及在连接日志里看清当前到底是哪条规则命中、DNS 有没有歪。这与 Windows / macOS / Android 上单独开一个图形客户端的路径不同：路由器侧界面更像「网关控制台」，一次改动会影响全屋设备的出站与会话。

因此本文不写从零安装 ipk、immortalwrt 软件源选型、旁路网关如何把 DHCP option 指过来，也不展开 nftables 透明转发命令；如果你正处于「要让全屋透明代理」的阶段，可先对照 旁路由透明代理与 DNS 重定向 把拓扑理顺。订阅链接本身的格式与各桌面端导入姿势，可与 Clash 订阅导入指南 互为补充——路由器端往往在 LuCI 里直接填写同一个订阅 URL。

登录 LuCI：先确认 OpenClash「活着」

浏览器打开路由器管理 IP（常见 192.168.1.1），完成登录后在服务或插件菜单找到 OpenClash。进入概况或运行状态页时，优先核对三件事：内核进程是否在跑、当前载入的配置文件名称、以及运行模式（例如规则模式 / 全局类表述）。若概况页提示内核未启动，后面订阅更新即便成功也不会形成可用出站；应先排除磁盘空间、权限或上一次 YAML 语法错误导致的启动失败。

LuCI 插件通常会把订阅生成的运行时配置与你在编辑器里手写的高级片段区分开：订阅面板负责「拉远端列表」，策略与规则面板负责「怎么用这份列表」。混淆这两者时，最常见的问题是改了订阅却一直沿用旧的缓存配置——下文在订阅一节会给出保存 → 更新 → 应用的顺序习惯。

订阅更新：让节点列表与机场面板对齐

订阅更新的本质，是让路由器周期性或用一次手动触发，把服务商给出的订阅链接下载下来，解析成 Clash 认识的 proxies 段落并合并进当前配置。LuCI 里的订阅表单一般会包含：订阅名称（本地辨识用）、订阅地址、可选的User-Agent或跳过证书验证开关（仅在明确知道风险时使用）、以及自动更新间隔。

实操顺序建议固定成肌肉记忆：（1）粘贴或修订订阅 URL，检查有没有多余的空格、有没有把门户登录页误当成订阅接口；（2）保存表单；（3）点击更新订阅或等价按钮；（4）等待日志中出现成功条目后，打开服务器节点列表核对数量；（5）若插件提供应用配置或重新载入内核选项，在大幅变更订阅后再点一次，避免内存里仍是旧的出站集合。

当订阅偶尔更新失败时，先用路由器自带的诊断 → Ping / HTTPS工具确认出站通路没有被你自己的规则堵死（典型坑：全局直连 DNS 却把订阅域名导向错误上游）。日志若提示 TLS 握手失败，多半是系统时间漂移或中间设备劫持 HTTPS；提示超时则收窄 MTU、运营商 QoS、或订阅 CDN 区域性封锁三类变量。机场侧若开启了订阅限速，过于频繁的更新间隔反而会触发风控——可以把自动更新拉到数小时一级，仅在旅行换机房后手动多点一次。

部分用户会用订阅转换服务把 Universal / SIP008 等格式转成 Clash YAML；路由器侧只需托管生成的静态链接即可，但要注意转换后端是否支持你所在网络访问。转换规则若把全部流量推到单一「自动选择」策略，也会让你在 LuCI 里看到一大堆名字类似、却受同一探测器控制的重复项——这不影响使用，但会增加排障时的视觉噪音。

策略组与节点切换：改的是「下一步由谁转发」

在 Clash / mihomo 模型里，策略组（界面里常被译作代理组、策略代理、或按机场习惯叫法）负责把某一类域名或 IP 段映射到具体节点、自动测速选择、直连或拒绝。LuCI 一般会提供可视化列表：左侧是分组名（如「国外流量」「流媒体」「Telegram」），右侧是当前选中的节点或模式。你要做的，是在正确的分组里改选项，而不是只看「全局」页签的表面状态。

为什么「换了节点却没感觉」高频出现？第一种原因是改的是展示用或未被规则引用的分组，实际命中的仍是默认的 MATCH 兜底链。对照 规则分流指南 里关于规则优先级的说明，路由器上同样遵循「从上到下先匹配先走」。第二种原因是长连接应用：视频通话、即时通讯常复用既有 TCP / QUIC 会话，你在 LuCI 里切换后要断开并重建会话才看得到出口变化；可以尝试关掉客户端后台或切换飞行模式强制重建。

若机场提供了UDP支持，留意策略组是否区分 TCP-only 节点；游戏与语音场景若选了不支持 UDP 的中转，表现为延迟抖动而非立刻断线。此类细节通常在节点备注或提供商文档里写明；LuCI 侧能看到握手统计时已偏后期排障。

运行模式与内核重启：什么时候必须「打断重来」

OpenClash 把运行模式、TUN / 混合特性、DNS 劫持方式等选项放在插件设置深处；本文不把每一项都展开成专题，只强调与日常操作相关的触发重启场景：（1）订阅大规模增减节点；（2）切换 fake-ip / redir-host 一类 DNS 工作模式；（3）更换 GeoIP / GEOSITE 数据源版本或自定义规则片段导入失败后被自动回滚。

重启内核会让现有连接瞬时断开数秒，全屋终端体感类似路由器短暂离线——因此不要在全屋视频会议进行时贸然连续点击重启。更稳妥的顺序是：保存配置 → 观察 YAML 校验是否通过 → 在低峰执行重启 → 用手机热点对照验证 DNS 是否符合预期。

如果你在概况页看到DNS 异常或内核崩溃计数递增，先把内核日志级别临时调高（常见为 debug），抓一小段滚动日志后再回调到 info；长期停在 debug 会拖慢 flash 写入速度与界面响应。

实时连接与内核日志：看清「谁在用什么线路」

连接面板是最直观的观测窗口：通常会列出源 IP（局域网设备）、目标域名或 IP、下行策略组命中路径、上行节点名称与字节计数。当你在优酷 / Netflix / Cursor / Steam 等不同应用之间切换时，对照列表可以快速回答两个问题：这条流量有没有经过内核，以及命中的第一条允许规则是哪一类。若列表长时间静止，要先区分是面板刷新间隔较长，还是流量根本没进入内核——后者常见于客户端设置了手工 HTTP 代理绕过网关，或 IPv6 解析走了另一条物理出口。

内核日志则更偏工程师语气：DNS 解析失败、规则提供商下载超时、脚本钩子返回非零退出码，都会在这里留下线索。排查订阅问题时，先看订阅抓取返回码；排查分流错位时，搜索特定域名关键字比对命中策略名。不要把内核日志等同于插件前端日志：前者贴近 mihomo 运行本体，后者多是 LuCI CGI 层的 HTTP 报错。

若你希望把路由器观测习惯迁移到桌面深入调试，可参考 外部控制器与仪表盘 一文理解 REST 端口与安全边界；路由器场景务必限制管理接口暴露范围，避免把外部控制器裸露在公网。

一套可复制的日常操作流程

1. 登录 LuCI → OpenClash 概况页确认内核运行与配置文件无误。
2. 进入订阅管理 → 保存订阅 URL → 手动更新 → 核对节点数量。
3. 在策略组界面为目标分组切换节点或自动策略 → 必要时重启内核。
4. 打开连接面板观察新建会话 → 若有异常再切内核日志关键字检索。
5. 操作结束后把调试日志级别调回常规，避免长期 verbose。

常见问题（精简版）

订阅更新失败怎么办？先从路由器诊断 HTTPS / 时间同步入手，再在插件日志区分超时与 TLS；必要时改用镜像订阅或在本机先把订阅静态托管到局域网 NAS。

切换节点后个别 App 仍然卡顿？多为 QUIC / HTTP3 仍在旧会话上；强制杀了 App 进程或清空 DNS 缓存再试；若是流媒体账户区域问题，还需核对 DNS 出口与账号账单地址逻辑。

能不能和手机客户端共用同一订阅？通常可以，但要注意多数机场同时在线设备数限制；路由器被视为一台长时间在线客户端，不要把订阅链接公开发帖。

小结

OpenClash 在 OpenWrt 上的日常使用，核心是订阅更新 → 策略组选节点 → 用连接面板验证命中这条闭环；LuCI 把三件事塞进浏览器里，省去 SSH 手动 curl 订阅的痛苦，但仍然依赖你对规则优先级与DNS 模式有基本概念——这两点和桌面版 Clash 系客户端完全一致。

相比之下，市面不少路由器插件要么界面碎片化严重、中英文术语长期不一致，要么日志可读性差，出问题只能盲重启；开源 OpenClash 生态文档分散在不同镜像站与 wiki，检索主题时常要把内核日志与 LuCI 报错对照粘贴，新手容错并不高。Clash 官网则尽量把分流意图讲清楚，并用站内文章把桌面端与网关场景串联引用，你在电脑上并行核对订阅或导出 YAML 备份时能少走跳转弯路。如果你希望在路由器之外的终端上也快速拉起同款内核体验，不妨免费下载 Clash 官网 整理的各平台客户端，把 LuCI 里的策略命名搬到笔记本上做 A/B 对照——很多时候先在桌面确认订阅无误，再回到路由器一键更新，排障路径最短。