Wars with QoS and DPI #2

The "already died protocol":

P.S. Continuation of the previous post; please read the disclaimer there, as it covers the nature of the information and the use of "wars" in the title.

This morning, as planned, I dove deep into configuring and testing the capabilities of . I had many thoughts on how to "get it running" on a .

Everything I believed could be done to achieve stable network operation without compromising privacy:

• Disable OBFS; it still leaves distinct patterns (salamander).
• Lower the to avoid fragmentation (~1200-1300, 1200 is ideal as it's the standard for HTTP/3 x QUIC).
• Find a more suitable with HTTP/3 support on the original site and support for long-lived sessions, preferably a popular one.
• Set up port-forwarding to a standard port instead of 1080.
• Attempt to set up a "masquerade" so that wget/curl over HTTP/3 returns a genuine 502 error.
• Disable port-hopping.

I decided to try each step sequentially and, of course, combine them into one "mega-solution". The first thing that struck me while checking the logs of hy2 with a standard config on a mobile network was the inability of to resolve IPs for Google, VK, or anything else. The logs were just a stream of errors. It turned out I was using Cloudflare DoH, which seems to have been throttled by QoS/DPI as well. If standard Cloudflare DNS didn't work, DoH certainly wouldn't. I fixed it simply by switching to standard 8.8.8.8.

Then came the more interesting issues:

ERROR[0015] [2034875018 15.0s] connection: open connection to XXX.XXX.XXX.XXX:443 using outbound/hysteria2[proxy]: context deadline exceeded

My competitive drive kept me going. Regarding hysteria2 in our region, I’d heard it’s long been easily detected and dropped at the handshake stage. Well, that turned out to be true—at least if you don't mess with the settings (I stubbornly, perhaps blindly, believed otherwise).

Essentially, the error means (for those unaware) that detects a pattern, identifies it as a , and terminates the connection before it can even establish or reach another IP. While logs can indicate various issues depending on the network, I concluded this was the case here since every connection except 8.8.8.8 failed with context deadline exceeded before it could even start.

Nothing out of the ordinary—I just started testing every possible configuration mentioned at the start of this post. After the trillionth attempt... it connected! Apparently, my traffic matched the patterns of a call, and I likely got lucky that the entropy wasn't analyzed. My sessions last several hours; then again, video calls can last just as long. I haven't seen DPI flagging "excessively long calls" yet, but we'll see. Thus, I managed to revive a "long-dead" protocol, even though is actively shaped here (all for the sake of priority in QoS, of course).