How VPN traffic filtering works (DPI, TSPU) and why some protocols hold up better than others

Three layers of filtering

An ISP sees every packet you send. It can’t read the contents of an encrypted tunnel, but it can ask three questions: where is the packet going, what does it look like, and how does the stream of packets behave over time. Each question maps to its own layer of filtering.

IP address lists and a personal address

The simplest layer. ISPs and regulators collect the addresses of known VPN services’ servers and add them to block lists. Finding them isn’t hard: a mass-market service runs on a few hundred addresses that are published in the app and on the website, and anyone can connect and note where the traffic went.

A personal server lives differently. Its address is known only to you — it isn’t published or shared with anyone. It isn’t on any ready-made list, and it can only end up there if the entire hosting subnet gets blocked. So a personal VPN server removes almost all of the first layer — but only the first.

Subnet blocks do happen. In that case the fix is to switch location: the server redeploys in a different data centre with a new address within minutes. That’s one reason for having 60+ locations to choose from.

Signatures, DPI and TSPU

DPI is equipment that parses packets deeper than addresses: it looks at the first bytes of a connection, packet sizes and order, and protocol versions and extensions. Every VPN protocol has a characteristic handshake. Classic WireGuard starts with a fixed-size packet and a recognisable structure; OpenVPN has its own service headers; IKEv2 uses known ports and a known format.

TSPU — “technical measures to counter threats” — is DPI installed at Russian ISPs with centrally managed rules. The key difference from home-grown filters: a rule added centrally applies at every ISP at once, and it may throttle rather than block — which makes it harder to tell what happened.

What DPI actually sees

• The type and version of the TLS handshake, including the server name in the plaintext SNI field.
• The client fingerprint: the set of ciphers, extensions and their order, which reveals the library.
• The sizes of the first packets and the pauses between them.
• Whether expected protocol elements are present: certificates, HTTP headers, server responses.

A protocol that looks like “something encrypted with no distinguishing marks” is suspicious on its own: ordinary traffic is almost always recognisable. That’s why the modern answer isn’t to hide the protocol, but to make it resemble a specific legitimate one.

Behavioural analysis

Signatures catch a protocol in the first few seconds. Behavioural analysis works more slowly but holds up better against disguising: it looks at the stream as a whole. An ordinary HTTPS connection to a website lasts seconds or minutes, transfers a modest amount, and ends. A tunnel to a single address lasts for hours, carries all of a device’s traffic, and the ratio of inbound to outbound data looks like “everything at once”.

Models take into account, for example:

• connection duration and data volume to a single address;
• the number of different “sites” a device has stopped visiting directly;
• regular service packets of the same size (keepalives);
• a mismatch between the domain claimed in the SNI and the actual behaviour.

Responding to behavioural analysis is harder than to signatures: you need to change the shape of the stream, not just the headers. This is done by spreading traffic across several connections and ports, padding packets and adding pauses to match “ordinary” sizes, and periodically changing parameters. This is where the line runs between protocols that “disguise” and protocols that adapt.

How modern protocols respond

TLS disguising and REALITY

The idea: a connection to a VPN server should be indistinguishable from an HTTPS connection to a big website. In REALITY, the server answers the client with a genuine TLS handshake for someone else’s domain, which it takes from the real site. An analyser that tries to connect to the address itself sees the real site with a real certificate. Only a client with the right key gets a tunnel inside. That’s how VLESS with REALITY works; the client fingerprint is also forged to match common browsers.

Obfuscation

An older trick: make traffic look like random noise and strip out recognisable handshake elements. That’s how Shadowsocks and obfuscated variants of other protocols work. It works against signatures, but worse against behavioural analysis, because “noise with no distinguishing marks” is itself atypical.

Port strategies

Filters tend to watch “known” ports more closely and apply rules to non-standard ones more cautiously, to avoid hitting legitimate services. Hence the tricks: running on port 443, where all of HTTPS lives, spreading connections across several ports, and switching ports on a drop. Some protocols use UDP where TCP is throttled, and vice versa — for example, Hysteria is built on top of QUIC.

