[Bug]: 7.18更新4.78-1版本，分流时忘更改默认节点(直连)时会直接卡死

kylongteng commented 3 months ago

描述您遇到的bug

7.18更新4.78-1版本，分流时忘更改默认节点(直连)时会直接卡死（上个版本已验证不会出现）

复现此Bug的步骤

分流时忘更改默认节点(直连)时会直接卡死

您想要实现的目的

分流时忘更改默认节点(直连)时不直接卡死

日志信息

2024/07/18 15:32:17 192.168.1.1:51844 accepted tcp:1.1.1.1:53 [tcp_redir -> direct] 出现在6秒内出现5000多次请求DNS服务器，不仅pw卡死，宿主机openwrt直接宕机！

截图

1721289245669 1721289314785

系统相关信息

pw:4.78-1 浏览器: 124.0.2478.51 (正式版本) (64 位) openwrt： lede-git-24.182.36151-66d29de

其他信息

100%复现，只能强制重启赶在pw尚未自动启动前将其关掉

Leung808 commented 3 months ago

@xiaorouji DNS 好像确实有点问题，我用 ipk 升级了一下直接国外网站没办法解析，清空 IPSET 后才恢复正常。

Leung808 commented 3 months ago

@xiaorouji @nftbty 楼主的问题我这里测试也是一样，并且我确认了和 ChinaDNS-NG 以及 DNS 重定向无关，只要 Xray 默认节点是直连就能复现，路由器连接数暴增，直到挂掉。另外，如果分流使用 Sing-Box，即使默认节点是直连，虽然也无法解析域名，但不会出现 Xray 这样连接数暴增的情况。

所以除了新版本中 DNS 相关的代码可能有些问题，Xray 的逻辑是不是也有点问题？@nftbty

这是 Xray 的日志（日志中包含我的公网 IP 隐去了）：

Xray 1.8.16 (Xray, Penetrates Everything.) OpenWrt (go1.22.1 linux/amd64)
A unified platform for anti-censorship.
2024/07/22 09:03:34 [Info] infra/conf/serial: Reading config: /tmp/etc/passwall/acl/default/TCP_UDP_SOCKS.json
2024/07/22 09:03:38 -:56912 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56920 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56924 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56934 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56950 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56958 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56964 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56974 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:56986 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57000 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57006 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57016 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57024 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57040 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57046 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57052 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]
2024/07/22 09:03:38 -:57068 accepted tcp:1.1.1.1:53 [tcp_redir -> direct]

这是 Sing-Box 的日志：

+0000 2024-07-22 09:11:41 ERROR [2722230105 0ms] inbound/redirect[redirect_tcp]: process connection from -:38274: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:41 ERROR [1697290690 0ms] inbound/redirect[redirect_tcp]: process connection from -:38288: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:43 ERROR [1538811469 0ms] inbound/redirect[redirect_tcp]: process connection from -:38312: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:43 ERROR [2052750378 0ms] inbound/redirect[redirect_tcp]: process connection from -:38336: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:46 ERROR [1909111128 0ms] inbound/redirect[redirect_tcp]: process connection from -:56338: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:47 ERROR [3150157650 0ms] inbound/redirect[redirect_tcp]: process connection from -:56364: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:48 ERROR [936476605 0ms] inbound/redirect[redirect_tcp]: process connection from -:56378: reject loopback connection to 1.1.1.1:53
+0000 2024-07-22 09:11:48 ERROR [2183134432 0ms] inbound/redirect[redirect_tcp]: process connection from -:56398: reject loopback connection to 1.1.1.1:53

kylongteng commented 3 months ago

@xiaorouji DNS 好像确实有点问题，我用 ipk 升级了一下直接国外网站没办法解析，清空 IPSET 后才恢复正常。

除了openclash，包括psw在内的几个一般不会出太大问题，逻辑相对要简单些，bug就要少些，偶尔抽风一下还是能接受的。哈~

lwb1978 commented 3 months ago

能否再说明下是用iptables还是nftables，tcp代理方式是tproxy还是redirect，方便其他大佬们判断。

