[Bug]: 现在最新版本是不是DNS劫持了，可否恢复之前的重写向dns选项，谢谢

[snakwu]

描述您遇到的bug

现在最新版本没有了重定向dns选项了，默认DNS劫持了
:~$ nslookup qq.com 9.8.7.6
Server: 9.8.7.6
Address: 9.8.7.6#53

Non-authoritative answer:
Name: qq.com
Address: 113.108.81.189
Name: qq.com
Address: 123.150.76.218

复现此Bug的步骤

只要启paswall,默认DNS劫持了
:~$ nslookup qq.com 9.8.7.6
Server: 9.8.7.6
Address: 9.8.7.6#53

Non-authoritative answer:
Name: qq.com
Address: 113.108.81.189
Name: qq.com
Address: 123.150.76.218

您想要实现的目的

可否恢之重定向dns选项，对自己建dns的用户来说，不需要重定向dns

日志信息

:~$ nslookup qq.com 9.8.7.6
Server: 9.8.7.6
Address: 9.8.7.6#53

Non-authoritative answer:
Name: qq.com
Address: 113.108.81.189
Name: qq.com
Address: 123.150.76.218

截图

No response

系统相关信息

Passwall 版本【 24.12.08-r1 】

其他信息

No response

[sss9091]

并不影响你使用自建DNS，passwall里配置DNS为你的自建DNS即可。不确定xiaorouji大佬有没有打算加开关，实在不想用的话先自己把相关代码删掉吧。

这个功能还是挺重要的，劫持DNS后能解决很多奇奇怪怪的问题。

然后说点题外话，其实passwall最开始是没有dns劫持的功能的，当时lede是靠自定义防火墙规则实现，immortalwrt有开关实现，但在今年4月的时候，xiaorouji大佬的一次修改去掉了一些代码，导致劫持全部失效：cf7003f ，当时就是以下代码被移除了：

$ipt_m -A PSW -p udp --dport 53 -j RETURN
$ip6t_m -A PSW -p udp --dport 53 -j RETURN

nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return"
nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return"

后来是@lwb1978帮忙解决的，加了开关，在此再次对这位大佬表示感谢。

[lwb1978]

小肉鸡的新代码是把Dnsmasq的设置拷贝一份，然后修改端口为11400，在这个副本上面进行修改和适配pw，重新调起一个新的Dnsmasq进程（相当于pw专用），然后劫持并重定向客户机访问的53端口流量到11400端口。我现在还不知道这样修改后对性能和稳定性上有什么帮助，但可能会对一些用户套娃使用dns有些影响，比如adg+smartdns+Dnsmasq这样的形式，要摸清现在修改后的原理和流程才能正常工作。
现在小肉鸡已经重新回归出山，所以一切涉及核心的更改以小肉鸡思路为主。

[snakwu]

并不影响你使用自建DNS，passwall里配置DNS为你的自建DNS即可。不确定xiaorouji大佬有没有打算加开关，实在不想用的话先自己把相关代码删掉吧。

这个功能还是挺重要的，劫持DNS后能解决很多奇奇怪怪的问题。

然后说点题外话，其实passwall最开始是没有dns劫持的功能的，当时lede是靠自定义防火墙规则实现，immortalwrt有开关实现，但在今年4月的时候，xiaorouji大佬的一次修改去掉了一些代码，导致劫持全部失效：cf7003f ，当时就是以下代码被移除了：

$ipt_m -A PSW -p udp --dport 53 -j RETURN
$ip6t_m -A PSW -p udp --dport 53 -j RETURN

nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return"
nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return"

后来是@lwb1978帮忙解决的，加了开关，在此再次对这位大佬表示感谢。

你说到重点来了，当时就是因为lede的会劫持，所以再转到pass的，现在劫持了，影响到了自建dns了。

[snakwu]

小肉鸡的新代码是把Dnsmasq的设置拷贝一份，然后修改端口为11400，在这个副本上面进行修改和适配pw，重新调起一个新的Dnsmasq进程（相当于pw专用），然后劫持并重定向客户机访问的53端口流量到11400端口。我现在还不知道这样修改后对性能和稳定性上有什么帮助，但可能会对一些用户套娃使用dns有些影响，比如adg+smartdns+Dnsmasq这样的形式，要摸清现在修改后的原理和流程才能正常工作。 现在小肉鸡已经重新回归出山，所以一切涉及核心的更改以小肉鸡思路为主。

