[Bug]: 4.62 之后的 负载均衡 有点奇怪

[2eronia]

描述您遇到的 bug

机场的协议是 SSR

根据机场的节点所在地，做了4组负载均衡，绑定 1181，1182，1185，1186，四个端口

4.61以及之前版本，HAProxy 可以看到所有负载均衡的机场节点都是绿的，实际测试也是可以连通的

SSH 连上路由，用 opkg install 安装 ipk 包，直接升级到 4.62，最近试了好多个版本，包括昨晚半夜编译的 4.62-7，登录 [路由IP]:1188，看到好多节点都是咖啡色的 (active or backup DOWN for maintenance (MAINT) )，如果节点检测方式用 Passwall 而不是 TCP，则很多节点是红色的。切换到只有一个节点是绿的 1185，能科学，但是 HAProxy 看到只有那个绿的节点有数据变动，其他咖啡色的都是 0

--force-downgrade，回滚 4.61，负载均衡又变回全绿，一切恢复正常

日志信息

未见异常，Watch Logs 跟之前输出一样

系统相关信息

Passwall: 4.62-2 ~ 4.62~7 固件内核: 5.4.118 HAProxy：2.6.2-1

其他信息

是不是我升级 4.62，需要重置 Passwall 配置？

[nftbty]

可以看看#2420，新版增强了负载均衡，支持不同协议不同配置的节点均衡，是使用socks转发实现的。不过我昨天也确实有发现其他一些疑惑的地方。

[jxph1123]

之前的版本测不了连通性，后面这个优化了连通性检测，同时支持不同协议不同配置的节点均衡，目前感觉很好用的。

[xiaorouji]

暫時感覺良好、稳定。

[Deleted-Account]

暫時感覺良好、稳定。

等会家人不怎么用网络的时候我复现截图下

[Deleted-Account]

4.61-1 版本的 Passwall：

切换分组：

再次切换分组：
所有节点都是可用的

---

Passwall 升级到 4.62-7，立马变成大面积咖啡色：

---

如果 Health Check Type 改成 用 Passwall Inner Implement：
节点就变得很奇怪

---

机场节点的配置信息：

shadowsocksr-libev-ssr-local
shadowsocksr-libev-ssr-redir
shadowsocksr-libev-ssr-server
都是2.5.6-9

---

4.62-7 的 Watch Logs：

2023-04-06 18:12:11: 删除相关防火墙规则完成。
2023-04-06 18:12:15: 清空并关闭相关程序和缓存完成。
2023-04-06 18:12:15: HAPROXY 负载均衡...
2023-04-06 18:12:24:   + 入口 0.0.0.0:1181...
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]，权重：5
2023-04-06 18:12:24:   + 入口 0.0.0.0:1182...
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:560，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:561，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:562，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:563，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:564，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:560，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:561，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:562，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:563，权重：5
2023-04-06 18:12:24:   + 入口 0.0.0.0:1185...
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:560，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:561，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:562，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:563，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:564，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:565，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:566，权重：5
2023-04-06 18:12:24:   | - 出口节点：[手工打码]:567，权重：5
2023-04-06 18:12:24:   + 入口 0.0.0.0:1186...
2023-04-06 18:12:24: TCP节点：[HK]，监听端口：1041
2023-04-06 18:12:24:   - Socks节点：[HK]127.0.0.1:1185，启动 0.0.0.0:1070
2023-04-06 18:12:24: UDP节点没有选择或为空，不代理UDP。
2023-04-06 18:12:24: 过滤服务配置：准备接管域名解析...
2023-04-06 18:12:24:   - 域名解析：使用UDP协议请求DNS（10.10.10.1#7913）...
2023-04-06 18:12:24:   * 要求代理 DNS 请求，如上游 DNS 非直连地址，确保 UDP 代理打开，并且已经正确转发！
2023-04-06 18:12:24:   - PassWall必须依赖于Dnsmasq，如果你自行配置了错误的DNS流程，将会导致域名(直连/代理域名)分流失效！！！
2023-04-06 18:12:24: 开始加载防火墙规则...
2023-04-06 18:12:25: 加入负载均衡的节点到ipset[vpsiplist]直连完成
2023-04-06 18:12:25: 加入所有节点到ipset[vpsiplist]直连完成
2023-04-06 18:12:25: 加载路由器自身 TCP 代理...
2023-04-06 18:12:25:   - [0]不代理TCP 端口：6800,6880:6888
2023-04-06 18:12:25: TCP默认代理：使用TCP节点[HK] [防火墙列表](REDIRECT:1041)代理除6800,6880:6888外的所有端口
2023-04-06 18:12:25: 防火墙规则加载完成！
2023-04-06 18:12:28: 重启 dnsmasq 服务
2023-04-06 18:12:28: 配置定时任务：自动更新规则。
2023-04-06 18:12:28: 配置定时任务：自动更新 [手工打码] 订阅。
2023-04-06 18:12:28: 运行完成！