Leung808 commented 3 months ago

能否再说明下是用iptables还是nftables，tcp代理方式是tproxy还是redirect，方便其他大佬们判断。

我是 iptables，tcp 代理是 redirect

kylongteng commented 3 months ago

能否再说明下是用iptables还是nftables，tcp代理方式是tproxy还是redirect，方便其他大佬们判断。

肯定是iptables，至于tproxy还是redirect不记得了

lwb1978 commented 3 months ago

4.77-6到4.78-1之间iptables就我增加了dns重定向功能，而且 @Leung808 也确定了与这个无关，这两个版本之间 @nftbty 也没更新过xray代码，@xiaorouji 添加的dns代码看上去似乎也没什么问题，不知道哪个环节出了情况。

kylongteng commented 3 months ago

4.77-6到4.78-1之间iptables就我增加了dns重定向功能，而且 @Leung808 也确定了与这个无关，这两个版本之间 @nftbty 也没更新过xray代码，@xiaorouji 添加的dns代码看上去似乎也没什么问题，不知道哪个环节出了情况。

问题应该很好复现，可以测试一下

Leung808 commented 3 months ago

尝试了一下前段时间编译的版本 5273e74192b82e9895bdc2a2ae76ca7a7a7c51e3 问题仍然可以复现，尝试开启或关闭 dns 重定向均可以复现，所以应该不是 dns 重定向的问题，也不是后续提交的代码的问题。

我编译的更早的版本已经清理掉了，或许楼主可以分享一下具体哪个 commit 是正常的，缩小排查范围。

Leung808 commented 3 months ago

我下载 4.77-6 ipk 安装试了下也是有问题的，楼主所说的上一个版本具体是哪一个？

kylongteng commented 3 months ago

我下载 4.77-6 ipk 安装试了下也是有问题的，楼主所说的上一个版本具体是哪一个？

应该是上周，我用lede和kenzok8仓库构建的x86，kenzok8里的psw是及时更新的，我当时也是同样的误操作没有宕机。具体的版本号没保存，我这一天搞好几个版本的折腾，只留了一个pve的备份在崩了的时候还原……

lwb1978 commented 3 months ago

不会是上周版本，4.77-6已经发布了将近两个月了，既然4.77-6都存在问题，那么上周的代码也是有问题的。

kylongteng commented 3 months ago

不会是上周版本，4.77-6已经发布了将近两个月了，既然4.77-6都存在问题，那么上周的代码也是有问题的。

这个不确定，我印象中，大概月初的时候看了一眼kenzok8里psw的更新时间，当时显示大概几天前，也就是说我当时没问题的版本是上个月底差不多

Leung808 commented 3 months ago

无视刚刚的回复，我再测一下

lwb1978 commented 3 months ago

无视刚刚的回复，我再测一下

辛苦测试

Leung808 commented 3 months ago

我目前测试的结果有些离谱，近几个月的版本似乎都存在问题，可能定位到了首个有问题的版本：

4.75-3 正常，可能无法解析，但不会连接数暴增，Sing-Box 也不会报拒绝环回连接的错误 4.75-4 异常，连接数暴增，Sing-Box 出现拒绝环回连接报错

建议楼主也试试是不是这样，软件包里先移除 luci-app-passwall 和 luci-i18n-passwall-zh-cn，然后安装 4.75-4 的两个 ipk，看看问题是否还存在，然后再试试 4.75-3 的版本

kylongteng commented 3 months ago

我目前测试的结果有些离谱，近几个月的版本似乎都存在问题，可能定位到了首个有问题的版本：

4.75-3 正常，可能无法解析，但不会连接数暴增，Sing-Box 也不会报拒绝环回连接的错误 4.75-4 异常，连接数暴增，Sing-Box 出现拒绝环回连接报错

建议楼主也试试是不是这样，软件包里先移除 luci-app-passwall 和 luci-i18n-passwall-zh-cn，然后安装 4.75-4 的两个 ipk，看看问题是否还存在，然后再试试 4.75-3 的版本

