[Bug]: 关闭”路由器本机代理“后谷歌和GitHub连接测试失败，启用后UDP翻墙协议出现断流现象
iseku opened this issue · comments
描述您遇到的bug
- “路由器本机代理”关闭后谷歌和GitHub连接测试失败，实际上已经正常连接，局域网其它设备可以正常透明代理。
- 如果激活本机代理，连接测试正常了，但是使用UDP的协议（如tuic和hysteria2）会出现不稳定的问题，特别是每次重启宽带pppoe拨号接口后必定出现连接失败的问题，需要单独重启passwall服务才能恢复正常 。
- 远程服务器域名和IP已加入直连分流规则，其它非UDP协议也都可正常连接。
复现此Bug的步骤
1.基本设置-主要页面 2.勾选“路由器本机代理” 3.保存并应用 4.重启pppoe接口
您想要实现的目的
1、无论是否开启路由器本机代理都可以正常测试连接状态
2、解决开启路由器本机代理后UDP翻墙协议不正常的问题
日志信息
************** 重启pppoe接口后，passwall2服务跟随自动重启 ***************
2024-04-16 21:30:40: 删除nftables防火墙规则完成。
2024-04-16 21:30:40: 清空并关闭相关程序和缓存完成。
2024-04-16 21:30:40: 分析 Socks 服务的节点配置...
2024-04-16 21:30:40: - Socks节点：[h1_tuic]h1.xxx.xxx:12345，启动 0.0.0.0:1080
2024-04-16 21:30:40: 127.0.0.1#15353 （直连DNS：114.114.114.114, 远程DNS：8.8.8.8）
2024-04-16 21:30:40: - [0]节点列表中的域名(vpslist)：114.114.114.114,
2024-04-16 21:30:40: - [0]默认：127.0.0.1#15353
2024-04-16 21:30:40: 开始加载防火墙规则...
2024-04-16 21:30:40: - [0]追加ISP IPv4 DNS到白名单：114.114.114.114
2024-04-16 21:30:41: 加入负载均衡的节点到nftset[passwall2_vpslist]直连完成
2024-04-16 21:30:41: 加入所有节点到nftset[passwall2_vpslist]直连完成
2024-04-16 21:30:41: - [0]追加直连DNS到nftables：114.114.114.114:53
2024-04-16 21:30:41: 【默认】，使用 TCP 节点分流总节点
2024-04-16 21:30:41: 【默认】，使用 UDP 节点分流总节点
2024-04-16 21:30:41: 防火墙规则加载完成！
2024-04-16 21:30:42: 重启 dnsmasq 服务
2024-04-16 21:30:42: 运行完成！
************** 使用UDP的协议出现连接问题 ************************
2024-04-16 21:31:23: 自动切换检测：nOAde2j7【sing-box：[h1_tuic]】异常，切换到下一个备用节点检测！
2024-04-16 21:31:48: 自动切换检测：nOAde2j7【sing-box：[h1_hysteria2]】异常，切换到下一个备用节点检测！
2024-04-16 21:31:50: 自动切换检测：nOAde2j7【sing-box：[h1_reality]】正常，切换到此节点！
2024-04-16 21:31:50: 自动切换检测：nOAde2j7节点切换完毕！
************** 手动重启服务 /etc/init.d/passwall2 restart *********
2024-04-16 21:34:04: 删除nftables防火墙规则完成。
2024-04-16 21:34:05: 清空并关闭相关程序和缓存完成。
2024-04-16 21:34:05: 分析 Socks 服务的节点配置...
2024-04-16 21:34:05: - Socks节点：[h1_tuic]h1.xxx.xxx:12345，启动 0.0.0.0:1080
2024-04-16 21:34:05: 127.0.0.1#15353 （直连DNS：114.114.114.114, 远程DNS：8.8.8.8）
2024-04-16 21:34:05: - [0]节点列表中的域名(vpslist)：114.114.114.114,
2024-04-16 21:34:05: - [0]默认：127.0.0.1#15353
2024-04-16 21:34:05: 开始加载防火墙规则...
2024-04-16 21:34:05: - [0]追加ISP IPv4 DNS到白名单：114.114.114.114
2024-04-16 21:34:05: 加入负载均衡的节点到nftset[passwall2_vpslist]直连完成
2024-04-16 21:34:05: 加入所有节点到nftset[passwall2_vpslist]直连完成
2024-04-16 21:34:05: - [0]追加直连DNS到nftables：114.114.114.114:53
2024-04-16 21:34:06: 【默认】，使用 TCP 节点分流总节点
2024-04-16 21:34:06: 【默认】，使用 UDP 节点分流总节点
2024-04-16 21:34:06: 防火墙规则加载完成！
2024-04-16 21:34:06: 重启 dnsmasq 服务
2024-04-16 21:34:06: 运行完成！
************** 服务重启后正常 ********************
截图
No response
系统相关信息
Passwall 版本：1.28-6
Openwrt版本：ImmortalWrt 23.05.2
FireWall 版本：fw4
路由器本机使用pppoe拨号连接宽带
其他信息
No response
TCP代理方式设置为 TPROXY 后问题似乎解决了，再观察一段时间
TCP代理方式改为 TPROXY 后UDP协议稳定性问题没有再发生，但是连接测试的问题还在，以前用passwall的时候没有发现，换成passwall2后才出现的，估计连接测试脚本是直接打开的测试url而没有调用已存在的proxy转发端口
按照功能逻辑，首页连接测试是用来测试当前节点连接状态的，并且可以用延迟来判断分流是否成功，该功能应该与是否启用本机代理无关。
我修改了一下 /usr/lib/lua/luci/controller/passwall2.lua 的连接状态函数代码，让culr使用当前节点 Socks 监听端口来进行连接测试，可以符合上述逻辑。
修改后的代码如下：
function connect_status()
local e = {}
e.use_time = ""
local url = luci.http.formvalue("url")
------------- 添加和修改这两行 ---------------------------------
local socks_port = ucic:get(appname, "@global[0]", "node_socks_port")
local result = luci.sys.exec('curl --connect-timeout 3 -o /dev/null -I -sk -w "%{http_code}:%{time_appconnect}" --socks5 127.0.0.1:' .. socks_port .. ' ' .. url)
-------------------------------------------------------------
local code = tonumber(luci.sys.exec("echo -n '" .. result .. "' | awk -F ':' '{print $1}'") or "0")
if code ~= 0 then
local use_time = luci.sys.exec("echo -n '" .. result .. "' | awk -F ':' '{print $2}'")
if use_time:find("%.") then
e.use_time = string.format("%.2f", use_time * 1000)
else
e.use_time = string.format("%.2f", use_time / 1000)
end
e.ping_type = "curl"
end
luci.http.prepare_content("application/json")
luci.http.write_json(e)
end
Stale Issue