VPN censorship and protocol analysis
How AmneziaWG 3.0 fights VPN fingerprinting
AmneziaWG 3.0 changes more than a few recognizable WireGuard packet markers. It varies technical details across the connection, including protected header fields, packet padding and timing. The aim is to stop a filtering system from building one stable statistical profile for every AmneziaWG session.
Amnezia announced the release on August 26 in response to a new round of VPN blocking in Russia. The company believes Russia's TSPU filtering equipment now combines traffic behavior with destination IP monitoring instead of matching only a known protocol signature. That explanation is plausible, but it remains Amnezia's working model of a closed censorship system rather than an independently verified description of its rules.
Who gets AmneziaWG 3.0 and 3.1
Amnezia uses both versions in current products. The split below reflects the English documentation checked on August 26, 2026. Managed connections and exported configuration files are separate cases, which explains some apparently conflicting version numbers in Amnezia's support pages.
| Product or route | Current version | What users need |
|---|---|---|
| Amnezia Premium in AmneziaVPN | AmneziaWG 3.0 | AmneziaVPN 5.0.0.5 or later |
| Amnezia Free | AmneziaWG 3.0 | AmneziaVPN 5.0.0.5 or later |
| Self-hosted | AmneziaWG 3.1 | AmneziaVPN 5.0.1.5 or later and a new 3.1 container |
| Exported Premium configuration | AmneziaWG 3.1 | A compatible app or router; 2.0 conversion does not work |
The managed Premium and Free status comes from Amnezia's current English FAQ. Its Premium dashboard documentation separately says newly issued configuration files use 3.1. Self-hosted 3.1 arrived with AmneziaVPN 5.0.1.5.
Why encrypted VPN traffic can still be recognized
WireGuard encrypts the content carried through its tunnel, but encryption does not erase every fact about a connection. A network operator can still observe the server IP, direction, packet length, order, timing, connection duration and overall volume. Standard WireGuard also has compact message types with recognizable sizes and handshake behavior.
A classifier does not need to read a message if those outside characteristics are distinctive enough. In 2022, researchers demonstrated a detection framework that combined byte patterns, packet sizes and active probing to identify OpenVPN traffic, including many configurations that used obfuscation. The work found more than 85 percent of OpenVPN flows in the authors' controlled evaluation and detected 34 of 41 obfuscated configurations. The USENIX paper does not test AmneziaWG, but it shows why encrypted payloads and a single masking layer do not end protocol fingerprinting.
Traffic fingerprinting diagram
What changes when obfuscation covers the whole connection
WireGuard
Stable profile- Encrypted payload
- Recognizable message types and sizes
- Regular handshake and keepalive behavior
Earlier AmneziaWG
Signatures altered- Configurable headers and padding
- Junk and signature packets
- Other repeated flow traits may remain
AmneziaWG 3
Profile varied- Protected header fields
- Variable content padding and timings
- 3.1 can add random packet trailers
What a censor may still observe
Destination IP, connection volume, direction, aggregate timing and repeated behavior across many users remain available to an on-path observer. AmneziaWG 3 raises the classification problem. It does not make the connection invisible.
What AmneziaWG 3.0 changes
Earlier AmneziaWG versions already altered WireGuard's obvious packet signatures. They supported configurable message headers, handshake padding, junk packets and custom signature packets. Version 3.0 keeps those tools and adds variability that persists beyond the opening handshake.
| Mechanism | What the code does | What it is meant to change |
|---|---|---|
| Header protection | Transforms selected low-entropy header values with a shared key | Reduces stable message-type markers |
| Content padding | Adds a configurable random amount of padding | Varies packet-length patterns during data transfer |
| Timing ranges | Varies rekey, retry, reject and keepalive timing | Reduces repeated timing fingerprints |
| Keepalive range | Chooses intervals from a range instead of one fixed value | Makes idle connections less mechanically regular |
These behaviors are documented in the public amneziawg-go repository and the 3.0 implementation commit. Header protection uses a ChaCha20-based transformation for technical header bytes. The WireGuard tunnel already encrypts the payload. Describing this as stronger content encryption would be misleading.
What AmneziaWG 3.1 adds
Version 3.1 is a smaller iteration of the 3.0 design. The public comparison between the tags adds random trailers to the end of packets and an option that prevents the server from sending WireGuard cookie replies. It also raises a minimum padding requirement for header protection and includes fixes around packet handling.
Random trailers create another source of packet-length variation. Disabling cookie replies removes a response pattern that could help an active detector, though cookie messages also exist as part of WireGuard's denial-of-service protection. The design therefore changes a security and operational behavior as well as a fingerprint. Independent review would help clarify that trade-off under load and attack.
What Amnezia believes Russia's TSPU is doing
Amnezia says recent blocking did not behave like an immediate match on one packet. New servers sometimes remained accessible for hours or days, while the speed of blocking varied by ISP, traffic volume and connection density. The company's hypothesis is that TSPU combines several indicators into a score, then subjects a server IP to deeper inspection or blocking after the score crosses a threshold.
Possible indicators include packet sizes and sequence, time between packets, handshake behavior, keepalives, total traffic, repeated session statistics and the number of connections reaching one destination. The destination IP may then be blocked even when the classifier is not certain about every individual flow. In some cases a larger subnet may be affected.
Independent evidence supports the broader possibility. Human Rights Watch documented experiments involving statistical data about visits to IP addresses, as well as VPN disruption that changed by provider, region, ISP, time and fixed or mobile access. Its 2025 Russia censorship report also lists AmneziaWG among protocols that had been targeted. That finding does not prove the precise 2026 scoring process described by Amnezia.
Why fighting VPN censorship is so hard
Protocol developers work against an observer that can change tactics after every release. If one signature disappears, the censor can look for a combination of weaker signals. If traffic classification becomes unreliable, it can block the destination IP. If that causes too many false positives, it can apply the rule only on certain networks or during politically sensitive periods.
Russia's filtering system adds an operational complication. TSPU equipment is centrally controlled but deployed through many internet providers. Censored Planet found that the system could react to server names, destination IPs and QUIC traffic using several interference behaviors, including dropped or modified packets. The measurement project helps explain why two users can get different results without either user being wrong.
Popularity can also work against a circumvention tool. A private self-hosted server may initially have little reputation as a VPN endpoint. Once many suspicious-looking connections converge on it, the IP becomes easier to score or block. Changing the packet profile cannot hide the existence of the destination.
Network blocking is only one layer. Authorities can remove apps, block download sites, pressure hosting providers, restrict VPN advertising or disrupt the channels used to send connection keys. Human Rights Watch reported around 469 VPN services blocked by late February 2026, alongside growing legal restrictions on promoting circumvention tools. Its August 2026 briefing places the protocol fight inside that wider system.
No transport can cover every failure mode. UDP may be throttled, an endpoint may be blacklisted, or a mobile network may allow only approved services. People who depend on circumvention need more than one tested route, copies of installation files, and a way to receive new configuration information when the usual channel is blocked.
WireGuard, AmneziaWG 2.0, 3.0 and 3.1 compared
| Version | Main approach | Connection-wide variation | Current role |
|---|---|---|---|
| WireGuard | Small, fixed protocol with encrypted payloads | No anti-fingerprinting layer | Fast baseline where blocking is light |
| AmneziaWG 2.0 | Configurable headers, padding and extra packets | Limited compared with version 3 | Older compatible self-hosted route |
| AmneziaWG 3.0 | Header protection plus packet and timing variation | Yes | Managed Premium and Free connections |
| AmneziaWG 3.1 | 3.0 design plus random trailers and cookie control | Yes, with added packet-length variation | Self-hosted and exported Premium configs |
DoVPN's VPN protocol comparison records the public source, assessment and restricted-network evidence for AmneziaWG alongside other provider-developed technologies. The released registry remains a dated research snapshot, so this article supplies the newer version context without silently rewriting the archived dataset. The separate protocol transparency report explains why public code and an independent assessment are different forms of evidence.
What self-hosted users need to do
Amnezia recommends version 3.1 for self-hosted servers. This is not an in-place conversion of a 2.0 configuration. Users need AmneziaVPN 5.0.1.5 or later, must remove the older AmneziaWG container, install the new one, then recreate users and issue new keys or configuration files. The existing 2.0 container can continue to work, but it does not gain 3.1 behavior by updating only the client.
The detailed sequence is covered in our updated Amnezia VPN self-hosted guide. Do not delete a working fallback before confirming that 3.1 connects, routes traffic and survives a reconnect on every device you depend on. An early Windows issue report describes a 3.1 handshake with no traffic on one self-hosted setup. That is useful troubleshooting evidence, not proof of a general defect.
Router users need particular care. Amnezia says common router operating systems do not yet support 3.1 natively, and a 3.1 configuration cannot be converted into a 2.0 file. Keep the older route or use a compatible client until the router's actual firmware and Amnezia instructions support the new parameters.
What users can verify for themselves
- Record the working app, server and protocol versions before changing anything.
- Create the new connection without destroying the only working fallback.
- Test the sites and apps that matter on the restricted network itself.
- Verify the exit address and DNS route with DoVPN's IP leak test.
- Interrupt the tunnel and check the expected behavior with the kill switch test.
- Retest after network changes, app updates and periods of intensified blocking.
A successful test today is evidence for that device, server and network at that time. It is not a permanent guarantee. Our guide to VPNs and other tools for unblocking websites explains when a different protocol or access method may be the better fallback.
What remains unknown
- No public benchmark gives an AmneziaWG 3 detection or false-positive rate.
- No dedicated public third-party assessment identifies the 3.0 or 3.1 implementation.
- TSPU's current classifier, thresholds and IP scoring rules remain closed.
- Long-term reliability across Russian ISPs and mobile networks has not been established.
- The performance and denial-of-service trade-offs of 3.1 cookie control need study.
DoVPN's hands-on Amnezia Premium review is still in progress. The final assessment will separate provider claims from app tests and restricted-network evidence under our published VPN review methodology. We will not assign a censorship-resistance score from the release announcement alone.
Sources
- AmneziaVPN 5.0.1.5 release article for the self-hosted 3.1 and managed 3.0 rollout.
- Amnezia English FAQ for the current Premium, Free and self-hosted version requirements.
- amneziawg-go source, its 3.0 implementation and 3.1 comparison for code-confirmed mechanisms.
- Censored Planet TSPU measurements for independent analysis of Russia's filtering infrastructure.
- Human Rights Watch's Russia censorship report for documented VPN blocking methods and uneven network effects.
- USENIX Security research on VPN fingerprinting for independent evidence that encrypted and obfuscated traffic can retain detectable characteristics.
AmneziaWG 3.0 and 3.1: FAQ
AmneziaWG 3.0 is a WireGuard-based protocol update designed to vary more of the traffic profile seen by an on-path filtering system. Its public implementation protects selected header fields and can vary content padding, handshake timing, keepalive timing and related connection behavior.
Version 3.0 is the larger redesign. Version 3.1 builds on it with random packet trailers, an option to disable WireGuard cookie replies, stricter parameters and implementation fixes. Amnezia currently deploys 3.1 for self-hosted servers while its managed Premium and Free connections use 3.0 in the main app.
The user payload is still protected by WireGuard. The new header protection and randomization target technical fields and observable traffic behavior that a classifier could use to identify the connection. They do not replace WireGuard cryptography or make the payload more encrypted.
Yes. A censor can adapt its classifier, block a server IP or subnet, probe suspected endpoints, disrupt UDP, or restrict traffic to an allowlist. AmneziaWG 3 is designed to make reliable classification harder, not to guarantee access on every network.
No. Amnezia says older clients do not support the new format. Self-hosted users moving to 3.1 must deploy a new container and create new users and configurations. Keep a known working route until the replacement has been tested.
Router support is still limited. Amnezia says common router operating systems do not yet provide native 3.1 support, and a 3.1 configuration cannot be converted into a 2.0 configuration. Check the exact router and client instructions before removing an older setup.
We did not locate a dedicated public security assessment or independent censorship-resistance benchmark for AmneziaWG 3.0 or 3.1 by August 26, 2026. The source code and releases are public, but public code is not the same as a third-party assessment or a measured detection rate.