正正就是套娃方案不过我是adg+paopaodns，引起了dns经常出问题了，现在只要打开passwall，国外的正常解释，国内的失败

[snakwu]

@xiaorouji 肉鸡大哥，可否恢复重定身dns开关，让套娃dns的用户满足一下需求，现在所有dns让劫持了，引起了只能访问国外，国内访问不了，还有影响到了设备访问控制里的设备无法上网，谢谢

[sss9091]

还以为你是单纯的不想开劫持，如果有问题的话，最好具体说下是什么问题，把所有的配置和日志都贴上来。

/tmp/etc/dnsmasq.conf
/tmp/etc/passwall/acl/default/dnsmasq.conf
以上两个配置文件也很重要，如果开了访问控制，访问控制目录下的dnsmasq.conf也很重要。

先确认下是不是passwall的逻辑上有冲突，尽量把潜在的问题解决了，再讨论开关的事吧。

[sss9091]

@xiaorouji 肉鸡大哥，可否恢复重定身dns开关，让套娃dns的用户满足一下需求，现在所有dns让劫持了，引起了只能访问国外，国内访问不了，还有影响到了设备访问控制里的设备无法上网，谢谢

感觉你说的和 xiaorouji/openwrt-passwall2#718 这个问题有点像，都是直连有问题，代理没问题，有用最新源码试过么。

[lwb1978]

另外还可以参考这个xiaorouji/openwrt-passwall2#730

[snakwu]

@xiaorouji 肉鸡大哥，可否恢复重定身dns开关，让套娃dns的用户满足一下需求，现在所有dns让劫持了，引起了只能访问国外，国内访问不了，还有影响到了设备访问控制里的设备无法上网，谢谢

感觉你说的和 xiaorouji/openwrt-passwall2#718 这个问题有点像，都是直连有问题，代理没问题，有用最新源码试过么。

用的是最新的代码

[snakwu]

还以为你是单纯的不想开劫持，如果有问题的话，最好具体说下是什么问题，把所有的配置和日志都贴上来。

/tmp/etc/dnsmasq.conf /tmp/etc/passwall/acl/default/dnsmasq.conf 以上两个配置文件也很重要，如果开了访问控制，访问控制目录下的dnsmasq.conf也很重要。

先确认下是不是passwall的逻辑上有冲突，尽量把潜在的问题解决了，再讨论开关的事吧。

其实就是单纯的不要劫持，因为我的自建DNS是设在内网，adg+paopaodns的方案，如果关闭了passwall是正常的，paopaodns所在的主机的dns查询也是正常的，如果开户了passwall后，paopaodns所在的主机，查询所有记录都让劫持了，引发dns查询不正常，因为paopaodns是带有分流功能的，有点类似smatdns,然后如果在访问控制列表添加一个全局代理的规则下面的dns选项也填自建的，就会引起这台设备上不了网，如果把dns设为9.9.9.9,就可以正常，现在我回退passwall代码到c8683d4dcfcaf412ca1e14678a83b30475936d51，这里，就正常了。

[lwb1978]

按最新的逻辑你单纯不劫持连科学都用不了，最新逻辑pw的dns端口是11400，不劫持的话客户机根本不会自动访问11400端口，所以只能遇到问题解决问题，不是加个开关就解决的，除非你用回12号以前的版本。

[lwb1978]

还以为你是单纯的不想开劫持，如果有问题的话，最好具体说下是什么问题，把所有的配置和日志都贴上来。

/tmp/etc/dnsmasq.conf /tmp/etc/passwall/acl/default/dnsmasq.conf 以上两个配置文件也很重要，如果开了访问控制，访问控制目录下的dnsmasq.conf也很重要。

先确认下是不是passwall的逻辑上有冲突，尽量把潜在的问题解决了，再讨论开关的事吧。

如果是要解决问题就如上所说，尽可能提供有效信息进行分析，单纯的说要恢复开关基本上不会了，除非小肉鸡废除这几天的代码恢复之前的逻辑，又或者你一直停留在12号以前的版本以后不再更新。

