Xray 1.8.10 breaks Fallback to WS

[AmirReza2012]

When using Vless + TCP + Vision + Fallback to websockets, switching server to version 1.8.10 breaks the websockets config and I get EOF error on xray 1.8.9 on android client.

Error log:
proxy/vless/inbound: firstLen = 192 proxy/vless/inbound: fallback starts > proxy/vless/encoding: invalid request version proxy/vless/inbound: realName = MYSNI proxy/vless/inbound: realAlpn = http/1.1

[lxhao61]

你 WebSocket 启用了 0-RTT 吧？

[chika0801]

发你的nginx和xray配置文件

[AmirReza2012]

你 WebSocket 启用了 0-RTT 吧？

I have tried "?ed=2048", "?ed=2560" and no early-data on the client side.

发你的nginx和xray配置文件

I noticed I had "/?ed=2560" for ws path on my server side xray configuration (to be able to more conveniently scan QR codes and have the ed written for me the link)

If I have on the server side:
"path": "/whatever?ed=2560"
this will keep working when I upgrade from 1.8.9 to 1.8.10

But if I have
"path": "/?ed=2560"
then upgrading to 1.8.10 will break the clients connections and return EOF

I think adding early-data to the server-side configuration is not necessary in the first place but it was working for me before 1.8.10, please correct me if I'm wrong.

[AmirReza2012]

发你的nginx和xray配置文件

