使用「Xray 分流：分流总节点」导致TCP连接数量暴涨

Gabirel commented 2 years ago

描述bug

使用「Xray 分流：分流总节点」，TCP连接多到“爆炸”，TCP连接主要为域名：1e100.net
使用普通代理节点，TCP连接正常

复现步骤

xray + xray分流总节点
开启自动切换（不确定是否有影响）
开启守护进程（不确定是否有影响）
查看ssh，命令netstat | grep tcp

你想要实现的目的

在使用Xray分流总节点掉情况下，TCP连接数正常即可

日志信息

个人觉得有用信息比较少

2021-12-31 12:53:36: 删除相关防火墙规则完成。
2021-12-31 12:53:36: 清空并关闭相关程序和缓存完成。
2021-12-31 12:53:37:   - 域名解析 DNS Over HTTPS...
2021-12-31 12:53:37: UDP节点没有选择或为空，不代理UDP。
2021-12-31 12:53:37: 过滤服务配置：准备接管域名解析...
2021-12-31 12:53:37:   | - (chinadns-ng) 最高支持4级域名过滤...
2021-12-31 12:53:37:   | - [0](chinadns-ng) 代理域名表合并到防火墙域名表
2021-12-31 12:53:37:   | - [0](chinadns-ng) 域名白名单合并到中国域名表
2021-12-31 12:53:37:   + 过滤服务：ChinaDNS-NG(:7914)：国内DNS：127.0.0.1#5553，可信DNS：127.0.0.1#7913
2021-12-31 12:53:37:   - [0]节点列表中的域名(vpsiplist)：127.0.0.1#5553
2021-12-31 12:53:37:   - [0]域名白名单(whitelist)：127.0.0.1#5553
2021-12-31 12:53:37:   - [0]代理域名表(blacklist)：127.0.0.1#7913
2021-12-31 12:53:37:   - [0]V2ray/Xray分流规则(shuntlist)：127.0.0.1#7913
2021-12-31 12:53:37:   - [0]防火墙域名表(gfwlist)：默认
2021-12-31 12:53:42:   - [0]中国域名表(chnroute)：默认
2021-12-31 12:53:44:   - [0]以上所列以外及默认(ChinaDNS-NG)：127.0.0.1#7914
2021-12-31 12:53:44:   - PassWall必须依赖于Dnsmasq，如果你自行配置了错误的DNS流程，将会导致域名(直连/代理域名)分流失效！！！
2021-12-31 12:53:44: 开始加载防火墙规则...
2021-12-31 12:53:44: 加入负载均衡的节点到ipset[vpsiplist]直连完成
2021-12-31 12:53:44: 加入所有节点到ipset[vpsiplist]直连完成
2021-12-31 12:53:44: 加载路由器自身 TCP 代理...
2021-12-31 12:53:44:   - 启用 TPROXY 模式
2021-12-31 12:53:45: TCP默认代理：使用TCP节点[分流总节点] [中国列表以外](TPROXY:1041)代理所有端口
2021-12-31 12:53:45: 防火墙规则加载完成！
2021-12-31 12:53:45: 重启 dnsmasq 服务
2021-12-31 12:53:45: 配置定时任务：自动更新规则。
2021-12-31 12:53:45: 配置定时任务：自动更新【奇怪的订阅】订阅。
2021-12-31 12:53:45: 运行完成！

截图

正常情况截图（使用正常节点）

PS: 即使保持一段时间后，这个TCP的链接数量也是在可控范围

异常情况截图（使用Xray分流节点）

netstat | grep tcp | grep ESTABLISHED

截图为部分内容：（短时间内激增，是激增没错）

PS：100.66.186.57是wan的分配给软路由的IP地址，因此可见是软路由自身的行为。

统计个数：

$ netstat | grep tcp | grep ESTABLISHED | wc -l
65489

系统相关信息

LuCI: Master (git-21.335.48743-5f363d9)
OpenWrt: Ipv6-S2021.12.19 by Sirpdboy
Xray: 1.4.5
passwall版本怎么看？反正是latest
Xray分流：分流总结点配置情况如下