[snakwu]

按最新的逻辑你单纯不劫持连科学都用不了，最新逻辑pw的dns端口是11400，不劫持的话客户机根本不会自动访问11400端口，所以只能遇到问题解决问题，不是加个开关就解决的，除非你用回12号以前的版本。

哦哦，这样，这些我不太懂，要看你们大佬了，非常感谢你们对这个项目的付出🙏，因为我adg所在的ip:192.168.88.53，paopao作为adg的上游，ip：192.68.88.64，passwall的dns填的自定义192.168.88.63，然后在paopaodns的主机nsloookup qq.com 9.8.7.6.这个9.8.7.6是一个空dns主机，然后看到已经劫持到主路由上去了，正常空的dns是不应该能查询到结果的，引起paopaodns测试不通过，可能引发paopaodns一些组件出了问题，如果关了passwall就一切正常，回退12号之前的代码后，开了passwall也正常，因为我之前一直是这么用的，都正常的，就这几天怎么发现有问题，就猜想到应该是劫持引起的。

[snakwu]

还以为你是单纯的不想开劫持，如果有问题的话，最好具体说下是什么问题，把所有的配置和日志都贴上来。
/tmp/etc/dnsmasq.conf /tmp/etc/passwall/acl/default/dnsmasq.conf 以上两个配置文件也很重要，如果开了访问控制，访问控制目录下的dnsmasq.conf也很重要。
先确认下是不是passwall的逻辑上有冲突，尽量把潜在的问题解决了，再讨论开关的事吧。

如果是要解决问题就如上所说，尽可能提供有效信息进行分析，单纯的说要恢复开关基本上不会了，除非小肉鸡废除这几天的代码恢复之前的逻辑，又或者你一直停留在12号以前的版本以后不再更新。

passwall的设置：

adg和paopao监听的端口都是：53
开启passwall后paopaodns的测试：

下面是关闭passwall的测试：

这个9.8.7.6是用来测试返回值有没有劫持的，然后和上面对比，已经劫持了，所以HIJACK测试会出错。

[hcym]

今天的版本内存是一点都不漏
dns没在意

[xiaorouji]

按最新的逻辑你单纯不劫持连科学都用不了，最新逻辑pw的dns端口是11400，不劫持的话客户机根本不会自动访问11400端口，所以只能遇到问题解决问题，不是加个开关就解决的，除非你用回12号以前的版本。

哦哦，这样，这些我不太懂，要看你们大佬了，非常感谢你们对这个项目的付出🙏，因为我adg所在的ip:192.168.88.53，paopao作为adg的上游，ip：192.68.88.64，passwall的dns填的自定义192.168.88.63，然后在paopaodns的主机nsloookup qq.com 9.8.7.6.这个9.8.7.6是一个空dns主机，然后看到已经劫持到主路由上去了，正常空的dns是不应该能查询到结果的，引起paopaodns测试不通过，可能引发paopaodns一些组件出了问题，如果关了passwall就一切正常，回退12号之前的代码后，开了passwall也正常，因为我之前一直是这么用的，都正常的，就这几天怎么发现有问题，就猜想到应该是劫持引起的。

paopaodns的上游是什麼

[snakwu]

按最新的逻辑你单纯不劫持连科学都用不了，最新逻辑pw的dns端口是11400，不劫持的话客户机根本不会自动访问11400端口，所以只能遇到问题解决问题，不是加个开关就解决的，除非你用回12号以前的版本。

哦哦，这样，这些我不太懂，要看你们大佬了，非常感谢你们对这个项目的付出🙏，因为我adg所在的ip:192.168.88.53，paopao作为adg的上游，ip：192.68.88.64，passwall的dns填的自定义192.168.88.63，然后在paopaodns的主机nsloookup qq.com 9.8.7.6.这个9.8.7.6是一个空dns主机，然后看到已经劫持到主路由上去了，正常空的dns是不应该能查询到结果的，引起paopaodns测试不通过，可能引发paopaodns一些组件出了问题，如果关了passwall就一切正常，回退12号之前的代码后，开了passwall也正常，因为我之前一直是这么用的，都正常的，就这几天怎么发现有问题，就猜想到应该是劫持引起的。