Xray:
{ "inbounds": [ { "listen": null, "port": 443, "protocol": "vless", "settings": { "clients": [ { "email": "Whatever", "flow": "xtls-rprx-vision", "id": "id" } ], "decryption": "none", "fallbacks": [ { "alpn": "", "dest": "@vless-ws", "name": "SNI1", "path": "", "xver": 2 }, { "alpn": "", "dest": "@vless-ws", "name": "SNI2", "path": "", "xver": 2 }, { "alpn": "", "dest": "@vless-ws", "name": "SNI3", "path": "", "xver": 2 }, { "alpn": "", "dest": "@vless-ws", "name": "SNI4", "path": "", "xver": 2 }, { "alpn": "", "dest": "@ws-new", "name": "OtherDomainName.com", "path": "/products", "xver": 2 }, { "alpn": "h2", "dest": "/dev/shm/h2c.sock", "name": "", "path": "", "xver": 2 }, { "alpn": "", "dest": "/dev/shm/h1.sock", "name": "", "path": "", "xver": 2 } ] }, "sniffing": { "destOverride": [ "http", "tls", "quic" ], "enabled": true }, "streamSettings": { "network": "tcp", "security": "tls", "sockopt": { "acceptProxyProtocol": false, "mark": 0, "tcpFastOpen": true, "tproxy": "off" }, "tcpSettings": { "acceptProxyProtocol": false, "header": { "type": "none" } }, "tlsSettings": { "alpn": [ "h2", "http/1.1" ], "certificates": [ { "certificateFile": "/root/cert/WILDCARD1/fullchain.cer", "keyFile": "/root/cert/WILDCARD1/WILDCARD1.key", "ocspStapling": 3600 }, { "certificateFile": "/root/cert/WILDCARD2/fullchain.cer", "keyFile": "/root/cert/WILDCARD2/WILDCARD2.key", "ocspStapling": 3600 }, { "certificateFile": "/root/cert/WILDCARD3/fullchain.cer", "keyFile": "/root/cert/WILDCARD3/WILDCARD3.key", "ocspStapling": 3600 } ], "cipherSuites": "", "maxVersion": "1.3", "minVersion": "1.3", "rejectUnknownSni": false } }, "tag": "inbound-443" }, { "listen": "@vless-ws", "port": 3, "protocol": "vless", "settings": { "clients": [ { "email": "WS - User", "flow": "", "id": "id" } ], "decryption": "none", "fallbacks": [] }, "sniffing": { "destOverride": [ "http", "tls", "quic" ], "enabled": true }, "streamSettings": { "network": "ws", "security": "none", "sockopt": { "acceptProxyProtocol": false, "mark": 0, "tcpFastOpen": true, "tproxy": "off" }, "wsSettings": { "acceptProxyProtocol": true, "headers": {}, "path": "/?ed=2560" } }, "tag": "inbound-@vless-ws:3" }, { "listen": "@ws-new", "port": 4, "protocol": "vless", "settings": { "clients": [ { "email": "WSN - Other id", "flow": "", "id": "id" } ], "decryption": "none", "fallbacks": [] }, "sniffing": { "destOverride": [ "http", "quic", "tls" ], "enabled": true }, "streamSettings": { "network": "ws", "security": "none", "sockopt": { "acceptProxyProtocol": false, "mark": 0, "tcpFastOpen": true, "tproxy": "off" }, "wsSettings": { "acceptProxyProtocol": true, "headers": {}, "path": "/products?ed=2560" } }, "tag": "inbound-@ws-new:4" } ], "log": { "access": "./access.log", "dnsLog": false, "error": "./error.log", "loglevel": "warning" }, "observatory": null, "outbounds": [ { "protocol": "freedom", "settings": { "domainStrategy": "UseIP" }, "streamSettings": { "sockopt": { "domainStrategy": "UseIP" } }, "tag": "direct" }, { "protocol": "blackhole", "settings": {}, "tag": "blocked" }, { "protocol": "dns", "settings": { "address": "127.0.0.53", "port": 53 }, "tag": "DNS-Internal" } ], "policy": { "levels": { "0": { "connIdle": 180, "handshake": 3, "statsUserDownlink": true, "statsUserUplink": true } }, "system": { "statsInboundDownlink": true, "statsInboundUplink": true, "statsOutboundDownlink": true, "statsOutboundUplink": true } }, "reverse": null, "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "inboundTag": [ "api" ], "outboundTag": "api", "type": "field" }, { "network": "udp", "outboundTag": "blocked", "port": 443, "type": "field" }, { "outboundTag": "DNS-Internal", "protocol": [ "dns" ], "type": "field" }, { "outboundTag": "DNS-Internal", "port": "53", "type": "field" } ] }, "stats": {}, "transport": null }

Nginx has been configured according to https://github.com/XTLS/Xray-examples/blob/main/All-in-One-fallbacks-Nginx/nginx.conf

[lxhao61]

你 WebSocket 启用了 0-RTT 吧？

I have tried "?ed=2048", "?ed=2560" and no early-data on the client side.

发你的nginx和xray配置文件

I noticed I had "/?ed=2560" for ws path on my server side xray configuration (to be able to more conveniently scan QR codes and have the ed written for me the link)

If I have on the server side: "path": "/whatever?ed=2560" this will keep working when I upgrade from 1.8.9 to 1.8.10

But if I have "path": "/?ed=2560" then upgrading to 1.8.10 will break the clients connections and return EOF

I think adding early-data to the server-side configuration is not necessary in the first place but it was working for me before 1.8.10, please correct me if I'm wrong.

晕！启用 WebSocket 0-RTT 仅客户端路径后加 ?ed=2048 或 ?ed=2560。版本 1.8.10 及以后客户端路径推荐加 ?ed=2560。

[AmirReza2012]

你 WebSocket 启用了 0-RTT 吧？

I have tried "?ed=2048", "?ed=2560" and no early-data on the client side.

发你的nginx和xray配置文件

I noticed I had "/?ed=2560" for ws path on my server side xray configuration (to be able to more conveniently scan QR codes and have the ed written for me the link)
If I have on the server side: "path": "/whatever?ed=2560" this will keep working when I upgrade from 1.8.9 to 1.8.10
But if I have "path": "/?ed=2560" then upgrading to 1.8.10 will break the clients connections and return EOF
I think adding early-data to the server-side configuration is not necessary in the first place but it was working for me before 1.8.10, please correct me if I'm wrong.

晕！启用 WebSocket 0-RTT 仅客户端路径后加 ?ed=2048 或 ?ed=2560。版本 1.8.10 及以后客户端路径推荐加 ?ed=2560。

Hi.
Thank you. So adding ed to the server configuration is not necessary.

[lxhao61]

你 WebSocket 启用了 0-RTT 吧？

I have tried "?ed=2048", "?ed=2560" and no early-data on the client side.

发你的nginx和xray配置文件

I noticed I had "/?ed=2560" for ws path on my server side xray configuration (to be able to more conveniently scan QR codes and have the ed written for me the link)
If I have on the server side: "path": "/whatever?ed=2560" this will keep working when I upgrade from 1.8.9 to 1.8.10
But if I have "path": "/?ed=2560" then upgrading to 1.8.10 will break the clients connections and return EOF
I think adding early-data to the server-side configuration is not necessary in the first place but it was working for me before 1.8.10, please correct me if I'm wrong.

晕！启用 WebSocket 0-RTT 仅客户端路径后加 ?ed=2048 或 ?ed=2560。版本 1.8.10 及以后客户端路径推荐加 ?ed=2560。

Hi. Thank you. So adding ed to the server configuration is not necessary.

是的。

[chika0801]

@lxhao61 ed=xxxx 一直是只在客户端加就是了。

2048变2560是最近httpupgrade那个提交中提到事儿

最近就顺便把文档上修改了下这2个内容

[RPRX]

#3222