database64128

@wkrp Thank you for letting me know. This workaround doesn't sound very flexible. The padding length is limited to multiples of 34. And it takes 2 `read()` calls for the...

> We are now starting our investigation immediately. @gfw-report In case you didn't already know and it might be helpful to your investigation, shadowsocks-rust by default only enables Shadowsocks 2022's...

@pmkol Have you set `net.ipv4.tcp_fastopen = 3` on your server? What OS is your client on? If it's Windows, have you tried to disable the fallback logic as mentioned in...

1. Is the cookie request option present in your captured SYN packet? 2. Once again, what OS and kernel version is your router on? 3. Maybe you should report your...

I'm not familiar with sing-box's configuration. I'm only here because sing-box uses my tfo-go library for TFO support.

> I believe this is a problem of shadowsocks-rust implementation. It's not a bug. This behavior is mandated by the Shadowsocks 2022 spec: https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md#313-detection-prevention > In most cases it works,...

> First problem here is, this way relies on implementation details rather than interface convention. Even it works, it's still not a good practice. We've had extensive discussions on this,...

It's not just shadowsocks-rust. My [shadowsocks-go](https://github.com/database64128/shadowsocks-go) and @nekohasekai's [sing-box](https://sing-box.sagernet.org/) both impose the same requirement. sing-box also has support for ShadowTLS v1 and v2. I'm curious how sing-box solves the issue....

> Based on the configuration above, it does not work. Post your full config so I can take a look.

You put these fields in the wrong place. The `unsafeRequestStreamPrefix` and `unsafeResponseStreamPrefix` fields are supposed to be in the client and server blocks, not in the root structure.