paopaodns的上游是什麼

https://github.com/kkkgo/PaoPaoDNS
大佬，就是这个项目，好像是不用上游的，是直接从根服务器查询的，你可以看看，谢谢

[SakuraFallingMad]

我的情况就更简单了。op里adg（53port）+smartdns（6053port）+Dnsmasq（5335port），套娃顺序adg+Dnsmasq+smartdns
预想行为是，无论开关psw，想让op通过adg+Dnsmasq+smartdns大方向设置不动。ps：已在防火墙设置根据官网op的intercept-dns设置完毕。

预期功能思路：

1. 关闭psw：adg转发dnsmasq转发smartdns
2. 预期psw打开后：adg转发dnsmasq（pw可接管，chinadns-ng推荐模式）

附上日常日志：

[xiaorouji]

Try the latest commit.

[snakwu]

Try the latest commit.

ok，我测一下，谢谢

[sss9091]

Try the latest commit.

所以现在的逻辑是什么，passwall还能劫持dns吗，最新源码测试劫持失败，结果是污染的。

# dig www.google.com @119.29.29.29

; <<>> DiG 9.16.44-Debian <<>> www.google.com @119.29.29.29
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: df5758f3cd0ee8a1 (echoed)
;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		61	IN	A	199.59.148.96

;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sun Dec 15 23:22:16 CST 2024
;; MSG SIZE  rcvd: 71

[sss9091]

@xiaorouji 我看了下PaoPaoDNS，是个递归DNS服务，也就是从根服务器开始一级一级解析下来，这种用法确实没见过。
现在最新源码劫持是无效的，但是看了下还是有劫持相关的代码，不太懂现在的逻辑。

[snakwu]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> www.google.com @192.168.88.64 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 479 IN A 74.125.200.147 www.google.com. 479 IN A 74.125.200.106 www.google.com. 479 IN A 74.125.200.103 www.google.com. 479 IN A 74.125.200.105 www.google.com. 479 IN A 74.125.200.99 www.google.com. 479 IN A 74.125.200.104 ;; Query time: 1 msec ;; SERVER: 192.168.88.64#53(192.168.88.64) (UDP) ;; WHEN: Sun Dec 15 23:59:30 CST 2024 ;; MSG SIZE rcvd: 212

[snakwu]

Try the latest commit.

ok了，现在一切正常了，感谢肉鸡大佬😘

[lwb1978]

乱套了呢？一个正常了另一个又失败了。我用dns分流用的smartdns，所以没有感觉😂

[sss9091]

乱套了呢？一个正常了另一个又失败了。我用dns分流用的smartdns，所以没有感觉😂

貌似现在的逻辑就是不劫持内网DNS请求了，只劫持目的地址为路由器本机的DNS请求，但走自定义规则劫持还是有点问题，我等下重新开个issue吧。

[SakuraFallingMad]

最新源码测试一下后，看来本机自建dns好像还是不能套娃了，而且还发现一个关联问题。
1.主开关关闭后，防火墙fw4相关代码貌似没有清除。
2.启用pw后，本机潜在可能的一些端口服务异常。已测试:netdata无法正常打开页面。
3.发现日志报错，代码Mon Dec 16 00:06:25 2024 daemon.err uhttpd[3897]: lua: /usr/share/passwall/helper_dnsmasq.lua:93: attempt to concatenate field 'TMP_PATH' (a nil value) Mon Dec 16 00:06:25 2024 daemon.err uhttpd[3897]: stack traceback: Mon Dec 16 00:06:25 2024 daemon.err uhttpd[3897]: /usr/share/passwall/helper_dnsmasq.lua:93: in function 'func' Mon Dec 16 00:06:25 2024 daemon.err uhttpd[3897]: /usr/share/passwall/helper_dnsmasq.lua:675: in main chunk Mon Dec 16 00:06:25 2024 daemon.err uhttpd[3897]: [C]: ?

[sss9091]

我也看到了日志报错：

