Xray-core
Xray-core copied to clipboard
XTLS
反代 HttpUpgrade，服务端 access 日志反复出现 rejected 相关报错。
使用 Caddy 代理 HttpUpgrade ，服务端 access 日志反复出现 'rejected' 相关报错，不影响正常使用。测试如下： 1、VLESS+HttpUpgrade+TLS 应用反复出现 ‘2024/03/23 20:47:55 X.6.201.12:0 rejected proxy/vless/encoding: invalid request version’ 报错。 2、Trojan+HttpUpgrade+TLS 应用反复出现 ‘2024/03/23 23:02:39 X.6.201.12:0 rejected proxy/trojan: not trojan protocol’ 报错。 3、VMess+HttpUpgrade+TLS 应用仅每次客户端连接出现 ‘2024/03/23 20:55:13 X.6.201.12:0 rejected proxy/vmess/encoding: invalid user > user do not exist’ 报错，应该算正常。 以上三种情况换成反代 WebSocket 或 HTTP/2（H2） 或 gRPC 就不会反复出现 rejected 相关报错，一切正常。
补充： 服务端使用 action 里最新 Xary 版本。 客户端使用最新 passwall - 4.76-1，且 Xray 替换为 action 里最新 Xary 版本；WebSocket 与 HttpUpgrade 应用开 Mux，路径加 ?ed=2560。
我是nginx监听443，传递到Xray。客户端不开mux(tcp)，加了ed=2560
Xray warning日志等级，access日志里还没看到 rejected proxy/vless/encoding: invalid request version 报错信息
用action里的版本试一试
就是用的 action 里最新版本测试的。
那试试 v1.8.9
@Fangliding https://github.com/XTLS/Xray-core/pull/3152#issuecomment-2002900794 这个你重测了吗
我是nginx监听443，传递到Xray。客户端不开mux(tcp)，加了ed=2560
Xray warning日志等级，access日志里还没看到
rejected proxy/vless/encoding: invalid request version报错信息
你是否弄反了？ 我刚发现客户端的 HttpUpgrade 应用路径加 ?ed=2560 就反复出现 rejected 相关报错，不加就正常。
我是nginx监听443，传递到Xray。客户端不开mux(tcp)，加了ed=2560 Xray warning日志等级，access日志里还没看到
rejected proxy/vless/encoding: invalid request version报错信息你是否弄反了？ 我刚发现客户端的 HttpUpgrade 应用路径加 ?ed=2560 就反复出现 rejected 相关报错，不加就正常。
我前面没写错，两端xray-core都是用最新提交的版本号。客户端在win和安卓上用，观察了服务端日志。
另外我说了句客户端不开mux中的tcp，是因为开了，我遇到浏览器开网页偶发下图现象。频率是不算频率，再次刷新这提示就会消失，我观察测试发现是客户端开mux(tcp）引起的。
我是nginx监听443，传递到Xray。客户端不开mux(tcp)，加了ed=2560 Xray warning日志等级，access日志里还没看到
rejected proxy/vless/encoding: invalid request version报错信息你是否弄反了？ 我刚发现客户端的 HttpUpgrade 应用路径加 ?ed=2560 就反复出现 rejected 相关报错，不加就正常。
我前面没写错，两端xray-core都是用最新提交的版本号。客户端在win和安卓上用，观察了服务端日志。
若这样只能是我使用 passwall - 4.76-1 客户端（见如上补充）原因了，等正式支持 HTTPUpgrade 0-RTT 版本出来后若还有这个问题再给 passwall 报告了。
另外我说了句客户端不开mux中的tcp，是因为开了，我遇到浏览器开网页偶发下图现象。频率是不算频率，再次刷新这提示就会消失，我观察测试发现是客户端开mux(tcp）引起的。
奇怪，我这里开启 Mux 测试没有遇到浏览器开网页偶发出错现象。
用action里的版本试一试
就是用的 action 里最新版本测试的。
那试试 v1.8.9
@Fangliding #3152 (comment) 这个你重测了吗
似乎还是寄的 最新的commit 配置
{
"log": {
"loglevel": "debug"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 80,
"protocol": "VLESS",
"settings": {
"decryption": "none",
"clients": [
{
"id": "114514",
"email": "[email protected]"
}
]
},
"streamSettings": {
"network": "httpupgrade",
"httpupgradeSettings": {
"host": "gov.cn"
},
"security": "none"
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
}
]
}
{
"log": {
"loglevel": "debug"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": "1080",
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true,
"ip": "127.0.0.1"
}
},
{
"listen": "127.0.0.1",
"port": "1081",
"protocol": "http"
}
],
"outbounds": [
{
"protocol": "VLESS",
"settings": {
"vnext": [
{
"address": "gov.cn",
"port": 80,
"users": [
{
"encryption": "none",
"id": "114514"
}
]
}
]
},
"streamSettings": {
"network": "httpupgrade",
"httpupgradeSettings":{
"host": "gov.cn",
"path": "?ed=2048"
}
},
"tag": "proxy"
},
{
"protocol": "freedom",
"tag": "direct"
}
]
}
@lxhao61
若这样只能是我使用 passwall - 4.76-1 客户端（见如上补充）原因了
passwall是个生成xray配置的GUI，它生成配置格式我认为和造成的原因没关联
等正式支持 HTTPUpgrade 0-RTT 版本出来后若还有这个问题再给 passwall 报告了。
Update HTTPUpgrade spelling and proto 你的Xray是用的是个提交及以后的话，我认为就没Xray-core这边的问题了。我也用这个提交及以后的最新版本
奇怪，我这里开启 Mux 测试没有遇到浏览器开网页偶发出错现象。
这现象遇到机率低，我也是在手机和WIN系统上用，分别遇到了，想研究下，最后测试了我的看法是客户端不开TCP的MUX，我就再没遇到了。
若这样只能是我使用 passwall - 4.76-1 客户端（见如上补充）原因了
passwall是个生成xray配置的GUI，它生成配置格式我认为和造成的原因没关联
等正式支持 HTTPUpgrade 0-RTT 版本出来后若还有这个问题再给 passwall 报告了。
Update HTTPUpgrade spelling and proto 你的Xray是用的是个提交及以后的话，我认为就没Xray-core这边的问题了。我也用这个提交及以后的最新版本
奇怪，我这里开启 Mux 测试没有遇到浏览器开网页偶发出错现象。
这现象遇到机率低，我也是在手机和WIN系统上用，分别遇到了，想研究下，最后测试了我的看法是客户端不开TCP的MUX，我就再没遇到了。
我刚用 Nginx 替换 Caddy 进行测试，其它都不变发现无问题了，看来是 HTTPUpgrade 0-RTT 兼容问题。
我刚用 Nginx 替换 Caddy 进行测试，其它都不变发现无问题了
我理解你的意思是服务端用Caddy时Xray日志有这些报错信息，换Nginx后Xray日志就没这些报错信息。就是Caddy它的问题。
是吗？
我刚用 Nginx 替换 Caddy 进行测试，其它都不变发现无问题了
我理解你的意思是服务端用Caddy时Xray日志有这些报错信息，换Nginx后Xray日志就没这些报错信息。就是Caddy它的问题。
是吗？
你理解是对的，但判断是错的！是 Xray 的 HTTPUpgrade 0-RTT 兼容问题，WebSocket 0-RTT 就无问题。
是 Xray 的 HTTPUpgrade 0-RTT 兼容问题
你意思是不是Caddy的问题。是Xray的 HTTPUpgrade 0-RTT 有问题。
那么你测试过当用Caddy时，客户端不加ed=2560（即没0-RTT），Xray服务端日志有不有报错信息。和客户端加了ed=2560（即有0-RTT），Xray服务端日志有不有报错信息。这2种情况的结果了？
才好判断是Xray本身的 HTTPUpgrade 有问题，还是Xray的 HTTPUpgrade加了0-RTT配合Caddy时有问题。
另外要再研究，你可试试将Xray换成v2fly v5 core看看v2fly那边有不有同样复现了。
我不用Caddy不帮你测了。
如果只是 HTTPUpgrade 0-RTT 配合 Caddy 有问题，代码里加个 100ms 延时应该就解决了，~~但我觉得更应该 PR 修改 Caddy 的代码~~
之前我看大猩猩的 WS 服务端是不允许客户端握手后面直接跟着数据，那些反代和 CDN 如果在 HTTPUpgrade 后就只是纯转发流量的话应该无此限制，有限制的话加个延时可以解决，但是我更想把 0-RTT 改成首包粘包，~~所以还是去 PR 修改 Caddy 的代码吧~~
如果只是 HTTPUpgrade 0-RTT 配合 Caddy 有问题，代码里加个 100ms 延时应该就解决了，~但我觉得更应该 PR 修改 Caddy 的代码~ @RPRX @chika0801 就是 HTTPUpgrade 0-RTT 配合 Caddy 有问题（启用 0-RTT）， Caddy 反代其它都正常，包括反代 WebSocket 且启用 0-RTT。
客户端： v2rayNG 1.8.19 服务端：Xray-core v1.8.10
裸 Vless + httpUpgrade，没有 tls，没有套 Web Server 和 CDN
服务端配置：
{
"inbounds": [
{
"port": 10007,
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{"id": ""}
]
},
"streamSettings": {
"network": "httpupgrade",
"httpupgradeSettings": {
"path": "/tysh/resources/images/newIndex/new-img01.png"
}
},
"sockopt": {
"mark": 0,
"tcpFastOpen": true,
"tcpcongestion": "bbr",
"tproxy": "off"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"]
}
}
]
}
客户端不加 ?ed=xxx 可以使用，加了连不上网。
客户端： v2rayNG 1.8.19 服务端：Xray-core v1.8.10
裸 Vless + httpUpgrade，没有 tls，没有套 Web Server 和 CDN
服务端配置：
{ "inbounds": [ { "port": 10007, "protocol": "vless", "settings": { "decryption": "none", "clients": [ {"id": ""} ] }, "streamSettings": { "network": "httpupgrade", "httpupgradeSettings": { "path": "/tysh/resources/images/newIndex/new-img01.png" } }, "sockopt": { "mark": 0, "tcpFastOpen": true, "tcpcongestion": "bbr", "tproxy": "off" }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] } } ] }客户端不加 ?ed=xxx 可以使用，加了连不上网。
试试此配置改成 WebSocket 应用，客户端也启用 0-RTT（?ed=xxx）怎么样？
客户端： v2rayNG 1.8.19 服务端：Xray-core v1.8.10 裸 Vless + httpUpgrade，没有 tls，没有套 Web Server 和 CDN 服务端配置：
{ "inbounds": [ { "port": 10007, "protocol": "vless", "settings": { "decryption": "none", "clients": [ {"id": ""} ] }, "streamSettings": { "network": "httpupgrade", "httpupgradeSettings": { "path": "/tysh/resources/images/newIndex/new-img01.png" } }, "sockopt": { "mark": 0, "tcpFastOpen": true, "tcpcongestion": "bbr", "tproxy": "off" }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] } } ] }客户端不加 ?ed=xxx 可以使用，加了连不上网。
试试此配置改成 WebSocket 应用，客户端也启用 0-RTT（?ed=xxx）怎么样？
工作正常
客户端： v2rayNG 1.8.19 服务端：Xray-core v1.8.10 裸 Vless + httpUpgrade，没有 tls，没有套 Web Server 和 CDN 服务端配置：
{ "inbounds": [ { "port": 10007, "protocol": "vless", "settings": { "decryption": "none", "clients": [ {"id": ""} ] }, "streamSettings": { "network": "httpupgrade", "httpupgradeSettings": { "path": "/tysh/resources/images/newIndex/new-img01.png" } }, "sockopt": { "mark": 0, "tcpFastOpen": true, "tcpcongestion": "bbr", "tproxy": "off" }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] } } ] }客户端不加 ?ed=xxx 可以使用，加了连不上网。
试试此配置改成 WebSocket 应用，客户端也启用 0-RTT（?ed=xxx）怎么样？
工作正常
哦，看来我的猜测正确的， HTTPUpgrade 0-RTT 的兼容性无法等同 WebSocket 0-RTT。
哦，看来我的猜测正确的， HTTPUpgrade 0-RTT 的兼容性无法等同 WebSocket 0-RTT。
是的，就像 HTTPUpgrade 的兼容性无法等同 WebSocket
我说一下吧，直连不要用这两个传输方式，过 CDN 才要，所以 0-RTT 的实现兼容 CDN 就够了，自己的服务器端要用兼容的反代软件
~我觉得说明一下httpupgrade的兼容问题就行了吧 没啥人踩坑的情况下不用加那么多指导~
~~防止大聪明们想玩 HTTPUpgrade 直连，就像去年 WebSocket 直连的小白们被封麻了，说了好多遍不要用了才消停~~
~~反正他们99%都是跟着各种油管主搭的 还有很多人用wss也大都是因为看了过时教程 文档是这辈子都不可能看的 现在应该都是跟风声用reality去了~~
是的，就像 HTTPUpgrade 的兼容性无法等同 WebSocket
我说一下吧，直连不要用这两个传输方式，过 CDN 才要，所以 0-RTT 的实现兼容 CDN 就够了，自己的服务器端要用兼容的反代软件
刚测试最新 Caddy master 版已解决所报告问题。