VPN blocked by DPI: how deep packet inspection works and what helps
What deep packet inspection is, how it spots VPN traffic and how Reality, Trojan and Hysteria2 approach it, with honest limits and practical steps to try.
Your VPN worked yesterday. Today it connects and freezes, or does not connect at all, while the internet itself works fine. On many networks the reason is deep packet inspection (DPI): equipment that looks not only at where traffic goes, but at what it looks like. This guide explains what DPI can see, how Colitu's transports approach it and what you can do, without pretending that any protocol is invisible.
What DPI is
Ordinary routing looks at addresses and ports. DPI goes further: it examines the start of each connection, the shape of the traffic and sometimes the content of unencrypted packets, then classifies the flow and applies a rule: let it through, slow it down or cut it. Operators use DPI for traffic management, companies for security, and states for filtering. In Russia, such equipment installed at operators is known as TSPU.
What DPI looks at
- Addresses. The simplest method: a list of blocked IP addresses or networks. No protocol helps if the server's address itself is blocked.
- Handshakes. Many classic VPN protocols start with recognisable messages. WireGuard, for example, uses fixed message types and sizes, and makes no attempt to hide them.
- The TLS greeting. In a TLS connection the first message (ClientHello) carries the requested site name (SNI) in clear text and has a "fingerprint" made of cipher suites and extensions. A client that does not look like a common browser stands out.
- Traffic shape. Packet sizes and timing reveal patterns, for example TLS traffic wrapped inside another TLS connection.
- Randomness. Traffic that looks like pure random data from the very first byte is itself a signal; researchers have documented filtering systems that block it on that basis.
- Active probing. The filter connects to a suspected server itself and watches how it answers.
What a DPI block looks like
- the connection fails during the handshake;
- the connection opens, carries a little data and then freezes;
- the speed drops to an unusable level;
- it works on one network (home internet) and fails on another (a mobile operator).
How Colitu's transports approach DPI
Every Colitu server offers five transports, built on different ideas:
- VLESS Reality has no certificate of its own. It borrows the TLS 1.3 handshake of a real third-party site, so a probe that connects to the server sees that site. Details: VLESS Reality.
- VLESS XHTTP carries data as an HTTP-like stream of separate upload and download requests over Reality. It is useful where long single TCP connections are cut. Details: VLESS XHTTP.
- Trojan runs over real TLS and looks like HTTPS. A client with a wrong password gets the behaviour of an ordinary web server. Details: Trojan.
- Hysteria2 runs over QUIC with TLS 1.3 and a real certificate, so it resembles HTTP/3. It depends on UDP getting through. Details: Hysteria2.
- Shadowsocks 2022 uses AEAD encryption with replay protection and has no recognisable handshake. It is light and fast, but where filters target random-looking traffic it is more exposed. Details: Shadowsocks 2022.
| Transport | Disguise idea | Main weak spot |
|---|---|---|
| VLESS Reality | Handshake of a real site | TCP, slower on lossy links |
| VLESS XHTTP | HTTP-like requests over Reality | TCP, slower on lossy links |
| Trojan | Ordinary HTTPS | Relies on its own TLS certificate |
| Hysteria2 | HTTP/3 over QUIC | Networks that limit UDP |
| Shadowsocks 2022 | No recognisable pattern | Randomness can be a signal |
The honest limits
No transport is undetectable and none is unblockable. Filtering systems change over time, and a network operator can always block a server's address or allow only an approved list of services. That is exactly why Colitu does not rely on one "magic" protocol: it keeps several transports with different strengths and lets the app choose the one that works on your network right now. We cannot promise that any transport will work on every network.
What Adaptive Connect does when DPI interferes
Adaptive Connect does not trust a successful handshake alone. A transport is accepted only when real traffic passes a check. That matters against DPI, which often lets the handshake through and then freezes the data. A transport that carried nothing is pushed back, Android remembers the last working transport for each server, and the Windows app checks every two seconds whether the tunnel still carries traffic and reconnects if it stops. Apps also report which transports worked to the panel in aggregate, so defaults improve over time.
What you can do
- Keep the app updated.
- Let the app finish connecting; on a filtered network the first connection can take longer.
- Try another location: if one server's address is blocked, another may work.
- Compare with another network, for example Wi-Fi instead of mobile data, to see whether the problem is tied to one operator.
- Write to support with your operator, region and the time the problem started; that helps us see patterns.
Rules on using VPNs differ by country. You are responsible for following the laws that apply to you. Related reading: UDP blocked and connection problems in the help centre.
Sources
- RFC 8446: TLS 1.3
- RFC 9000: QUIC
- WireGuard whitepaper
- Project X (Xray) documentation
- REALITY on GitHub
- Trojan protocol description
- Hysteria 2 documentation
- Shadowsocks SIP022: Shadowsocks 2022 edition
- Wu et al., How the Great Firewall of China detects and blocks fully encrypted traffic (USENIX Security 2023)
- OONI: Open Observatory of Network Interference