Sun Dec 15 23:18:28 2024 daemon.err uhttpd[2160]: lua: /usr/share/passwall/helper_dnsmasq.lua:93: attempt to concatenate field 'TMP_PATH' (a nil value)
Sun Dec 15 23:18:28 2024 daemon.err uhttpd[2160]: stack traceback:
Sun Dec 15 23:18:28 2024 daemon.err uhttpd[2160]: 	/usr/share/passwall/helper_dnsmasq.lua:93: in function 'func'
Sun Dec 15 23:18:28 2024 daemon.err uhttpd[2160]: 	/usr/share/passwall/helper_dnsmasq.lua:675: in main chunk
Sun Dec 15 23:18:28 2024 daemon.err uhttpd[2160]: 	[C]: ?

[snakwu]

现在paopaodns正常了，但国外网页打开不了了，好了一个另一个又有问题😂

[xiaorouji]

@SakuraFallingMad 你這種DNS套娃方式需要自行修改 app.sh 的 local RUN_NEW_DNSMASQ=1 將其值改為 0

[SakuraFallingMad]

@SakuraFallingMad 你這種DNS套娃方式需要自行修改 app.sh 的 local RUN_NEW_DNSMASQ=1 將其值改為 0

#3568 (comment) 最新的commit 仍需要手动修改RUN_NEW_DNSMASQ参数吗？看到最新的commit做了开关

[smateoliu]

但凡是LEDE的路由在更新这个版本之后，功能全部不正常了。我敢推测几天后issues区肯定是一片“热闹的”景象。

[snakwu]

现在paopaodns正常了，但国外网页打开不了了，好了一个另一个又有问题😂

再拉最新代码后，这次就一切正常了，用下来没什么问题了，再次感谢肉鸡大佬

[snakwu]

但凡是LEDE的路由在更新这个版本之后，功能全部不正常了。我敢推测几天后issues区肯定是一片“热闹的”景象。

但凡用过lede的都知道，lede里面加了一堆东西，谁知道加了什么，再说lede本身就有ssr，lede是强制劫持dns的，个人觉得没必要强制劫持，还是喜欢passwall，一开始是无劫持，现在更是让用户自己选项劫持，更是人性化。

[sss9091]

但凡是LEDE的路由在更新这个版本之后，功能全部不正常了。我敢推测几天后issues区肯定是一片“热闹的”景象。

什么叫“全部不正常”，最新源码我LEDE上一切正常。

[smateoliu]

但凡是LEDE的路由在更新这个版本之后，功能全部不正常了。我敢推测几天后issues区肯定是一片“热闹的”景象。

什么叫“全部不正常”，最新源码我LEDE上一切正常。

抱歉，我的意思是更新版本后，当DNS重定向开启时，通过代理访问的网站通通不会返回DNS解析结果。
除非前往 /usr/share/passwall/app.sh 把 RUN_NEW_DNSMASQ 修改为 0。
我使用的是基于lede的编译的固件，目的是让在伊朗的朋友能通过代理使用我家住宅宽带访问互联网。

[SakuraFallingMad]

按我的环境小结一下，8e597413231620d34374a6d4d4a2a2bcd39e7978 版本后出现的与以往版本的变化。OP版本是Immortalwrt master snapshot版本。
RUN_NEW_DNSMASQ=1时

1. netdata由于localhost:19999，无法打开。
2. 客户端dns请求方向：client-adg(53port)-dnsmasq(pw接管)-chinadns-ng(smartdns直连|sing-box DoH走代理)因新逻辑不可用。（准备另寻方案或弃用）
3. nftables在luci修改设置时，无法刷新，需要点击清空nftset按钮。（观测貌似是老问题？）

RUN_NEW_DNSMASQ=0时，

1. 观测日志发现，在‘开始加载防火墙规则’后卡顿。（在设置RUN_NEW_DNSMASQ =0，并未重启op时复现；重启后无复现）
2. 观测日志发现，复现pw反复重启。重启op后可以复现。

[snakwu]

按我的环境小结一下，8e597413231620d34374a6d4d4a2a2bcd39e7978 版本后出现的与以往版本的变化。OP版本是Immortalwrt master snapshot版本。 RUN_NEW_DNSMASQ=1时

1. netdata由于localhost:19999，无法打开。
2. 客户端dns请求方向：client-adg(53port)-dnsmasq(pw接管)-chinadns-ng(smartdns直连|sing-box DoH走代理)因新逻辑不可用。（准备另寻方案或弃用）
3. nftables在luci修改设置时，无法刷新，需要点击清空nftset按钮。（观测貌似是老问题？）

