先定拓扑：谁应该是「这一跳的网关」
在谈 OpenWrt 与 电脑客户端之前，先把一句话写进脑子里：同一时刻，对局域网里的普通设备而言，默认网关通常只应指向一个「会帮你转发到运营商的那台路由器」。家庭常见结构是光猫桥接、OpenWrt 主路由拨号，LAN 里所有终端的网关就是 OpenWrt 的 LAN 地址（例如 192.168.1.1）。在这种结构下，「路由器上跑 Clash」解决的是经过网关的流量如何被透明拦截与分流，而不是再让终端把网关改成别的机器。
如果你把 OpenWrt 放在二级路由位置（上级还有一台拨号路由），仍然建议每一层子网各自只有一个默认网关：二级 OpenWrt 下的电脑，网关应是 OpenWrt 的 LAN IP；至于上级路由是否也要跑代理，那是另一条链路，避免终端同时「既指上级又指下级」造成不对称路由。所谓「双重 NAT」多指上级路由与下级路由各做一层源地址转换，它与「Clash 做透明代理」不是同一个概念——透明代理通常不会改变你看到的「默认网关是谁」，而是让已指向网关的 TCP/UDP 会话在路由器上被重定向到本机 Clash 监听的端口。
DHCP：把网关与 DNS 指给谁
DHCP 是大多数手机、电脑「自动获得 IP」时拿到的三件套的来源：IP 地址、子网掩码、默认网关，很多环境还会下发DNS 服务器。当你启用 OpenClash 或同类插件里「接管 LAN DNS」「重定向 DNS」一类选项时，本质上是希望终端把查询发到路由器，再由路由器上的 Clash DNS 或 dnsmasq 转发链去处理。此时在 OpenWrt 的 DHCP 设置中，常见做法是：网关仍为 LAN IP；DNS 也填 LAN IP（或留空由插件统一改写），让终端不要绕开路由器去用运营商下发的公网 DNS，否则会出现「网页时而能开时而不能」「部分设备走了代理、部分设备走了污染解析」的分裂现象。
若你家里有设备必须走专用 DNS（例如公司笔记本要指向内网域控），可以有两种务实做法：其一，在路由器 DHCP 里为该 MAC 地址建静态租约并单独下发 DNS（OpenWrt 的静态 DHCP 支持 per-host 选项）；其二，保持全局 DNS 指向路由器，但在 Clash 配置里用 nameserver-policy 把特定后缀交给可信解析器。后一种与桌面单机的思路一致，可把YAML 规则与 DNS 段当作同一套逻辑在路由器上放大到全屋。
需要强调的是：电脑里手动设置静态 IP 时，若网关或 DNS 仍指向旧路由、上级路由，或填了公共 DNS 而绕开 OpenWrt，你会看到「只有 DHCP 自动获取的设备正常，手动设 IP 的那台异常」——这类问题与 Clash 本身无关，先把指缝对齐再谈规则。
路由器上的 Clash：透明代理与「全屋」边界
在 OpenWrt 上，OpenClash 等方案通常通过 iptables/nftables 或 TPROXY 把 LAN 侧发往公网的连接导向本机 Clash。对你而言，配置界面上的模式名称可能因版本而异，但判断标准是统一的：不运行 Clash 的终端，是否仍能把默认网关设在 OpenWrt 上正常上网。若关插件后全网不通，说明基础转发或 NAT 本身有问题，应先修路由与防火墙，而不是叠加更多代理层。
「全屋代理」并不等于「每一个以太网帧都进 Clash」。本地子网互访、组播、打印机发现等流量，通常仍应直连；这与桌面客户端里绕过局域网的思路相同，只是路由器侧要在规则或绕过列表里维护一份内网段。若你发现「访问 NAS 变慢」「投屏不稳定」，优先检查是否误把 RFC1918 地址段送进了代理策略组，而不是先去改 DHCP。
与 Windows / Mac 客户端并存：推荐分工
最省心、也最不容易「环路」或「双重代理」的组合通常是：路由器负责全屋透明代理，需要单独策略的终端（开发机、游戏机、访客设备）再按需处理。对于仍想开着桌面 Clash 的电脑，请先想清楚你要的是哪一种效果。
若路由器已经透明代理，这台电脑再开系统代理或TUN，等于同一条会话可能被重复处理：轻则延迟升高、日志难读；重则出现证书校验异常、特定应用断连。实务上更常见的两种安全组合是：A. 路由器开 Clash，电脑上退出客户端或切到「直连/系统代理关闭」，用路由器策略组统一分流；B. 路由器只做 DNS 或不做透明代理，电脑单独跑客户端，DHCP 仍可把 DNS 指到路由器，由路由器转发到 Clash DNS，但默认流量不二次进隧道。二者择一，不要默认「全开」。
若你必须在同一台电脑上临时叠加热门插件里的「仅规则模式」与桌面 TUN（例如调试规则），务必关闭其中一侧的「全局接管」，并观察 Clash 连接日志里是否出现同一域名经不同出口反复重试。更系统的 TUN 与权限问题，见桌面 TUN 专文。
DNS 劫持、Fake-IP 与「部分设备上不了网」
路由器方案里，DNS 往往是故障高发区：终端以为自己在问 8.8.8.8，实际被重定向到路由器；或者 Clash 使用 fake-ip，应用缓存了虚拟地址，离开局域网后又无法复现。处理原则与桌面一致：先确认「终端实际使用的解析路径」，再谈模式好坏。若你启用 fake-ip，请确保内网域名、路由器管理域名、*.local 等落在 fake-ip-filter 或等价绕过列表中，细节见DNS 模式专文。
「部分设备上不了网」时，可按设备类型拆分：仅手机不行常是 Android 私人 DNS 或「始终开启的 VPN」绕开 DHCP；仅某台 Windows 不行常是网卡额外 DNS、公司组策略或 Hyper-V 虚拟交换机抢网关；仅 HTTPS 不行则回到证书、时间同步与 SNI 规则。路由器侧可同时看 OpenWrt 的 dnsmasq 日志与 Clash 查询日志，对照同一时间戳，比单纯反复切换模式更有效。
推荐排查顺序：从外到内、一次只动一项
下面步骤按成本低 → 成本高排列；每完成一步就复测「DHCP 客户端」与「手动静态 IP 客户端」各一台，避免变量堆叠。
- 画一条物理路径：光猫—主路由—交换机—终端；确认谁在拨号、谁的 LAN IP 是网关。
- 关 OpenClash 对照：仅保留 NAT 与基础转发，确认全网能上网，再逐项打开透明代理与 DNS 重定向。
- 核对 DHCP：网关是否为预期 OpenWrt LAN；DNS 是否指向同一台路由器（除非你刻意分流 DNS）。
- 抓一台异常设备：查看当前获取的 IPv4 网关、DNS 列表与路由表首跳，排除手动静态配置残留。
- 桌面客户端策略：路由器已透明代理时，优先退出电脑 Clash 或关闭 TUN/系统代理做 A/B。
- DNS 与 fake-ip：对照日志区分「解析失败」与「连接失败」；按需补
fake-ip-filter或nameserver-policy。 - 规则层：确认内网段、组播、路由器管理地址命中
DIRECT，避免 RFC1918 误送进代理组。
完成上述顺序后，多数「网关指错、DNS 分裂、双端同时接管」类问题都能定位到具体一层。剩下与订阅节点、TLS 或协议相关的现象，再按各专题文章深入即可。
小结：路由器与桌面是同一套网络逻辑的两处落点
OpenWrt 上跑 Clash 并不是魔法，它只是把你在电脑上熟悉的分流、DNS 与策略组搬到了网关旁。与 Windows / macOS 客户端并存时，关键是不要让默认网关与流量接管职责在两层设备上互相打架：用 DHCP 统一网关与 DNS 入口，用透明代理或桌面客户端二选一做主路径，用规则与过滤列表处理内网与特殊域名。把这条主线理顺之后，所谓「双重 NAT」「DNS 劫持」大多会还原成可验证的配置项。
相比只在论坛里搜零散关键词，把本文的顺序固化成你自己的检查表，能明显减少试错时间。Clash 在可维护性与策略表达上仍然适合作为长期方案——无论跑在路由器还是桌面，一份结构清晰的配置都比临时补丁更省心。
若你更习惯在电脑上完成导入订阅、切换节点与版本管理，也可从本站下载中心获取适配当前系统的客户端，再与路由器方案对照使用。
更多专题可继续浏览技术专栏中的 DNS、TUN 与规则分流文章，把家庭路由器与桌面终端纳入同一套知识体系。