vernesong
[Bug] Fake-ip+防火墙转发的DNS劫持模式下，访问谷歌等gfw黑名单网站，出现报错和DNS污染
Verify Steps
- [X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
- [X] Branch 我知道 OpenClash 的 Dev 分支切换开关位于插件设置-版本更新中，或者我会手动下载并安装 Dev 分支的 OpenClash
- [X] Latest 我已经使用最新 Dev 版本测试过，问题依旧存在
- [X] Relevant 我知道 OpenClash 与 内核(Core)、控制面板(Dashboard)、在线订阅转换(Subconverter)等项目之间无直接关系，仅相互调用
- [X] Definite 这确实是 OpenClash 出现的问题
- [ ] Contributors 我有能力协助 OpenClash 开发并解决此问题
- [ ] Meaningless 我提交的是无意义的催促更新或修复请求
OpenClash Version
v0.46.042-beta
Bug on Environment
Istoreos
OpenWrt Version
iStoreOS 22.03.7 2024080210 / LuCI istoreos-22.03 branch git-24.207.28853-3b34de8
Bug on Platform
Linux-amd64(x86-64)
Describe the Bug
在fake-ip+DNS劫持:防火墙转发模式下 局域网内的部分设备 访问谷歌等gfw黑名单网站，出现报错和DNS污染（表现为google返回Facebook证书），fake-ip+Dnsmasq劫持就没这个问题
To Reproduce
Fake-ip模式+DNS劫持改为 防火墙转发
OpenClash Log
见下方附件
OpenClash Config
No response
Expected Behavior
因为想在fake-ip模式下限制局域网设备的是否通过代理，根据教程只能用防火墙转发模式劫持DNS，但目前似乎会造成DNS污染，希望能修复这个问题
Additional Context
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
缓存不会有问题，主要你指定的上有dns不能给错误地址
大佬，帮我看看日志里能不能看出什么问题来，照理说fake-ip下浏览Google不会向上游请求真实dns了，直接返回一个假的然后走代理去了
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
我的DNS劫持模式用的是 防火墙转发，因为我想在Fake-ip模式下让部分网内设备绕过clash，默认的dnsmasq转发劫持没有局域网设备访问控制选项，设置里提示必须用防火墙转发模式才可以，可能我也不太懂，其他都是默认设置了。 莫非是需要另外设置一个dns服务器？
我对比了下Dnsmasq转发 和 防火墙转发 这两种DNS劫持模式下 调试日志内容的差异 但我看不懂
我今天开始也这样了，更新到最新43版和最新 dev 内核，跟你一模一样，好多之前正常的网站全都终止连接，油管打开页面也是异常缓慢，不知道咋回事
你也是fake-ip模式吗+防火墙转发吗？
我今天开始也这样了，更新到最新43版和最新 dev 内核，跟你一模一样，好多之前正常的网站全都终止连接，油管打开页面也是异常缓慢，不知道咋回事
你也是fake-ip模式吗+防火墙转发吗？
我是 fake ip+Dnsmasq转发用了都几年了了，今天下午开始就这样了，刷机重置打开 dns 复写都不行，搞不定准备换个插件，我的 vps 关了 openclash 可直连，打开 openclash 就连不上网页显示被终止，之前都是正常的，github 和油管网页打开缓慢，我还发现更新 ip 白名单一直报错网络错误
我今天开始也这样了，更新到最新43版和最新 dev 内核，跟你一模一样，好多之前正常的网站全都终止连接，油管打开页面也是异常缓慢，不知道咋回事
你也是fake-ip模式吗+防火墙转发吗？
我是 fake ip+Dnsmasq转发用了都几年了了，今天下午开始就这样了，刷机重置打开 dns 复写都不行，搞不定准备换个插件，我的 vps 关了 openclash 可直连，打开 openclash 就连不上网页显示被终止，之前都是正常的，github 和油管网页打开缓慢，我还发现更新 ip 白名单一直报错网络错误
会不会是你配置文件里的dns服务器故障或者被墙了 试试只保留一个name-server 223.5.5.5 ,再或者要么是机场的节点出了问题
我今天开始也这样了，更新到最新43版和最新 dev 内核，跟你一模一样，好多之前正常的网站全都终止连接，油管打开页面也是异常缓慢，不知道咋回事
你也是fake-ip模式吗+防火墙转发吗？
我是 fake ip+Dnsmasq转发用了都几年了了，今天下午开始就这样了，刷机重置打开 dns 复写都不行，搞不定准备换个插件，我的 vps 关了 openclash 可直连，打开 openclash 就连不上网页显示被终止，之前都是正常的，github 和油管网页打开缓慢，我还发现更新 ip 白名单一直报错网络错误
会不会是你配置文件里的dns服务器故障或者被墙了 试试只保留一个name-server 223.5.5.5 ,再或者要么是机场的节点出了问题
我试试吧，机场节点显示正常，vps 自建节点失败，vps 在开了 openclash 就无法直连（之前没问题），现在就是用机场节点打开 github 油管异常缓慢
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
我的DNS劫持模式用的是 防火墙转发，因为我想在Fake-ip模式下让部分网内设备绕过clash，默认的dnsmasq转发劫持没有局域网设备访问控制选项，设置里提示必须用防火墙转发模式才可以，可能我也不太懂，其他都是默认设置了。 莫非是需要另外设置一个dns服务器？
我对比了下Dnsmasq转发 和 防火墙转发 这两种DNS劫持模式下 调试日志内容的差异 但我看不懂
dnsmasq和防火墙转发差别在于把客户端dns劫持到路由器53端口（dnsmasq）或是劫持到clash本身的dns监听端口上，这个是在iptables/nftables上实现的，用意就是防止客户端得到不正确的dns反馈，这种dns劫持本质上都是把客户端劫持到路由器上再做处理，一般让dnsmasq处理就行，最后还是会到clash这里，所以我才让你看看路由器上是否还有其它dns插件捣蛋 另外客户端错误的dns指向设置也会导致浏览器对clash发起错误的连线（gateway指向clash，而dns指向其它上游dns），一般来说没啥特殊要求，都是指向同一台路由器，另设一台dns是没必要的 还有就是你确定下浏览器没有开启DoT或是DoH（简称安全dns），这个设置能躲过劫持，造成你dns反馈出错
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
我的DNS劫持模式用的是 防火墙转发，因为我想在Fake-ip模式下让部分网内设备绕过clash，默认的dnsmasq转发劫持没有局域网设备访问控制选项，设置里提示必须用防火墙转发模式才可以，可能我也不太懂，其他都是默认设置了。 莫非是需要另外设置一个dns服务器？
我对比了下Dnsmasq转发 和 防火墙转发 这两种DNS劫持模式下 调试日志内容的差异 但我看不懂
dnsmasq和防火墙转发差别在于把客户端dns劫持到路由器53端口（dnsmasq）或是劫持到clash本身的dns监听端口上，这个是在iptables/nftables上实现的，用意就是防止客户端得到不正确的dns反馈，这种dns劫持本质上都是把客户端劫持到路由器上再做处理，一般让dnsmasq处理就行，最后还是会到clash这里，所以我才让你看看路由器上是否还有其它dns插件捣蛋 另外客户端错误的dns指向设置也会导致浏览器对clash发起错误的连线（gateway指向clash，而dns指向其它上游dns），一般来说没啥特殊要求，都是指向同一台路由器，另设一台dns是没必要的 还有就是你确定下浏览器没有开启DoT或是DoH（简称安全dns），这个设置能躲过劫持，造成你dns反馈出错
原来如此，我客户端都是dhcp自动获取的，都是指向网关。另外,在dnsmasq转发下DNS劫持就很正常，我感觉还是clash内核在处理防火墙转发时没有正确劫持到dns请求的关系，因为我没有其他DNS插件干扰，要么就是这个版本的openwrt有bug
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
我的DNS劫持模式用的是 防火墙转发，因为我想在Fake-ip模式下让部分网内设备绕过clash，默认的dnsmasq转发劫持没有局域网设备访问控制选项，设置里提示必须用防火墙转发模式才可以，可能我也不太懂，其他都是默认设置了。 莫非是需要另外设置一个dns服务器？
dnsmasq和防火墙转发差别在于把客户端dns劫持到路由器53端口（dnsmasq）或是劫持到clash本身的dns监听端口上，这个是在iptables/nftables上实现的，用意就是防止客户端得到不正确的dns反馈，这种dns劫持本质上都是把客户端劫持到路由器上再做处理，一般让dnsmasq处理就行，最后还是会到clash这里，所以我才让你看看路由器上是否还有其它dns插件捣蛋 另外客户端错误的dns指向设置也会导致浏览器对clash发起错误的连线（gateway指向clash，而dns指向其它上游dns），一般来说没啥特殊要求，都是指向同一台路由器，另设一台dns是没必要的 还有就是你确定下浏览器没有开启DoT或是DoH（简称安全dns），这个设置能躲过劫持，造成你dns反馈出错
原来如此，我客户端都是dhcp自动获取的，都是指向网关。另外,在dnsmasq转发下DNS劫持就很正常，我感觉还是clash内核在处理防火墙转发时没有正确劫持到dns请求的关系，因为我没有其他DNS插件干扰，要么就是这个版本的openwrt有bug
昨晚折腾到凌晨 1 点没好，扔着今早去看，自己好了，也没搞懂哪的问题。。。
你这问题我之前也有碰过，我部署2个dns server 当clash的下游dns，客户端指向这两个dns server 然后时不时就会有证书错误的问题发生，主要发生在主路由上的clash重启后短时间浏览网页时发生，模式也是fake-ip 你可以看下出问题的页面证书内容（证书主题背景的备用名称）看看是不是和你其它浏览页面的网址有重合 这个问题我琢磨很久，最后发现是两个下游dns的dns cache问题，原理大概如下： 下游cache了clash在重启前给出的假ip，然后clash重启后重构假ip映射表，由于下游dns server惯性作用 （电脑发起的网址请求先从cache里查询），接着刚好这个ip对应的请求网址和clash fake-ip表里其它网址重合，然后就会出现你要求A网址，但实际返回的是cache里的B网址，然后你的浏览器就会报警了 解方也很简单，把dns查询指向clash就行，因为你没办法保证下游dns 给出的答案能和clash给出的一样
可是我没有部署其他DNS服务器 DNS默认指向应该就是Clash，而且照理说应该会返回一个198开头的fake-ip，但事实上似乎是被某个上游DNS抢答了，直接返回了一个199开头的污染的ip，fake-ip没有正常工作
对于clash来说，上游DNS是否污染无所谓，因为上游给的ip主要是拿来匹配规则及判定ip段用的，最后还是要发到节点做远程解析 clash默认有个dns server，你可以ssh路由器看看是不是有其它dns插件抢答，如果你没有自定义fake-ip段，然后又得到非198的ip 很大概率应该是有其他dns插件同时运行，看看udp port 53是谁占住就知道了（正常是dnsmasq）
我的DNS劫持模式用的是 防火墙转发，因为我想在Fake-ip模式下让部分网内设备绕过clash，默认的dnsmasq转发劫持没有局域网设备访问控制选项，设置里提示必须用防火墙转发模式才可以，可能我也不太懂，其他都是默认设置了。 莫非是需要另外设置一个dns服务器？
dnsmasq和防火墙转发差别在于把客户端dns劫持到路由器53端口（dnsmasq）或是劫持到clash本身的dns监听端口上，这个是在iptables/nftables上实现的，用意就是防止客户端得到不正确的dns反馈，这种dns劫持本质上都是把客户端劫持到路由器上再做处理，一般让dnsmasq处理就行，最后还是会到clash这里，所以我才让你看看路由器上是否还有其它dns插件捣蛋 另外客户端错误的dns指向设置也会导致浏览器对clash发起错误的连线（gateway指向clash，而dns指向其它上游dns），一般来说没啥特殊要求，都是指向同一台路由器，另设一台dns是没必要的 还有就是你确定下浏览器没有开启DoT或是DoH（简称安全dns），这个设置能躲过劫持，造成你dns反馈出错
原来如此，我客户端都是dhcp自动获取的，都是指向网关。另外,在dnsmasq转发下DNS劫持就很正常，我感觉还是clash内核在处理防火墙转发时没有正确劫持到dns请求的关系，因为我没有其他DNS插件干扰，要么就是这个版本的openwrt有bug
我觉得这几版的客户端与core有兼容性问题，你没看到up主这些天更新的很勤？估计正抓着问题呢 昨天我升到043后，tun模式就挂了......
检查一下设备使用的ipv6 dns，最近公共dns很喜欢发被污染过的ip
我dns用的是system 应该是自动使用上游的运营商的dns，没设置过专门的ipv6 dns
你的日志里面都没几个域名，大概率哪里开了其他dns查询了，本机的代理可以显示域名，说明本机的代理是没问题的
奇怪了，我就只在软路由上装了个openwrt，然后里面装了openclash和docker，docker就一个反代，没其他东西，而且如果把openclash关了，谷歌直接就是连不上，不会有这种证书与域名不匹配的dns污染的页面显示。
奇怪了，我就只在软路由上装了个openwrt，然后里面装了openclash和docker，docker就一个反代，没其他东西，而且如果把openclash关了，谷歌直接就是连不上，不会有这种证书与域名不匹配的dns污染的页面显示。
你找一台客户端使用nslookup看看返回的ip都是什么，也可以在路由器上使用看看返回的是不是和客户端一致
检查一下设备使用的ipv6 dns，最近公共dns很喜欢发被污染过的ip
我dns用的是system 应该是自动使用上游的运营商的dns，没设置过专门的ipv6 dns
去nameserver和fallback组启用cloudflare的doh，然后保存并应用试试
找到原因了，还是ipv6的关系，关了就正常了，如果要开ipv6 只能是redir-host或fake-ip+dnsmasq，如果DNS劫持改用防火墙转发会被ipv6的网关抢答DNS解析，clash拿不到客户端的dns请求，最终还是改用redir-host了，慢点就慢点吧
找到原因了，还是ipv6的关系，关了就正常了，如果要开ipv6 只能是redir-host或fake-ip+dnsmasq，如果DNS劫持改用防火墙转发会被ipv6的网关抢答DNS解析，clash拿不到客户端的dns请求，最终还是改用redir-host了，慢点就慢点吧
你好，我也出现了类似的情况，OP没有打开任何IPv6相关的设置，且用的是fake-ip+dnsmasq，仍旧出现与您类似的证书错误的情况。
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
找到原因了，还是ipv6的关系，关了就正常了，如果要开ipv6 只能是redir-host或fake-ip+dnsmasq，如果DNS劫持改用防火墙转发会被ipv6的网关抢答DNS解析，clash拿不到客户端的dns请求，最终还是改用redir-host了，慢点就慢点吧
现在的新版本 都没有 redir-host 这个模式了。