Fast versus resilient: a trade-off

Disguising costs resources: extra bytes, extra connections, processing on the device. That’s why WireGuard stays the fastest but also the most noticeable, while disguised protocols are a bit slower but get through where it slows down. A sensible strategy is to keep both options on the same server and switch depending on the situation.

Why it works today and not tomorrow

The most common question to support. There are several answers, and usually more than one applies at once.

1. A new rule. Filtering rules are updated centrally and can appear overnight. A protocol that matched no rule now matches a new one.
2. Accumulated statistics. Behavioural models compute a probability, not a binary flag. An address receiving a steady stream gains “weight” over time and crosses the throttling threshold.
3. Different ISPs, different rules. It works at home but not on LTE, because the mobile carrier runs a different rule set, and roaming between networks applies a third one.
4. Targeted experiments. Some throttling is switched on for a limited time or in specific regions to measure the effect. Then the problem disappears as suddenly as it appeared.
5. Collateral blocking. Throttling QUIC or specific hosting ranges affects protocols that rely on them without any intention of targeting them specifically.

The practical takeaway: resilience doesn’t come from “the single best protocol” but from being able to quickly switch protocol, port and address. For what this looks like for a user in Russia, see the section on VPNs in Russia.

What MeduzaVPN ULTRA and protocol switching do

A MeduzaVPN personal server brings up every protocol at once: MeduzaVPN ULTRA, MeduzaVPN, WireGuard, OpenVPN, VLESS, V2Ray, Xray, Shadowsocks, Outline, Hysteria, SOCKS5, IKEv2 and SoftEther. The app switches between them without reinstalling and without signing in again. That is the answer to “works today, not tomorrow”: change one setting instead of hunting for a new service.

What’s inside ULTRA

MeduzaVPN ULTRA is built for all three filtering layers at once. Against address lists — a personal IP and switching locations. Against signatures — disguising traffic as ordinary, with no recognisable handshake. Against behavioural analysis — spreading across ports, adaptive parameters, and a stream shape close to ordinary sessions. Its speed still stays close to WireGuard, so ULTRA can be kept as the main protocol rather than a “fallback”.

What to do if something goes wrong

1. Switch protocol: WireGuard → ULTRA → VLESS. Each one is more resilient to filtering than the last.
2. Switch location: a new address in a different data centre removes a subnet block.
3. Check on another network to tell a block apart from a local problem.
4. Contact support: they can see the server’s status and the current known changes in the rules.

A kill switch in the app stops traffic from going out directly while the tunnel is reconnecting, and split tunneling lets you take services that don’t need the VPN out of the tunnel, reducing the “weight” of the stream to the server.

Honest limits

• There are no guarantees. Filtering is a race where the rules keep changing. Any promise of “100% stability” is inaccurate. A realistic promise is a set of protocols where at least one usually works, and fast switching between them.
• The fact of a connection can’t be hidden. The ISP always sees that you’re connected to some address and how much you transferred. The protocol’s job is to keep that connection from being classified as a VPN, not to make it invisible.
• A complete lockdown is possible. If an ISP decides to allow only a whitelist of addresses, no protocol will help. Such regimes have been applied locally and briefly, but they can’t be ruled out.
• Disguising costs speed. Resilient protocols are a bit slower than fast ones. That’s the price, not a flaw.
• A personal IP isn’t armour. It removes list-based blocking but doesn’t protect against DPI. Combined with the protocol — yes; on its own — no.

Conclusion

Filtering works on three layers: addresses, signatures, behaviour. A personal IP closes the first, TLS disguising and obfuscation the second, and adaptive protocols like MeduzaVPN ULTRA the third. No single trick lasts forever, so the real value is having every protocol on one server and switching between them in the app.

MeduzaVPN gives you a personal server with its own IP in 60+ locations and the full set of protocols, including ULTRA. Subscriptions come with 7 days free — enough to check what actually works on your network. See plans.

FAQ