我对这块完全不了解，纯用户。这会儿在折腾小雅alist……只能麻烦你们找问题了……

Leung808 commented 3 months ago

可能导致问题的原因就是 0f87f2cca9b66f71de4f9649f97392a337618a82 避免该问题的方法，是使用分流时，DNS 要选择 Xray 或 Sing-Box。楼主可以试一下，DNS 过滤模式选择 Xray，再将默认节点设置为直连，还会不会出现该问题。

Leung808 commented 3 months ago

4.78-1 版本中，我将 DNS 过滤模式设置为 Xray，再将默认节点设置为直连，没有出现连接数暴增的情况了（虽然可能无法解析，或许是被阻断了），Sing-Box 分流 + Sing-Box DNS 也没有出现拒绝环回连接的报错了。

kylongteng commented 3 months ago

可能导致问题的原因就是 0f87f2c 避免该问题的方法，是使用分流时，DNS 要选择 Xray 或 Sing-Box。楼主可以试一下，DNS 过滤模式选择 Xray，再将默认节点设置为直连，还会不会出现该问题。

我试了，没宕机，和你描述的一样

lwb1978 commented 3 months ago

看了代码，可能是缺少dns的相关配置项，但具体还没摸透代码，不知道如何下手，看大佬能否出山。 @xiaorouji

solarflows commented 3 months ago

我感觉和刚刚更换自动切换的配置界面的时候我遇到的问题差不多，没猜错的话就是dns的地址是要代理的，但是被导向了不代理，导致了像广播风暴一样的问题，最后连接数boom，内核panic。

lwb1978 commented 3 months ago

@Leung808 因我在外地无测试环境，我随手改了一下脚本，你是否有空测试看是否能行。下载文件后去掉.txt后缀，查看文件是否是unix utf-8后上传到路由usr/share/passwall测试一下，脚本对应程序版本为4.78-1。其实就是尝试在不使用xray或sing-box作为dns程序时给他们补上远程dns地址。

app.sh.txt

Leung808 commented 3 months ago

@Leung808 因我在外地无测试环境，我随手改了一下脚本，你是否有空测试看是否能行。下载文件后去掉.txt后缀，查看文件是否是unix utf-8后上传到路由usr/share/passwall测试一下，脚本对应程序版本为4.78-1。其实就是尝试在不使用xray或sing-box作为dns程序时给他们补上远程dns地址。

app.sh.txt

测试这个 app.sh Xray 还是会连接数暴增 Sing-Box 有点奇怪，即使选择了正确的默认节点，DNS 过滤模式如果是 TCP，DNS 直接挂掉了，geo 文件都无法更新