展开我
![image](https://user-images.githubusercontent.com/12933851/147803808-bda5b257-aeb1-4b47-8298-fd59b7b2e4c7.png)

其他相关信息

切换xray版本不影响本issue（包括了最新的1.5.2）
规则列表（优先级最高的列表）中block掉1e100.net无效
在AD这个rules中加了domain:1e100.net，仍然看到TCP连接。可见没有遵循Xray分流总节点的规则
查看相关程序信息，可以确定是xray发出的（应该吧）
二次确认不是xray的问题。查看服务端都是正常的；另一个备用的软路由用了ss-tproxy + xray的组合，tcp也正常
```
# 服务端的tcp连接数量 - xray服务
$ netstat | grep tcp | grep ESTABLISHED | wc -l
39
```
关闭自动切换和守护进程，没有变化，确定没有影响
DNS设置如下：（DNS使用默认的pdnsd亦没有对该问题有变化）

展开我
![image](https://user-images.githubusercontent.com/12933851/147804894-1fe8f709-5297-47bf-a6c1-01a619d7e165.png)
关闭passwall就一定没有这个问题，或者，使用非xray分流总节点也一定没有问题
怀疑：是不是什么passwall的组件的问题？尤其是涉及到了Xray分流总节点才会发生，其他都不会发生。让我不禁怀疑

最终解决办法

查看最底部：https://github.com/xiaorouji/openwrt-passwall/issues/1677#issuecomment-1014203396

xiaorouji commented 2 years ago

未出现过，看看有没有其他人有这种情况吧。

xiaorouji commented 2 years ago

1e100.net 这个域名应该是google的，不过不知道是什么用的。系统 - 软件包 - luci-app-passwall 后有版本号另外想问下你是127.0.0.1#5553是自己配置的第三方国内DNS吗？

Gabirel commented 2 years ago

1e100.net的确是google的。在Loyalsoldier/v2ray-rules-dat中也有被block（但是没有block全），我就尝试直接domain:1e100.net全block了，虽然没有用
luci-app-passwall版本号：4.44-1
- 我看commit，到最新的版本没有什么太多的跟此issue可能相关的commit
DNS是AdGuardHome作为dnsmasq的上游设置的
- 不过的确软路由偶尔会出现DNS解析的问题，我看其他issue也有这样的问题，不知道是否有影响

看还有什么我可以提供的

smallprogram commented 2 years ago

最新源码编译passwall 测了一下午，xray分流+xray，各种刷网站，三台设备一起刷，最高237，最低39。与你的设置唯一的区别就是没有用AdGuradHome作为上游DNS，直接用dnsmasq。无法复现你的问题。

Gabirel commented 2 years ago

辛苦感谢大佬的一下午的测试

相关测试更新：

我关闭了ADGuard Home的，问题依旧。
直接用dnsmasq是指的不使用任何的DNS吗？（均已经关闭ADGuard Home的情况下）
- 我把DNS过滤关了，就正常了
- 如果开启任何DNS过滤（至少pdnsd和xray模式），也会导致这一问题
若开启ADGuard Home且不开启DNS过滤，是否也会导致呢？这个暂时没有时间测试，很抱歉。若有需要，后面我可以再补上来
- 个人猜测不是ADGuard Home的问题，目前大概率确定DNS的过滤模式问题。是否是ADGuard Home + DNS过滤才导致的，尚且不知

smallprogram commented 2 years ago

我测试的时候，DNS设置

DNS过滤模式使用的是pdnsd
缓存解析结果未勾选，
远程DNS 8.8.8.8
ChinaDNS-NG开启

Xray分流，与你的设置一致，默认节点是xray+vless+xtls

没有出现你说的问题

Gabirel commented 2 years ago

奇怪…因为我也测试过DNS过滤，也测过不缓存DNS（虽然个人觉得缓存应该和这个没有影响）（在ADGuard Home开始的情况下）

因为元旦，不太方便继续测试。当可以方便测试的时候，我再重新测试一下

realJustinLee commented 2 years ago

@Gabirel 我似乎也有同样的问题，passwall的DNS 和 tcp会有大量增长导致内存短时间内oom，我尝试给到10G的内存，发现在一般情况下passwall在最近两次 commit下都会短时间内吃到6～8G然后回落到100+mb

Gabirel commented 2 years ago

我测试的时候，DNS设置

DNS过滤模式使用的是pdnsd

缓存解析结果未勾选，

远程DNS 8.8.8.8

ChinaDNS-NG开启

Xray分流，与你的设置一致，默认节点是xray+vless+xtls

没有出现你说的问题

@smallprogram

环境更新：现在重装了虚拟化，然后用了LuCI Master (git-21.335.48743-5f363d9)固件，passwall版本号为：4.45-1

相同设置（but fresh installation），可是我还是有这样的问题。不过这次由于分配性能不一样，但是同样TCP链接数量激增，导致内存直接超过了说分配的1GB，然后passwall的xray程序就没了

另1：无论是否开启ChinaDNS-NG都会导致该问题出现。另2：经过测试，若开启DNS结果缓存，必定会导致该问题（经过测试，4次测试下4次完全复现，100%概率）

@Gabirel 我似乎也有同样的问题，passwall的DNS 和 tcp会有大量增长导致内存短时间内oom，我尝试给到10G的内存，发现在一般情况下passwall在最近两次 commit下都会短时间内吃到6～8G然后回落到100+mb

@realJustinLee 我的软路由环境最多只有4GB空间，完全够不到8GB，内存是否有回落现象，这个我不能确定了～

目前我平时需要使用，只能暂时放弃「Xray分流：总节点」。希望可以修复，我就可以切过去了

Gabirel commented 2 years ago

Update：看到隔壁pandavan固件的通告说dnsmasq 2.86 会在加载过多规则时卡死退回2.80版本

于是打算自己尝试一下会退到2.80版本以排除目前版本2.86的因素。

结果安装出现依赖无法满足的问题：

遂，这个尝试暂时做不了～不知道是否有其他勇士测试一下

xiaorouji commented 2 years ago

Update：看到隔壁pandavan固件的通告说dnsmasq 2.86 会在加载过多规则时卡死退回2.80版本

于是打算自己尝试一下会退到2.80版本以排除目前版本2.86的因素。

结果安装出现依赖无法满足的问题：

遂，这个尝试暂时做不了～不知道是否有其他勇士测试一下

这个dnsmasq 2.86 规则太多的确会卡死，我刚才试了一下直接用dnsmasq-chinalist而不用chinadns-ng直接挂了。。

Gabirel commented 2 years ago

@xiaorouji

我这边有一个疑问，就是即使使用了dnsmasq，但是我的分流规则里是屏蔽了1e100.net的，理论上来说，都被屏蔽了dnsmasq还会加载？还会导致卡死？应该不会吧
所以为了使用分流节点，要把chinadns-ng勾了就行？我的测试经验下来，好像这样不能解决这个问题

xiaorouji commented 2 years ago

不知我这里正常

NiceNicks commented 2 years ago

我前几天刷最新版本，也出现了passwall 太多分流规则，每次保存配置后一直处于loading的状态。

Gabirel commented 2 years ago

不知我这里正常

经过测试，全局代理 + Xray分流总节点 + chinadns-ng并不能解决问题。所以还是分流总节点模式出现的问题

另外，是不是我可以通过下低版本的openwrt，然后我去安装最新版的passwall，这样来看是不是dnsmasq的版本带来的问题？这样时候可行呢？比如会不会出现无法解决的依赖问题？

Gabirel commented 2 years ago

Update：测试了passwall的4.34-1的分流总结点模式 + dnsmasq 2.85版本，问题依旧……似乎可以排除dnsmasq 2.86版本（除非2.85版本也有问题）

所以目前还是只能将问题定位到passwall身上

Gabirel commented 2 years ago

我看info级别的日志似乎是有环路？怎么一直在tcp:app.smartmailcloud.com:443和tcp:ping.manjaro.org:80，而且都accept了，而且本地软路由肯定可以连接成功的。体现在超短的时间内爆发，然后内存2G打满，又卡死了

详见日志：日志有所截取（因为都是重复的内容）

expand me!

```log 2022/01/15 20:48:11 [Info] [3145943112] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [3025139030] proxy/dokodemo: received request for 100.66.194.120:50022 2022/01/15 20:48:11 [Info] [3145943112] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 100.66.194.120:56688 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [3145943112] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3145943112] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3724500136] proxy/dokodemo: received request for 100.66.194.120:56692 2022/01/15 20:48:11 [Info] [3025139030] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [3025139030] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [3025139030] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [3025139030] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:50022 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [3724500136] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [3724500136] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [3724500136] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 100.66.194.120:56692 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [3724500136] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [2025169742] proxy/dokodemo: received request for 100.66.194.120:50026 2022/01/15 20:48:11 [Info] [441786769] proxy/dokodemo: received request for 100.66.194.120:56696 2022/01/15 20:48:11 [Info] [2025169742] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [2025169742] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [2025169742] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [2025169742] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:50026 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:56696 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [441786769] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [441786769] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [441786769] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3419016757] proxy/dokodemo: received request for 100.66.194.120:50030 2022/01/15 20:48:11 [Info] [441786769] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3419016757] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [3419016757] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [3419016757] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [3419016757] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [2647890756] proxy/dokodemo: received request for 100.66.194.120:56700 2022/01/15 20:48:11 100.66.194.120:50030 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [3882091655] proxy/dokodemo: received request for 100.66.194.120:50034 2022/01/15 20:48:11 [Info] [3882091655] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [3882091655] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [2647890756] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [3882091655] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [2647890756] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [2647890756] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3882091655] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [2647890756] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 100.66.194.120:50034 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:56700 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [1125857725] proxy/dokodemo: received request for 100.66.194.120:56706 2022/01/15 20:48:11 [Info] [451216401] proxy/dokodemo: received request for 100.66.194.120:50036 2022/01/15 20:48:11 [Info] [1125857725] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [1125857725] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [1125857725] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [451216401] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [451216401] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [451216401] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [1125857725] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [451216401] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:56706 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:50036 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [2275171071] proxy/dokodemo: received request for 100.66.194.120:56708 2022/01/15 20:48:11 [Info] [739329810] proxy/dokodemo: received request for 100.66.194.120:50040 2022/01/15 20:48:11 [Info] [2275171071] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [739329810] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [2275171071] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [739329810] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [2275171071] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [739329810] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:50040 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [2275171071] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 100.66.194.120:56708 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [739329810] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [1399637404] proxy/dokodemo: received request for 100.66.194.120:56712 2022/01/15 20:48:11 [Info] [1399637404] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [2010910436] proxy/dokodemo: received request for 100.66.194.120:50046 2022/01/15 20:48:11 [Info] [1399637404] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [1399637404] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [1399637404] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [2010910436] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [2010910436] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [2010910436] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [2010910436] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:56712 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:50046 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [4286067751] proxy/dokodemo: received request for 100.66.194.120:56716 2022/01/15 20:48:11 [Info] [203219288] proxy/dokodemo: received request for 100.66.194.120:50050 2022/01/15 20:48:11 [Info] [4286067751] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [4286067751] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [4286067751] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [4286067751] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 100.66.194.120:56716 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [203219288] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [1622376605] proxy/dokodemo: received request for 100.66.194.120:56720 2022/01/15 20:48:11 [Info] [203219288] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [203219288] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [203219288] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:50050 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 [Info] [1622376605] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [1622376605] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [1622376605] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [1622376605] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 100.66.194.120:56720 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 [Info] [1456229194] proxy/dokodemo: received request for 100.66.194.120:50056 2022/01/15 20:48:11 [Info] [1868667340] proxy/dokodemo: received request for 100.66.194.120:51561 2022/01/15 20:48:11 [Info] [1868667340] app/dispatcher: sniffed domain: ip.gs 2022/01/15 20:48:11 [Info] [280983245] proxy/dokodemo: received request for 100.66.194.120:56726 2022/01/15 20:48:11 [Info] [1868667340] app/dispatcher: taking detour [direct] for [tcp:ip.gs:80] 2022/01/15 20:48:11 [Info] [1868667340] proxy/freedom: opening connection to tcp:147.78.176.176:80 2022/01/15 20:48:11 [Info] [1456229194] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [1456229194] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [1456229194] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [1868667340] transport/internet/tcp: dialing TCP to tcp:147.78.176.176:80 2022/01/15 20:48:11 [Info] [1456229194] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [280983245] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [280983245] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [280983245] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [280983245] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [3298583663] proxy/dokodemo: received request for 100.66.194.120:50060 2022/01/15 20:48:11 [Info] [1411554011] proxy/dokodemo: received request for 100.66.194.120:56730 2022/01/15 20:48:11 [Info] [3298583663] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [3298583663] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [445835852] proxy/dokodemo: received request for 100.66.194.120:50068 2022/01/15 20:48:11 [Info] [2437715094] app/dispatcher: sniffed domain: app.smartmailcloud.com 2022/01/15 20:48:11 [Info] [2437715094] app/dispatcher: taking detour [direct] for [tcp:app.smartmailcloud.com:443] 2022/01/15 20:48:11 [Info] [445835852] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [2437715094] proxy/freedom: opening connection to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [445835852] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [2437715094] transport/internet/tcp: dialing TCP to tcp:130.211.33.145:443 2022/01/15 20:48:11 [Info] [445835852] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [445835852] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [3791990768] proxy/dokodemo: received request for 100.66.194.120:50074 2022/01/15 20:48:11 [Info] [3057610041] proxy/dokodemo: received request for 100.66.194.120:56740 2022/01/15 20:48:11 [Info] [3791990768] app/dispatcher: sniffed domain: ping.manjaro.org 2022/01/15 20:48:11 [Info] [3791990768] app/dispatcher: taking detour [direct] for [tcp:ping.manjaro.org:80] 2022/01/15 20:48:11 [Info] [3791990768] proxy/freedom: opening connection to tcp:116.203.91.91:80 2022/01/15 20:48:11 [Info] [3791990768] transport/internet/tcp: dialing TCP to tcp:116.203.91.91:80 2022/01/15 20:48:11 100.66.194.120:51561 accepted tcp:147.78.176.176:80 [direct] 2022/01/15 20:48:11 100.66.194.120:50056 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:56726 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:50060 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:56730 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:50064 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:56734 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:56738 accepted tcp:130.211.33.145:443 [direct] 2022/01/15 20:48:11 100.66.194.120:50068 accepted tcp:116.203.91.91:80 [direct] 2022/01/15 20:48:11 100.66.194.120:50074 accepted tcp:116.203.91.91:80 [direct] ```

经过刚刚的一番比较，之前一直以为是最开始说的1e100.net（谷歌的这个追踪/广告）导致的

但偶然一次另一外一台manjaro的电脑连接了，然后从上面的日志发现，并没有1e100.net，反而是app.smartmailcloud.com和ping.manjaro.org。出现这样的原因是因为，我之前一直是用手机在Google应用上测试的，这次反而没有连，因此没有。

另：~~很大程度是怀疑存在某种“环路”，我观察内存暴涨的速度基本上是（大概估摸）呈指数级上涨，我想只有“环路”的“环路”才会导致这种情况~~（有可能是错的，忽略）。

PS：iptables这种东西都是默认，自己没有改过。因为这个问题，今天又重新安装了固件，所以可以确保我没动过。第一个调试的插件也是passwall。

Gabirel commented 2 years ago

在内存增加的时候，看配置文件，似乎生成json有点问题。分流的规则和proxy的outbounds没有生成（版本为4.47）

模式：全局代理（由xray控制分流）
结点：Xray分流总节点

{
  "outbounds": [
    {
      "streamSettings": {
        "sockopt": {
          "mark": 255
        }
      },
      "settings": {
        "domainStrategy": "UseIPv4"
      },
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "blackhole"
    }
  ],
  "log": {
    "loglevel": "error"
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp",
        "outboundTag": "direct"
      }
    ],
    "domainMatcher": "hybrid"
  },
  "inbounds": [
    {
      "port": 1041,
      "protocol": "dokodemo-door",
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      },
      "sniffing": {
        "enabled": true,
        "RouteOnly": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "network": "tcp",
        "followRedirect": true
      }
    }
  ]
}

