Verify Steps
OpenClash Version
v0.47.110
Bug on Environment
iStoreOS / OpenWrt 22.03
OpenWrt Version
iStoreOS 22.03.7 2024120615
Bug on Platform
Linux-amd64(x86-64)
Describe the Bug
当订阅配置中自带 dns.proxy-server-nameserver,且该项包含不可用的本机 DNS(例如 udp://127.0.0.1:1053,但本机没有监听 1053)时,Mihomo 会持续使用该 DNS 解析代理节点域名,导致节点拨号失败并反复刷日志:
[DNS] resolve <node-domain> A from udp://127.0.0.1:1053
dial <proxy-group> ... error: <node-domain>:<port> connect error: dns resolve failed: all DNS requests failed, first error: read udp 127.0.0.1:<random>->127.0.0.1:1053: read: connection refused
进一步看 OpenClash 的自定义 DNS 覆写逻辑,nameserver / fallback / default-nameserver 在启用自定义 DNS 时是替换原配置,但 proxy-server-nameserver 是追加合并,因此订阅中原有的坏项不会被清掉:
# nameserver: replace
Value['dns']['nameserver'] = namedns_config['nameserver'].uniq
# proxy-server-nameserver: append
(Value['dns']['proxy-server-nameserver'] ||= []).concat(proxydns['proxy-server-nameserver']).uniq!
这会导致一个比较隐蔽的问题:用户在 LuCI 里配置了自定义 DNS / 节点域名解析服务器后,预期 OpenClash 接管 DNS 配置,但运行配置里仍然保留订阅自带的不可用 proxy-server-nameserver。
我搜索过几个相关 issue,但看起来不是同一个问题:
本 issue 关注的是:普通 DNS 覆写中 proxy-server-nameserver 与 nameserver 的覆盖语义不一致,导致订阅中的错误节点解析 DNS 被保留。
To Reproduce
- 导入一个订阅配置,配置内包含:
dns:
enable: true
nameserver:
- 119.29.29.29
- 223.5.5.5
proxy-server-nameserver:
- udp://127.0.0.1:1053
- 路由器本机没有任何进程监听 UDP 1053。
- 在 LuCI 中进入
服务 -> OpenClash -> 覆写设置 -> DNS 设置,启用自定义上游 DNS,并配置可用的节点域名解析 DNS,例如 223.5.5.5 / 119.29.29.29。
- 重启 OpenClash。
- 查看
服务 -> OpenClash -> 插件设置 -> 调试日志 -> 生成,或查看运行配置。
OpenClash Log
DNS劫持: Dnsmasq 转发
Dnsmasq转发设置: 127.0.0.1#7874
依赖检查:
dnsmasq-full: 已安装
ruby/ruby-yaml/ruby-psych: 已安装
kmod-tun: 已安装
端口占用:
udp :::7874 7537/clash
# no udp 1053 listener
运行配置:
dns:
enable: true
listen: 0.0.0.0:7874
nameserver:
- 119.29.29.29
- 223.5.5.5
proxy-server-nameserver:
- udp://127.0.0.1:1053
最近运行日志:
[DNS] resolve <node-domain> A from udp://127.0.0.1:1053
dial <proxy-group> ... error: <node-domain>:<port> connect error: dns resolve failed: all DNS requests failed, first error: read udp 127.0.0.1:<random>->127.0.0.1:1053: read: connection refused
OpenClash Config
Relevant sanitized config:
dns:
enable: true
ipv6: false
listen: 0.0.0.0:7874
nameserver:
- 119.29.29.29
- 223.5.5.5
proxy-server-nameserver:
- udp://127.0.0.1:1053
enhanced-mode: fake-ip
Expected Behavior
启用自定义 DNS 且用户设置了“节点域名解析服务器 / Proxy-server-nameserver”时,OpenClash 应该像处理 nameserver / fallback / default-nameserver 一样,替换订阅中原有的 proxy-server-nameserver,而不是追加保留旧值。
或者至少提供一个明确选项:是否清空订阅原有的 proxy-server-nameserver 后再写入用户配置。
期望生成的运行配置类似:
dns:
proxy-server-nameserver:
- 223.5.5.5
- 119.29.29.29
不再保留订阅中的 udp://127.0.0.1:1053。
Additional Context
这个问题会直接影响节点域名解析。Mihomo 的 proxy-server-nameserver 是用于解析代理节点服务器域名的 DNS,发生在代理节点拨号之前;如果该 DNS 指向不存在的本机端口,所有使用域名 server 的节点都可能连接失败。
Verify Steps
OpenClash Version
v0.47.110
Bug on Environment
iStoreOS / OpenWrt 22.03
OpenWrt Version
iStoreOS 22.03.7 2024120615
Bug on Platform
Linux-amd64(x86-64)
Describe the Bug
当订阅配置中自带
dns.proxy-server-nameserver,且该项包含不可用的本机 DNS(例如udp://127.0.0.1:1053,但本机没有监听 1053)时,Mihomo 会持续使用该 DNS 解析代理节点域名,导致节点拨号失败并反复刷日志:进一步看 OpenClash 的自定义 DNS 覆写逻辑,
nameserver/fallback/default-nameserver在启用自定义 DNS 时是替换原配置,但proxy-server-nameserver是追加合并,因此订阅中原有的坏项不会被清掉:这会导致一个比较隐蔽的问题:用户在 LuCI 里配置了自定义 DNS / 节点域名解析服务器后,预期 OpenClash 接管 DNS 配置,但运行配置里仍然保留订阅自带的不可用
proxy-server-nameserver。我搜索过几个相关 issue,但看起来不是同一个问题:
proxy-server-nameserver设置入口;proxy-server-nameserver的行为;本 issue 关注的是:普通 DNS 覆写中
proxy-server-nameserver与nameserver的覆盖语义不一致,导致订阅中的错误节点解析 DNS 被保留。To Reproduce
服务 -> OpenClash -> 覆写设置 -> DNS 设置,启用自定义上游 DNS,并配置可用的节点域名解析 DNS,例如223.5.5.5/119.29.29.29。服务 -> OpenClash -> 插件设置 -> 调试日志 -> 生成,或查看运行配置。OpenClash Log
OpenClash Config
Relevant sanitized config:
Expected Behavior
启用自定义 DNS 且用户设置了“节点域名解析服务器 / Proxy-server-nameserver”时,OpenClash 应该像处理
nameserver/fallback/default-nameserver一样,替换订阅中原有的proxy-server-nameserver,而不是追加保留旧值。或者至少提供一个明确选项:是否清空订阅原有的
proxy-server-nameserver后再写入用户配置。期望生成的运行配置类似:
不再保留订阅中的
udp://127.0.0.1:1053。Additional Context
这个问题会直接影响节点域名解析。Mihomo 的
proxy-server-nameserver是用于解析代理节点服务器域名的 DNS,发生在代理节点拨号之前;如果该 DNS 指向不存在的本机端口,所有使用域名 server 的节点都可能连接失败。