也不懂什么原因了，只好回退 4.61

ps. 刚才试了 4.63，跟 4.62 一模一样…

[nftbty]

健康检查类型改为可用性测试后，节点类型变为Socks转发到你实际的节点，在节点列表添加的负载均衡节点要改为Socks，127.0.0.1:1181，你再试一下。

[Deleted-Account]

健康检查类型改为可用性测试后，节点类型变为Socks转发到你实际的节点，在节点列表添加的负载均衡节点要改为Socks，127.0.0.1:1181，你再试一下。

好点，马上试试

[nftbty]

这是我的，存活情况和手机测试一致。虽然我并没有使用haproxy均衡，用的是同样由这几个节点组的Xray均衡(leastping选最快的)

[Deleted-Account]

健康检查类型改为可用性测试后，节点类型变为Socks转发到你实际的节点，在节点列表添加的负载均衡节点要改为Socks，127.0.0.1:1181，你再试一下。

改成这样之后，可以用

HAProxy里面，显示是红的，依然可用，不过流量信息没更新

如果强制 Health: force UP，过一会就会变黄然后变红

[nftbty]

你这几个节点目前有几个可用的，用手机单独连接测试过没有，可用的节点测试稳不稳，会不会有测试次数太多，就延迟大增甚至超时的情况。这个可用性测试应该是请求某个墙外网站测试的，好像是https://www.google.com/generate_204，不确定是不是，我看看。估计是不是正好你的节点访问连接测试的域名有问题。

[Deleted-Account]

你这几个节点目前有几个可用的，用手机单独连接测试过没有，可用的节点测试稳不稳，会不会有测试次数太多，就延迟大增甚至超时的情况。这个可用性测试应该是请求某个墙外网站测试的，好像是https://www.google.com/generate_204，不确定是不是，我看看。估计是不是正好你的节点访问连接测试的域名有问题。

我负载均衡的这些节点，应该是全都可用的。
4.61版本用负载均衡，所有节点都有大流量的数据交换信息。
你可以看我前几楼的图。4.61和4.62下，那几张HAProxy的图，截图的时间间隔不超过10分钟，
我还用 qv2ray 单独测试了那些红色/咖啡色的节点，也是可用的

[nftbty]

这就是可用性检测的脚本内容，确实是请求的https://www.google.com/generate_204，然后看返回的HTTP 状态码是不是204或者200。很简单的判断。你打开浏览器F12，然后手动请求https://www.google.com/generate_204，看返回的状态码是不是204或者200。

[nftbty]

另外，就是你的passwall代理模式是什么，路由器本机是否开启了代理

[Deleted-Account]

另外，就是你的passwall代理模式是什么，路由器本机是否开启了代理

TCP 模式选的 GFW List，UDP 不代理，路由选的 Same as the TCP default proxy mode

[nftbty]

最好是查看一下/tmp/etc/passwall下面haproxy_开头的几个配置文件，看里面分配的local port 是什么，一般是208x。然后在路由器上手动执行检测代码看看，比如某个节点的socks转发端口是2082，就是 /usr/bin/curl -x socks5h://127.0.0.1:2082 --connect-timeout 3 --retry 3 -w %{http_code}'\n' "https://www.google.com /generate_204"，看看输出是不是204

[Deleted-Account]

最好是查看一下/tmp/etc/passwall下面haproxy_开头的几个配置文件，看里面分配的local port 是什么，一般是208x。然后在路由器上手动执行检测代码看看，比如某个节点的socks转发端口是2082，就是 /usr/bin/curl -x socks5h://127.0.0.1:2082 --connect-timeout 3 --retry 3 -w %{http_code}'\n' "https://www.google.com /generate_204"，看看输出是不是204

好点，感谢回复。

手头有工作要忙，先退回4.61了。我找个升级上去并且重置下设置，看看能不能解决

另外，4.63 相比 4.62-7，还提示我缺少 shadowsocks-rust-ssserver v2ray-geoip v2ray-geosite luci-lua-runtime 这几个依赖，我想办法补全下

[nftbty]

最好是查看一下/tmp/etc/passwall下面haproxy_开头的几个配置文件，看里面分配的local port 是什么，一般是208x。然后在路由器上手动执行检测代码看看，比如某个节点的socks转发端口是2082，就是 /usr/bin/curl -x socks5h://127.0.0.1:2082 --connect-timeout 3 --retry 3 -w %{http_code}'\n' "https://www.google.com /generate_204"，看看输出是不是204

