Closed mars-m9 closed 5 months ago
使用 Passwall 提供的"Socks 配置 [1081 端口]"选项作为 Xray 前置代理节点时,/tmp/etc/passwall/acl/defaults/TCP_UDP_SOCKS.json
中并没有看到关于 1081 端口的配置,使用我自己添加的 Socks 节点"127.0.0.1:1081"后,配置中出现了 1081 端口的相关配置。
應該是BUG,@nftbty 。
https://github.com/xiaorouji/openwrt-passwall/blob/677684028c7d9f39a350010f271089bfb638b4ae/luci-app-passwall/luasrc/passwall/util_xray.lua#L772
proxy_node_id
值為 Socks_
開頭,所以 nil
https://github.com/xiaorouji/openwrt-passwall/blob/677684028c7d9f39a350010f271089bfb638b4ae/luci-app-passwall/luasrc/passwall/util_xray.lua#L903
就不會執行了。
确实是,之前处理的时候没考虑到这个,我把这个判断逻辑再改一下
接楼提问,用openwrt主线编译选上passwall会勾选ipt-core和ipset是正常的吗?openwrt主线不是默认firewall4了吗?
@mars-m9 试试这个,上传到路由器/usr/lib/lua/luci/passwall/
,把原版记得备份,然后这个名字改成util_xray.lua
试试这个有没有问题。 另外,你再试试之前的老版,用 Sing-Box分流+Xray Vmess有没有问题。因为目前发现的问题是在Xray分流里面,对 Sing-Box分流+Xray节点使用场景无影响。
另外,据我测试,Passwall应该是没有适配(测试用的是无法直连的CloudflareWarp,通没通,走没走前置代理,可以直观感受到)
Sing-Box分流+Xray节点+前置代理
和
Xray分流+Sing-Box节点+前置代理
这2种情况的,主要在于生成节点配置时没有把服务器地址端口改为127.0.0.1:208x
的 dokodemo-door/direct 入站地址。
更新:这个问题也定位到了,是_app.sh_里面run_socks()
传给run_singbox()
和run_xray()
的 server_host
和server_port
两个参数没传好,然后run_singbox()
和run_xray()
里也没有处理这两个参数。
加上后,生成的配置文件服务器地址是对的上了,不过我测试还是不通,不知道是节点问题还是哪里仍有问题。
同节点配置,Xray分流+Xray WireGuard 走前置代理 是通的,Sing-Box分流+Xray WireGuard 不通。我再看看生成的配置有没有别的问题。
换成一个Vmess协议节点,倒是能通,但是不知道是否通过了前置代理连接的还是直连的,用手机试了好多节点,找不到那种直连连不上,只能通过前置代理连的节点,也没有别的像Warp一样通过查看IP就可以判断是否经过前置代理的代理服务器。
按照问题描述,你应该是可以判断出节点是否使用了前置代理的。就麻烦你再测几次。替换 util_xray.lua后,纯 Xray 和纯 Sing-Box环境应该是没问题了。但是上面说的2种混合场景应该是都不经过前置代理的。
然后把这个app.sh.txt替换/usr/share/passwall/app.sh
后,应该就可以走前置代理了,试试看。
@nftbty 替换后,Xray 分流 + Xray Vmess + Socks 前置代理没问题了。 Sing-Box 分流 + Xray Vmess + Socks 前置代理貌似还是走的直连(Passwall 提供的选项或自己添加的 Socks 节点都一样),不过问题不大,这种用法比较奇葩😂,也不推荐这样用,我只是顺手测试一下。 谢谢大佬。
@nftbty 抱歉刚刚没看到还有个 app.sh,替换后测试 Sing-Box 分流 + Xray Vmess + Socks 前置代理也正常了。
测试两个文件替换后全部正常了 Xray 分流 + Xray Vmess + Socks 前置代理 Xray 分流 + Sing-Box Vmess + Socks 前置代理 Sing-Box 分流 + Sing-Box Vmess + Socks 前置代理 Sing-Box 分流 + Xray Vmess + Socks 前置代理
那我等会就提PR了。
另外,你用原来的app.sh,再测xray分流+sing-box vmess看看,从代码和生成的配置来看,落地节点应该是直连,并没有走代理。
你可以设置应用后,到/tmp/etc/passwall/
下,看你设置使用xray vmess+前置代理的分流规则名,打开文件名带有这个规则名的json配置文件,看outbound里服务器地址端口是不是127.0.0.1 和208x,只有是127.0.0.1才会走代理,如果是真实服务器地址是直连出去的。
那我等会就提PR了。
另外,你用原来的app.sh,再测xray分流+sing-box vmess看看,从代码和生成的配置来看,落地节点应该是直连,并没有走代理。 你可以设置应用后,到
/tmp/etc/passwall/
下,看你设置使用xray vmess+前置代理的分流规则名,打开文件名带有这个规则名的json配置文件,看outbound里服务器地址端口是不是127.0.0.1 和208x,只有是127.0.0.1才会走代理,如果是真实服务器地址是直连出去的。
旧的app.sh
{
"outbounds": [
{
"security": "none",
"server_port": 56789,
"uuid": "*",
"domain_strategy": "prefer_ipv6",
"global_padding": false,
"packet_encoding": "",
"alter_id": 0,
"type": "vmess",
"server": "我的落地机地址",
"authenticated_length": false,
"tag": "qlo6KXzt"
},
{
"domain_strategy": "prefer_ipv6",
"type": "direct",
"routing_mark": 255,
"tag": "direct"
},
{
"tag": "block",
"type": "block"
}
],
"log": {
"timestamp": true,
"level": "error",
"disabled": true,
"output": "/dev/null"
},
"route": {
"geosite": {
"path": "/usr/share/singbox/geosite.db",
"download_url": "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.db"
},
"rules": [],
"geoip": {
"path": "/usr/share/singbox/geoip.db",
"download_url": "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.db"
},
"final": "qlo6KXzt"
},
"inbounds": [
{
"type": "socks",
"sniff": true,
"listen": "0.0.0.0",
"listen_port": 2083,
"tag": "socks-in"
}
]
}
新的app.sh
{
"outbounds": [
{
"security": "none",
"server_port": 2082,
"uuid": "*",
"domain_strategy": "prefer_ipv6",
"global_padding": false,
"packet_encoding": "",
"alter_id": 0,
"type": "vmess",
"server": "127.0.0.1",
"authenticated_length": false,
"tag": "qlo6KXzt"
},
{
"domain_strategy": "prefer_ipv6",
"type": "direct",
"routing_mark": 255,
"tag": "direct"
},
{
"tag": "block",
"type": "block"
}
],
"log": {
"timestamp": true,
"level": "error",
"disabled": true,
"output": "/dev/null"
},
"route": {
"geosite": {
"path": "/usr/share/singbox/geosite.db",
"download_url": "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.db"
},
"rules": [],
"geoip": {
"path": "/usr/share/singbox/geoip.db",
"download_url": "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.db"
},
"final": "qlo6KXzt"
},
"inbounds": [
{
"type": "socks",
"sniff": true,
"listen": "0.0.0.0",
"listen_port": 2083,
"tag": "socks-in"
}
]
}
所以之前只要是两者混用的都存在问题。按照你贴的配置,应该从passwall支持Sing-Box起,Xray和Sing-box 混用+开前置就有问题,但是你之前测试时,感觉不出来其实落地机是直连并没有通过前置吗?
至于要说混用需求,可能还真有。 Xray支持负载均衡,LeastPing 优选+fallback后备(可多级),Sing-Box 支持DNS分流,支持一些Xray不支持的都有协议。有时同时需要2者的独有功能。
今天有点事,等会有空了再提交PR。另外如果使用过程发现新的问题也反馈到这个issue,刚好还没commit,尽量把问题早发现早解决。
所以之前只要是两者混用的都存在问题。按照你贴的配置,应该从passwall支持Sing-Box起,Xray和Sing-box 混用+开前置就有问题,但是你之前测试时,感觉不出来其实落地机是直连并没有通过前置吗?
至于要说混用需求,可能还真有。 Xray支持负载均衡,LeastPing 优选+fallback后备(可多级),Sing-Box 支持DNS分流,支持一些Xray不支持的都有协议。有时同时需要2者的独有功能。
今天有点事,等会有空了再提交PR。另外如果使用过程发现新的问题也反馈到这个issue,刚好还没commit,尽量把问题早发现早解决。
应该是支持 Sing-Box 起就有问题了,不过之前一直用的 Xray,最近更新后感觉很卡才测试了一下。目前用起来没什么问题了,谢谢大佬。☕
描述您遇到的bug
最新源码中可以直接选择 Socks 节点,不需要在节点列表中添加,非常方便,如图
不过,我似乎发现了一些问题,具体情况如下: 配置情况:Socks 1081 配置了香港节点+自动切换日本节点,是机场提供的专线节点,并使用该 1081 配置作为 Xray 分流前置代理节点,最终落地节点为自己的香港落地机(落地机为国际线路,直连效果差,所以用机场中转),使用 Xray Vmess 协议。
当前置代理节点选择“Socks 配置 [1081 端口]”时,打开各种网页都非常慢,比如 Google,是这样的: 如果我在节点中自行添加一个 Socks 节点(127.0.0.1:1081),并作为前置代理节点使用,打开网页的速度立马就快了:
重复试了很多次,确实存在问题。选 Passwall 提供的 Socks 1081 就有问题,选自己添加的 127.0.0.1:1081 就没问题。
另外,如果将分流类型改为 Sing-Box,这个问题就解决了,但最终落地节点也要是 Sing-Box Vmess 协议,如果是 Xray Vmess 协议则问题依旧存在。
猜测:使用 Xray 分流时,前置代理节点选择由 Passwall 提供的 Socks 选项,似乎前置代理没有生效,而是直接连接了落地节点,又由于节点是国际线路,直连效果差,所以导致卡顿。
@nftbty 大佬先看看吧,版本之间的配置差异,晚点我再刷回旧版本看下。
复现此Bug的步骤
已经在上面描述了。
您想要实现的目的
优化。
日志信息
不重要,有需要再贴。
截图
No response
系统相关信息
4.76-4
其他信息
No response