How to tell that it is not the site being blocked, but the VPN protocol
The main sign that the VPN protocol itself is being blocked, not a specific website: without a VPN, everything opens; as soon as you turn on the VPN, the connection either is not established or is established and then immediately dies. The site has nothing to do with it; TSPU (ТСПУ) cuts the VPN session itself.
This is a typical scenario in Russia: the operator does not block your hypothetical VPS, does not block the site you want to open, and does not block your IP. It blocks the characteristic protocol handshake — recognizes WireGuard or OpenVPN by the shape of the first packets and resets the connection. This is protocol-level blocking.
Below is a step-by-step way to distinguish this situation from others, and what to do next.
In short
- The site opens without a VPN → the VPN does not connect → the problem is in the VPN session itself.
- DPI catches the VPN not by the server address, but by the handshake signature.
- WireGuard, OpenVPN, IPsec are the easiest to detect.
- VLESS+REALITY, AmneziaWG, Shadowsocks-2022 are masked as HTTPS and last longer.
- Changing to another server using the same protocol usually does not help.
- Changing the protocol to a masked one usually helps.
How to tell protocol blocking from other problems
To make sure you are dealing with protocol-level blocking, you need to rule out the alternatives one by one.
Step 1. Check the internet without a VPN
Open any site without a VPN, preferably one that definitely works (for example, mail.ru or yandex.ru). If it does not open, the problem is with the network, not the VPN. If it opens, continue.
Step 2. Turn on the VPN and try the same site
If the VPN does not connect at all, this is a symptom of session blocking. If it connects and stays up, but a specific site does not open, that is a completely different story: most likely the site itself is blocking the VPN IP.
Step 3. Change to another server using the same protocol
Take a second server from your VPN using the same protocol (WireGuard to WireGuard, for example). If none of them works, this is signature-based blocking, not server-based blocking.
Step 4. Change the protocol
Switch to VLESS+REALITY, AmneziaWG, or Shadowsocks-2022 on the same server or provider. If it starts working, that is final confirmation that the protocol itself was being blocked.
How DPI recognizes a VPN
Most VPN protocols reveal a recognizable structure in the very first packet. WireGuard is a short UDP packet of a fixed Initiation type. OpenVPN has a header with a message type. IPsec uses standard ISAKMP packets on port 500. TSPU stores these signatures and marks the flow as VPN before the first useful byte has even passed. Masked protocols (VLESS+REALITY, XTLS-Vision) make the first packet indistinguishable from ordinary HTTPS, so building a signature for them is harder.
How to understand what exactly broke
| Symptom | Possible cause | What to check |
|---|---|---|
| Everything opens without a VPN, the VPN does not connect | Signature-based protocol blocking | Change the protocol to REALITY/AmneziaWG |
| The VPN connects, then the internet dies after 5 seconds | DPI recognized the handshake after connection | Enable obfuscation |
| No server of this VPN works | Signature-based blocking across all servers | Change the protocol |
| Works on one operator, does not work on another | Different TSPU rules at different operators | Compare measurements by operator |
| Works on a PC, does not work on a phone | Different networks, different TSPU | Compare Wi-Fi and LTE |
| A specific site does not open through the VPN, but others do | The site itself blocks the VPN IP | Do not confuse this with protocol-level blocking |
How to check right now
If you suspect protocol-level blocking, check the symptom across several operators. If WireGuard does not connect for you on MTS, but the same config works for a neighbor on MegaFon, this is already proof that the protocol is being blocked, not the server.
Freedom Checker shows exactly this picture by operator: the same protocols and services are checked from probes in several cities, and you can see where the protocol passes and where it is cut. A detailed description of the core architecture used by modern obfuscated protocols is available in Xray-core on GitHub.
Failure or blocking?
A failure is when a specific VPN provider has an outage, a server is down, or authorization is temporarily unavailable. Symptom: a couple of servers work, the rest do not, and after a few hours everything recovers by itself.
Protocol-level blocking behaves differently: the same error appears on all servers using one protocol, remains stable over time, and is tied to a specific operator. If changing the server does not help, but changing the protocol does, this is protocol blocking, not a failure.
What to pay attention to
- WireGuard is caught by its fixed first handshake packet — it is the most “transparent” protocol for DPI.
- Changing the port (443/8443) rarely helps: DPI looks at the content, not the port.
- AmneziaWG is a fork of WireGuard with handshake obfuscation: the same key material, but it looks different.
- VLESS+REALITY makes the first packet indistinguishable from real TLS to the specified domain.
- Do not confuse “the VPN does not work” with “the site does not work through the VPN” — these are different problems.
- Traffic slowdown through a VPN may indicate partial blocking, not full blocking.
- Behavior can change: TSPU rules are updated, and a protocol that worked yesterday may fall into the filter today.
Conclusion
The sign that the VPN protocol itself is being blocked is simple: without a VPN the site opens, with a VPN nothing works, and no server of this VPN helps. Changing the protocol to a masked one (REALITY, AmneziaWG, Shadowsocks-2022) is the only reliable way to verify that the traffic type is the problem.
The fastest step is to compare behavior across several operators and try an alternative protocol on the same server.