RUN_NEW_DNSMASQ=0时，

1. 观测日志发现，在‘开始加载防火墙规则’后卡顿。（在设置RUN_NEW_DNSMASQ =0，并未重启op时复现；重启后无复现）
2. 观测日志发现，复现pw反复重启。重启op后可以复现。

你adg和smatdns都是建在op？个人感觉这是all in boom啊，我是建在独立的内网主机

[snakwu]

@xiaorouji 大佬，修复一下访问控制呗，只要加进访问控制的设备都无法访问国外，国内正常，无论是全局代理还是中国例表外都不行，因为我全局是用gfw模式，有些设备想要中国列表外或全局，只要加进去访问控制的，都只能国内，谢谢

[SakuraFallingMad]

按我的环境小结一下，8e597413231620d34374a6d4d4a2a2bcd39e7978 版本后出现的与以往版本的变化。OP版本是Immortalwrt master snapshot版本。 RUN_NEW_DNSMASQ=1时

1. netdata由于localhost:19999，无法打开。
2. 客户端dns请求方向：client-adg(53port)-dnsmasq(pw接管)-chinadns-ng(smartdns直连|sing-box DoH走代理)因新逻辑不可用。（准备另寻方案或弃用）
3. nftables在luci修改设置时，无法刷新，需要点击清空nftset按钮。（观测貌似是老问题？）

RUN_NEW_DNSMASQ=0时，

1. 观测日志发现，在‘开始加载防火墙规则’后卡顿。（在设置RUN_NEW_DNSMASQ =0，并未重启op时复现；重启后无复现）
2. 观测日志发现，复现pw反复重启。重启op后可以复现。

你adg和smatdns都是建在op？个人感觉这是all in boom啊，我是建在独立的内网主机

日常来说，dns services运行于op是基本上可以的，目前不主动重启没有见到发生问题。只要别用docker。。。。。。。这是 all in boom 的基础。

[snakwu]

按我的环境小结一下，8e597413231620d34374a6d4d4a2a2bcd39e7978 版本后出现的与以往版本的变化。OP版本是Immortalwrt master snapshot版本。 RUN_NEW_DNSMASQ=1时

1. netdata由于localhost:19999，无法打开。
2. 客户端dns请求方向：client-adg(53port)-dnsmasq(pw接管)-chinadns-ng(smartdns直连|sing-box DoH走代理)因新逻辑不可用。（准备另寻方案或弃用）
3. nftables在luci修改设置时，无法刷新，需要点击清空nftset按钮。（观测貌似是老问题？）

RUN_NEW_DNSMASQ=0时，

1. 观测日志发现，在‘开始加载防火墙规则’后卡顿。（在设置RUN_NEW_DNSMASQ =0，并未重启op时复现；重启后无复现）
2. 观测日志发现，复现pw反复重启。重启op后可以复现。

你adg和smatdns都是建在op？个人感觉这是all in boom啊，我是建在独立的内网主机

日常来说，dns services运行于op是基本上可以的，目前不主动重启没有见到发生问题。只要别用docker。。。。。。。这是 all in boom 的基础。

反正个人觉得，dns还是独立开来比较好，我现在就是官方源码加个passwall，其它所有功能独立开来，其它的主机都不会去动到它，不会说op出问题了，所有全失效

[xcyll]

@xiaorouji 大佬，修复一下访问控制呗，只要加进访问控制的设备都无法访问国外，国内正常，无论是全局代理还是中国例表外都不行，因为我全局是用gfw模式，有些设备想要中国列表外或全局，只要加进去访问控制的，都只能国内，谢谢

访问控制里的 远程DNS你是想用自定义DNS服务器 192.168.88.63？
dns2socks不支持这种吧

[xcyll]

[xcyll]

前三种支持这种使用方式 ，访问控制 里过滤模式精简了 没有加入这些
访问控制下的不支持自定义DNS

[snakwu]

前三种支持这种使用方式 ，访问控制 里过滤模式精简了 没有加入这些 访问控制下的不支持自定义DNS

好的明白了，我记得旧版本是没问题一直用😂，不知道为什么