[31mFATAL[0m[0000] start service: Get "https://github.com/1715173329/sing-geoip/releases/latest/download/geoip.db": dial tcp 127.0.0.1:1081: connect: connection refused
connect: connection refused
+0000 2024-07-23 09:44:37 ERROR router: download geoip database: Get "https://github.com/1715173329/sing-geoip/releases/latest/download/geoip.db": dial tcp 127.0.0.1:1081: connect: connection refused
+0000 2024-07-23 09:44:37 ERROR router: download geoip database: Get "https://github.com/1715173329/sing-geoip/releases/latest/download/geoip.db": dial tcp 127.0.0.1:1081: connect: connection refused

Sing-Box 也是依旧报错环回：

+0000 2024-07-23 09:50:21 ERROR [354670312 0ms] inbound/redirect[redirect_tcp]: process connection from xxxx:33212: reject loopback connection to 1.1.1.1:53
+0000 2024-07-23 09:50:22 ERROR [1427565706 0ms] inbound/redirect[redirect_tcp]: process connection from xxxx:33232: reject loopback connection to 1.1.1.1:53
+0000 2024-07-23 09:50:22 ERROR [2294017295 0ms] inbound/redirect[redirect_tcp]: process connection from xxxx:33248: reject loopback connection to 1.1.1.1:53

另外，其实 UDP 模式也是有一样的情况，[ "${DNS_MODE}" != "udp" ] 这个条件可以去掉吧，除非不开启 UDP 节点。

Leung808 commented 3 months ago

感觉这个问题比较棘手，补上 dns 也不是最佳的解决办法吧😂，可能要去改 Passwall 自身的逻辑，因为 1.1.1.1 需要被代理，但分流又选择了直连，流量又回到 Passwall，Passwall 又丢给分流处理（个人理解哈，这块我了解的不太多，类似楼上说的广播风暴的问题吧）。

lwb1978 commented 3 months ago

个人能力问题，我是搞不掂了，看其他大佬是否能出手。

xiaorouji commented 3 months ago

As a workaround, add 1.1.1.1 to the shunt rules, and select a node to parse.

xiaorouji commented 3 months ago

Xray's built-in DNS currently still does not seem to support let different DNS servers go through different outbound routes.

xiaorouji commented 3 months ago

I haven't used Xray for a long time. I use Sing-Box return country watch streaming media.

solarflows commented 3 months ago

捕捉野生大佬

kylongteng commented 3 months ago

其实这个问题从系统角度算是个bug，从用户使用角度来说不是致命伤。准确来说是一种错配，如果无法从根源解决，那就让xray表现和sing-box一样拒绝连接就行……

xiaorouji commented 3 months ago

When using Xray/Sing-box for shunt, be sure to select Xray/Sing-box again in DNS filtering mode, otherwise DNS will not be shunt according to the node.

solarflows commented 3 months ago

it's smartdns branches has the same issues when use Xray/Sing-box for shunt?

xiaorouji commented 3 months ago

If you want to use geo-shunt, why not use Passwall2 ?

In addition, the proxy domain name does not need to customize DNS itself. It is optimal to just let the proxy node request DNS. If you only care about speed, why not use FakeDNS?

xiaorouji commented 3 months ago

I have planned to optimize the logic of using the shunt function in the next version. When using the shunt function, it cannot be work with ChinaDNS-NG and Smartdns, because it is not necessary, and the probability of problems will increase.

solarflows commented 3 months ago

Good idea, but the main reason I use SmartDNS is China Mobile's junk broadband, which often makes the network inaccessible because of DNS.Thank you for your project.

Leung808 commented 3 months ago

I have planned to optimize the logic of using the shunt function in the next version. When using the shunt function, it cannot be work with ChinaDNS-NG and Smartdns, because it is not necessary, and the probability of problems will increase.

捕捉大佬😁

我认为 ChinaDNS-NG 还是有必要的，如果分流模式下不启用 ChinaDNS-NG，且不启用 Sniffing，访问污染域名会有问题，而启用 Sniffing 又会影响 Tor 浏览器。参考其他项目 Home Proxy，已经支持了 ChinaDNS-NG。

英语不太好，以下是机翻：

I think ChinaDNS-NG is still necessary, if you don't enable ChinaDNS-NG in shunt mode and don't enable Sniffing, you will have problems accessing contaminated domains, and enabling Sniffing affects Tor Browser. Refer to other project Home Proxy, ChinaDNS-NG is already supported.

Leung808 commented 3 months ago

刚再测试了一下，确认了该问题和 ChinaDNS-NG 无关。

也许当前最佳的解决办法是：

非分流模式时，DNS 过滤模式可选 TCP/UDP
Xray 分流模式时，DNS 过滤模式仅可选 Xray，TCP/UDP 不可选
Sing-Box 分流模式时，DNS 过滤模式仅可选 Sing-Box，TCP/UDP 不可选

而 ChinaDNS-NG，能保证在不影响国内解析的情况下，最大程度解决 DNS 污染问题，其实还是有必要的，如果不能搭配 ChinaDNS-NG 使用，可能会存在这些问题：

不在 gfwlist 内，但是被污染的域名，在未启用 Sniffing 的情况下无法访问。
启用 Sniffing 后，虽然可以解决问题 1，但是可能会有一些奇怪的问题，比如 Tor 浏览器，又或者会不会有更多像“排除域名”中的那些不规范域名，导致某些软件无法正常使用。而且 Sing-Box 是没有排除列表的，一定是会有一些影响的。
不在 Chnlist 内的国内域名，如果其同时存在国内 + 国外 CDN，直接交给 Xray DNS 处理应该会解析到国外。

另外，感觉 SmartDNS 分支或许可以合并到主分支了，已经测试了那么久看起来没什么问题了，有时候主分支做了修改，但又没能同步到 SmartDNS 分支。

以上仅是个人建议哈，希望能让 Passwall 再次伟大~

kylongteng commented 3 months ago

If you want to use geo-shunt, why not use Passwall2 ?

In addition, the proxy domain name does not need to customize DNS itself. It is optimal to just let the proxy node request DNS. If you only care about speed, why not use FakeDNS?

首先，感谢大佬回复。其实前几天我在passwall2提了一个功能优化：https://github.com/xiaorouji/openwrt-passwall2/issues/619 几款同类型产品中我还是觉得passwall(2)两款最适合，我想用分流，2确实分流更优秀运行更流畅，但是2在变更配置时会闪断。如果能解决这个问题，我肯定使用2去了。期待大佬将来时机成熟时能把https://github.com/xiaorouji/openwrt-passwall2/issues/619#issuecomment-2245616688这个自用的软件公开出来……

kylongteng commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

wtfr-dot commented 3 months ago

dns分流还是尽量不用xray，我现在用dnsmasq+chinadns-ng搭配smartdns用起来很好

lwb1978 commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

引用这个讨论，https://github.com/xiaorouji/openwrt-passwall/discussions/3309

kylongteng commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

引用这个讨论，#3309

果然没有一个是完美的

lwb1978 commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

引用这个讨论，#3309

果然没有一个是完美的

所以起初homeproxy就只有一个sing-box一个内核，就相当于sing-box的ui，现在也默默的加上了chinadns-ng

wtfr-dot commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

引用这个讨论，#3309

果然没有一个是完美的

我觉得专业的事情专业做，dns解析我就选smartdns，dns分流目前好像只有chinadns-ng比较合适，xray适合抗审查代理，singbox接管tun，可惜目前不能完美结合，特别是singbox接管的东西太多，与xray等兼容性不好，它自成一派的规则集跟其它都不兼容，而且我发现它的广告过滤误伤比较大，奈飞的某些亚马逊cdn ip会被block

kylongteng commented 3 months ago

分流的話，我認為Sing-Box功能更齊全，更符合應用於透明代理環境。而Xray嘅內置DNS功能無咁多功能。如果唔在意DNS和隱私問題，FakeDNS係最好用嘅。

从我用户角度来说我是赞同你的观点的。因为就目前而言，sing-box支持的协议更多，性能与xray比也不差。其实我上午就想问问，passwall和passwall2目前已经支持换成sing-box代理，但是内核依然是xray，不知内核换成sing-box工作量多大。我每次编译openwrt时，选择passwall(2)时，为了编译的更快，一般只会保留iptables、haproxy和xray，但是因为hy2协议的原因，编译完后又会在passwall(2)里手动下载hy2客户端，如果默认是sing-box内核的话，就不用多此一举了。

引用这个讨论，#3309

果然没有一个是完美的

我觉得专业的事情专业做，dns解析我就选smartdns，dns分流目前好像只有chinadns-ng比较合适，xray适合抗审查代理，singbox接管tun，可惜目前不能完美结合，特别是singbox接管的东西太多，与xray等兼容性不好，它自成一派的规则集跟其它都不兼容，而且我发现它的广告过滤误伤比较大，奈飞的某些亚马逊cdn ip会被block

dns这个东西要么不折腾，要么简单用用smartdns就足够了，我自己是用了smartdns，但是是放在docker里面的。如果真要折腾，那必然会想用openclash，或者套娃，会浪费很多的时间……

lwb1978 commented 3 months ago

我觉得这个帖子比较有意义，重新打开了。

kylongteng commented 3 months ago

我觉得这个帖子比较有意义，重新打开了。

ok

Hyyyy11 commented 3 months ago

一直在看你们讨论，我也来提提我的建议。

@xiaorouji 大佬的优化思路是：使用分流功能时，无法和 ChinaDNS-NG 和 Smartdns 一起使用，因为没有必要并且会增加出现问题的概率。但我不建议这样做，ChinaDNS-NG 和 Smartdns 各有各的优势，能混合使用也是 Passwall 的优势，这个 Issue 所提到的问题其实和他们没什么关系。

@Leung808 的优化思路是：使用分流功能时，过滤模式只能选择对应的分流工具。我也不建议这么做，比如 Sing-Box 之前就存在 DNS 截断的问题，会影响在 Linux 中的一些网络请求，目前 Sing-Box 似乎只是修改了截断的大小，从 512B 改为 1024B，没有按照传统的 DNS 逻辑对响应进行压缩。虽然 DNS 路由是 Sing-Box 的优势，但我目前仍然不会考虑使用 Sing-Box DNS。

@kylongteng 提到将 Sing-Box 作为默认分流内核，这个其实倒是无所谓，因为切换很方便，在 Passwall 没有正式切换之前，可以在编译前修改 0_default_config 以达成默认使用 Sing-Box 的目的。

另外一些想法：之前我有提到，使用 ChinaDNS-NG 时，可以自定义直连 DNS，支持使用 DoT 作为直连 DNS 上游（防止运营商投毒），这样我就可以省去配置 Smartdns 或者 AdGuard Home 的步骤了，因为 ChinaDNS-NG 本身支持使用 DoT，但目前看只是加入了直连 DNS 的选项，并不支持 DoT 上游，其实这样是没有意义的，直接去 WAN 接口或者 DNS 转发里面修改就行。

Smartdns 合并到主线也是时候可以考虑起来了吧？

kylongteng commented 3 months ago

一直在看你们讨论，我也来提提我的建议。

@xiaorouji 大佬的优化思路是：使用分流功能时，无法和 ChinaDNS-NG 和 Smartdns 一起使用，因为没有必要并且会增加出现问题的概率。但我不建议这样做，ChinaDNS-NG 和 Smartdns 各有各的优势，能混合使用也是 Passwall 的优势，这个 Issue 所提到的问题其实和他们没什么关系。

@Leung808 的优化思路是：使用分流功能时，过滤模式只能选择对应的分流工具。我也不建议这么做，比如 Sing-Box 之前就存在 DNS 截断的问题，会影响在 Linux 中的一些网络请求，目前 Sing-Box 似乎只是修改了截断的大小，从 512B 改为 1024B，没有按照传统的 DNS 逻辑对响应进行压缩。虽然 DNS 路由是 Sing-Box 的优势，但我目前仍然不会考虑使用 Sing-Box DNS。

@kylongteng 提到将 Sing-Box 作为默认分流内核，这个其实倒是无所谓，因为切换很方便，在 Passwall 没有正式切换之前，可以在编译前修改 0_default_config 以达成默认使用 Sing-Box 的目的。

另外一些想法：之前我有提到，使用 ChinaDNS-NG 时，可以自定义直连 DNS，支持使用 DoT 作为直连 DNS 上游（防止运营商投毒），这样我就可以省去配置 Smartdns 或者 AdGuard Home 的步骤了，因为 ChinaDNS-NG 本身支持使用 DoT，但目前看只是加入了直连 DNS 的选项，并不支持 DoT 上游，其实这样是没有意义的，直接去 WAN 接口或者 DNS 转发里面修改就行。

Smartdns 合并到主线也是时候可以考虑起来了吧？

我只是打酱油的，不专业，完全从用户角度出发。我为什么把smartdns装在docker里面，就是因为我一直纠结用不用它，我有时候感觉它没用，有时候又发现它又有用。如果真的把smartdns合并进来，我感觉有用，至少我少折腾个插件……

xiaorouji / openwrt-passwall