This doesn't work anymore; the GFW no longer detects VPN connections by port but instead by performing deep packet inspection to characterize the type of traffic going over every connection. Using this technique in combination with some advanced ML systems, they're able to detect any encrypted VPN connection and cut it off; it's basically not possible to run any kind of outbound VPN connection (even to private servers) from inside of China anymore, and it's usually not even possible to _tunnel_ a VPN connection through some other protocol because the GFW now detects that too.

Stepping back and looking at it from a purely technical perspective, it's actually insanely impressive.

Here's a USENIX paper from a few years ago on how it is done: https://gfw.report/publications/usenixsecurity23/en/

Which is ridiculous because OpenVPN is trivial to identify, even when over TCP since it's different from "regular" HTTPS/SSL traffic.

Why they chose this I have no idea.

You can even port share.

443 -> Web server for HTTPS traffic 443 -> OpenVPN for OpenVPN traffic

Still trivial to identify and not uncommon for even public WiFi to do so.

Since I changed to tailscale+headscale with my own derp server all these issues have disappeared (for now).