Gabirel commented 2 years ago

@xiaorouji Summary: 目前测试下来的结论：无法使用passwall的分流模式，最终只能使用访问控制列表手动全局 + Xray分流完成（我能测的部分已经全部测完了，且在我这边复现率基本上是100%）

0. 配置模式

passwall本身的模式：代理节点 + 仅使用中国外列表代理
访问控制：分流节点 + 全局代理 + 各个终端mac

1. 使用访问控制的分流节点则不会出现内存暴涨的问题

最终配置列表如下：

![image](https://user-images.githubusercontent.com/12933851/149648966-97734979-dd42-4fe4-a9ae-e42ef7ecde56.png)

内存使用保持在一个稳定的水平，如下图所示：

![image](https://user-images.githubusercontent.com/12933851/149648353-5dbfe0af-f29c-4f31-a893-6786dfe8846b.png)

PS（分流验证）： 通过xray的blockhole（譬如通过分流模式中的AD列表），屏蔽domain:ip.sb，终端机访问被屏蔽，证明分流成功（虽然并未找到分流的日志，可能是功能缺失？或者是我没有找到？@xiaorouji ）

2. 可能存在的问题（或是feature？）：针对于openwrt自身而言，访问控制的优先级没有自带的代理模式高

依据在于：

配置了以下情况：

我给openwrt配置了访问控制，以期望达到分流模式（因为paswall默认分流用不了）
屏蔽了domain:ip.sb

验证：在openwrt的terminal里curl ip.sb有ip返回（理论上：不应该返回数据，因为访问控制的优先级应该比passwall的设置的模式高）

3. 访问模式的缺点

可能没法进行节点切换不知道能否为访问控制添加一个自动切换

4. passwall默认模式

至于为什么passwall默认会有这样的问题，源码也没有看出来，具体原因可能是有 https://github.com/xiaorouji/openwrt-passwall/issues/1677#issuecomment-1013808607 或者其他什么原因。但是导致可能这样的“环路”或者连接数暴涨，不知道为什么。

Gabirel commented 2 years ago

最终解决方案

解决方案来源：@xiaorouji
解决办法：删除自定义规则里面把DNS劫持规则，如下图所示：

原始内容：

修改为如下内容： 注释掉53的iptables规则即可

zycboss commented 1 year ago

请问一下老哥，你用的宽带是移动固定/静态IP吗？因为我有梅林的设备也出现和你完全一样的问题，xray分流会TCP连接暴涨+内存吃满但是在路由器完全相同的设置情况下，该问题又仅在移动固定IP的宽带下才出现，另外几台使用电信PPPOE拨号的宽带一切正常……

Gabirel commented 1 year ago

你用的宽带是移动固定/静态IP吗？

动态ip，现在很少有纯静态的了吧

因为我有梅林的设备也出现和你完全一样的问题，xray分流会TCP连接暴涨+内存吃满

建议使用passwall2，并且注释掉53端口的iptables规则，就OK了

jackiezhang29 commented 6 months ago

最终解决方案

解决方案来源：@xiaorouji

解决办法：删除自定义规则里面把DNS劫持规则，如下图所示：

原始内容：

修改为如下内容： 注释掉53的iptables规则即可

我也遇到了想通问题，xray开启分流节点，软路由内存占满，虚拟机cpu占满，临时空间几个G被写满，无法保存软路由的设置，只能在启动项里重启，但是通过单节点，软路由一切正常。我现在使用nftable，请问如何解决

rocketraccooo-n commented 1 week ago

在有更好的办法之前，建议保留udp 53端口的劫持规则，否则任何一个设备只要稍不小心DNS服务器没有指向网关就会造成DNS泄漏。简而言之，浏览器在少数情况下，会通过TCP而不是UDP进行dns查询，有人发现在这种情况下会产生DNS泄漏，就建议也劫持TCP的53端口并在xray内路由至dns服务器。但个人猜测，xray的DNS over TCP好像并不是为透明代理底下大量产生的这类请求所设计（应该是缓存问题，设置disableCache为true则问题立即消失），从而产生了连接爆炸的问题。呼叫@RPRX 来看一眼

xiaorouji / openwrt-passwall