好点，感谢回复。

手头有工作要忙，先退回4.61了。我找个升级上去并且重置下设置，看看能不能解决

另外，4.63 相比 4.62-7，还提示我缺少 shadowsocks-rust-ssserver v2ray-geoip v2ray-geosite luci-lua-runtime 这几个依赖，我想办法补全下

4.63你从release下载的吧，4.62-7是你自己编译的？

[Deleted-Account]

最好是查看一下/tmp/etc/passwall下面haproxy_开头的几个配置文件，看里面分配的local port 是什么，一般是208x。然后在路由器上手动执行检测代码看看，比如某个节点的socks转发端口是2082，就是 /usr/bin/curl -x socks5h://127.0.0.1:2082 --connect-timeout 3 --retry 3 -w %{http_code}'\n' "https://www.google.com /generate_204"，看看输出是不是204

好点，感谢回复。 手头有工作要忙，先退回4.61了。我找个升级上去并且重置下设置，看看能不能解决 另外，4.63 相比 4.62-7，还提示我缺少 shadowsocks-rust-ssserver v2ray-geoip v2ray-geosite luci-lua-runtime 这几个依赖，我想办法补全下

4.63你从release下载的吧，4.62-7是你自己编译的？

嗯嗯，是的

[nftbty]

嗯嗯，是的

不用管，直接 --no-deps安装就行，我是搞不懂官方什么逻辑，整个makefile里面就没有对luci-lua-runtime的depend，就算是哪个依赖包在官方版里有对这个的依赖，但依赖的依赖，并不是我的依赖，也许是对所有luci-app都添加了？

[SakuraFallingMad]

嗯嗯，是的

不用管，直接 --no-deps安装就行，我是搞不懂官方什么逻辑，整个makefile里面就没有对luci-lua-runtime的depend，就算是哪个依赖包在官方版里有对这个的依赖，但依赖的依赖，并不是我的依赖，也许是对所有luci-app都添加了？

请问下，这边release下载的ipk包，我也--nodeps都不行，咋整 `root@ImmortalWrt:/tmp/upload# opkg install luci-app-passwall_4.63_all.ipk --nodeps Package luci-app-passwall (4.62) installed in root is up to date. Collected errors:

• pkg_hash_check_unresolved: cannot find dependency v2ray-core for luci-app-passwall
• pkg_hash_check_unresolved: cannot find dependency v2ray-plugin for luci-app-passwall
• pkg_hash_check_unresolved: cannot find dependency luci-lua-runtime for luci-app-passwall root@ImmortalWrt:/tmp/upload# `

[nftbty]

请问下，这边release下载的ipk包，我也--nodeps都不行，咋整 `root@ImmortalWrt:/tmp/upload# opkg install luci-app-passwall_4.63_all.ipk --nodeps Package luci-app-passwall (4.62) installed in root is up to date. Collected errors:

2464

[cyzzc]

我负载均衡也是这种情况，我是用一台中转机中转几台落地机。然后落地机同一个中转域名不同端口，HAProxy出现第一个节点绿色，剩下几个节点全是咖啡色的，但是如果落地节点把域名换成IP地址就变成绿色。附上两张图，一张是把节点改成IP的情况，一张是用域名的情况。

[WYC-2020]

虽然负载均衡 能支持不同协议了 只是 这进程数就有点老火了，一百个负载均衡节点 一百个进程，虽然这样可以增加稳定性，避免一个ssr-local 挂了 导致所有都不行，我在线又没多线程的，或者类似协程这种的，这样就可以吧好几个 只需要启动一个就能 进行协议转换，岂不是美哉，并且可以自定义 几个协议公用一个转换进程，意淫一下

[nftbty]

其实ss-local这些倒还好，一个进程占用大概也就1.35MB左右，一般用来做负载均衡的节点也不多，而且也不知道ss-local支不支持一个进程多组配置，今天上午查了一下，没查到这种用法，得手动尝试。 占用比较大的是V2ray/Xray类型的节点，一般正常点的机器内存占用至少也得5MB，只是几个节点也倒还好。上次某个issue里，遇到有个设备，相同xray配置，我的占用20+MB，他的100MB，HAProxy启动的xray进程，我的每个占用5.xMB，他的一个23MB。这一块，应该可以使用V2ray/Xray的conf-dir，把生成的配置文件丢进去，再启动xray。

[gitcook]

更新后负载均衡怎么都跑不起来 ，直接换docker来运行haproxy了

[gitcook]

[jxph1123]

@nftbty @xiaorouji 大佬，目前的版本，这个HAProxy里面的健康检查，始终比外面测的健康检查延时高一倍，你们是这样吗，还是说是我的问题。