I run a WebRTC-based proxying tool. I observed a very unusual blocking behavior since two weeks ago. To be precise,

• The DataChannel can always be negotiated without interference.
• The first round-trip after connection establishment is crucial.
• If the first request is a short preamble or a DNS request, no blocking will be seen afterwards (even when blatantly showing a TLS-in-DTLS signature).
• If the first request has obvious TLS-in-DTLS length characteristics (ClientHello+SACK+ServerHello), subsequent large packets (anything more than 200 bytes long, but exact measurements vary; I am reluctant to perform further tests on this for fear of guilty by association) will be dropped. The packet dropping might occasionally be lifted and restored in a short time, most likely to test if the DTLS association is worth unblocking.
• If the first request shows some KCP-like characteristics (e.g. quick retransmission in succession), subsequent packets will be throttled (around 50% packet loss) and large packets still dropped. The lift-and-restore behavior also exists.
• In no case will complete blocking happen.
• Padding is partly effective. Padding ClientHello to 700 bytes does not work; padding to 1200 bytes works sometimes; padding to more than a MTU is guaranteed to work.
• Desktop browsers are more likely to be blocked compared to mobile browsers. Mobile browsers are still able to make some TLS-in-DTLS connections, but I received zero successful reports on desktop browsers. My guess is DTLS fingerprinting.
• None of the behaviors I described differ based on whether a real browser is used. A simple Go program opening the DataChannel (which merely does the DTLS handshake without making any other request) is blocked with the same pattern of a desktop browser.

It is not clear whether the blocking is related to Snowflake. However, the behavior is rather consistent with klzgrad/naiveproxy#469, showing the censor's intention to make proxies unusable with little collateral damage.