A person set up WireGuard on a rented server. Configured it, tested it, enjoyed it for a week. Then one morning the tunnel stopped coming up — not from the phone, not from the laptop, not through another carrier, even though the server was alive and nobody had touched the config.
The story is so typical that it hardly needs telling anymore. I have seen dozens of cases like this, and the question is always the same: how can strong encryption be in place, nobody has read the contents, and yet the connection is blocked?
Exactly. Nobody read anything. More precisely, they did not need to.
Why pure WireGuard is visible with your eyes closed
Imagine watching people leave a building through frosted glass: you cannot make out their faces or what they are carrying. But if someone always leaves with a package of exactly the same size and follows the same sequence of movements, you can identify them without ever seeing their face. That is essentially what happens with WireGuard. When I first looked at a handshake capture, I was almost annoyed at how much the protocol gave itself away. The first client packet has a fixed length, the server response has another fixed length, and the beginning of the packet contains a message-type field with several known values.
No cryptanalysis is needed here. A rule such as “a UDP packet of this length, with these bytes at the beginning, going to an address outside the country” is enough. It can be written quickly and remain useful for years because the protocol structure does not change — it is part of the specification.
That explains why WireGuard can be blocked even though it has done nothing wrong. It is simply recognizable. That is the price of its compactness: the authors deliberately removed everything unnecessary, and diversity was one of the things left out. The protocol has no built-in traffic masking. When networks were friendly, nobody cared. I did not either. For years I considered a regular, predictable handshake a sign of good engineering, and I still do. Just with a qualification now.
[Image: packet comparison diagram — pure WireGuard and the obfuscated variant]
What AmneziaWG does: noise, junk and changing packet sizes
By 2026, AmneziaWG is a WireGuard fork developed by the Amnezia team. The cryptography inside is the same; it was not changed at all, and in my view that is the only sensible choice: modifying proven cryptography just for traffic masking is an idea that makes me nervous. What changed is the appearance. It works in three main ways.
Junk packets before the handshake. Before the exchange starts, the client sends several packets of random length and content, so the beginning of the session no longer looks like the familiar first packet.
Handshake packet padding. Random extra data is added to initiation and response packets. Their length is no longer fixed — and fixed length was the basis of one of the most persistent filtering rules.
Header substitution. The bytes identifying the message type are replaced with arbitrary values agreed between the client and server. The signature is broken.
What is the result? Simple signature-based rules stop matching. VPN traffic obfuscation works here like noise on the airwaves: the signal is still there, but the old filter can no longer isolate it. It is a straightforward solution, and I have recommended it to people who had exactly this problem.
The knobs you can turn — and why you would turn them
WireGuard obfuscation is configured through parameters, and that is both an advantage and a headache. The set includes Jc for the number of junk packets, Jmin and Jmax for their size range, S1 and S2 for how much to pad initiation and response packets, and H1–H4 for replacing message-type values.
The key point that almost everyone misses is this: these values must match on the client and the server. Completely. If they differ by one, the connection will not come up, often silently, without a useful log entry telling you where to look. I once lost an evening to exactly this: I edited the server config, changed the client from memory and got one number wrong. A large share of AmneziaWG configuration problems comes down to this. Compare the configs byte by byte, not by eye.
Why change the values if everything already works? Because the parameter set is also a fingerprint. If a million people use the same values from a popular guide, a million connections will have the same traffic profile, and eventually a new rule can describe that profile — not pure WireGuard this time, but “obfuscated exactly this way.” That leads to the part of this technology I like least. Obfuscation requires maintenance. It is not “configure it once and forget it”; it is “watch it and change the values,” and if you do not routinely revisit your infrastructure, the scheme will eventually come back to bite you.
Obfuscation and mimicry are not synonyms
This is the key idea of the entire article. It is worth saying slowly.
Obfuscation means “make it unlike anything”: traffic becomes a shapeless stream of random-looking bytes, and the filter cannot say what it is. Mimicry is different: “make it look like something specific and permitted.” A stick insect does not become invisible — it becomes a branch.
The difference appears when the filtering logic changes. As long as the system works on the principle “block everything identified as a VPN,” obfuscation works very well: there is nothing obvious to identify. But switch to “allow only traffic identified as permitted,” and the shapeless stream loses immediately: it does not belong to any allowlist and is rejected automatically. This is not a hypothetical scenario. Such filtering is already used in tightly controlled networks, and I have seen it in practice — not at the scale of an entire country, but at regional scale.
Reality takes the second route: it does not add noise, but performs a TLS handshake while presenting the certificate of a real third-party site — a large, popular and presumably permitted one. If the checking system follows the same address, it sees a working website.
AmneziaWG vs VLESS + Reality: where each approach fits
I am comparing the technologies, not the teams behind them: both were built by people who understand what they are doing.
| Criterion | AmneziaWG | VLESS + Reality | Shadowsocks with a plugin |
|---|---|---|---|
| Masking principle | Noise and random sizes | Mimicry of a real website | Noise or a TLS wrapper |
| What an observer sees | An ambiguous UDP stream | A normal HTTPS connection | An ambiguous TCP stream |
| Behavior under allowlists | Poor, it does not look permitted | Good, it looks like permitted traffic | Poor |
| Active server probing | The port does not respond with anything meaningful | It responds as the real cover site | Depends on the plugin, often vulnerable |
| Overhead | Present, depends on parameters | Minimal | Small |
| Speed | Slightly below pure WireGuard | High | High |
| Configuration complexity | Medium, parameters must be synchronized | Medium, usually preconfigured by the provider | Low |
| What to fix when it breaks | Choose new parameters | Change the cover site or node | Change the plugin |
In short, current traffic mimicry under HTTPS is more resilient than simply adding randomness. Not because obfuscation is bad — it leaves a clue, namely the fact that the traffic is unusual, and that clue can be enough.
AmneziaWG does have an advantage that Reality does not. It is still WireGuard, so you retain its speed, seamless roaming and low battery requirements. When the environment allows it, that combination is excellent, and I would use it myself.
Compatibility: clients, routers, and what actually supports it
The ecosystem is noticeably narrower than that of ordinary WireGuard.
Amnezia clients exist for the major platforms and work, and some universal applications have also added support. But “some” and “all” are different things. Ordinary WireGuard runs on almost any hardware, including consumer routers. AmneziaWG is different: you need custom firmware, a manually built module, or nothing. I once spent a weekend trying to get it running on a home router and eventually gave up. One more hardware detail: both sides must speak the same protocol. A server running AmneziaWG will not accept an ordinary WireGuard client. That is not a bug; it follows directly from the header modifications.
What you pay for: overhead and reduced speed
Obfuscation is not free. I have noticed that this is rarely mentioned, although it should be.
[Image: diagram of overhead at different obfuscation aggressiveness levels]
Junk packets are real bytes sent over the network, and padded handshake packets are real bytes too. With aggressive settings, each connection transfers noticeably more traffic than the useful payload alone requires. On a home wired connection this is negligible. On mobile data with a traffic limit, it is not, especially when the tunnel reconnects frequently. The phone switches between towers, you enter an elevator, the network flickers, and the whole process starts again. There is also connection-establishment latency. Fractions of a second, of course, but after ten reconnects in a day they add up to something noticeable.
When you do not need obfuscation at all
This section can save someone an evening. Nobody wrote it for me back then.
If everything already works, do not touch it. Ordinary WireGuard comes up and stays connected? Then your provider either does not filter it or filters it loosely, and obfuscation will only reduce speed, increase traffic consumption and introduce another failure point without giving you anything in return. It is also unnecessary inside a corporate network: nobody is blocking a tunnel between an office and a warehouse, and adding masking to a corporate environment means complicating something that should be boring and predictable. It is unnecessary on café Wi-Fi too: the threat there is another person on the same network, not a state-level filter, and ordinary encryption protects against that.
Conversely, obfuscation for bypassing restrictions in Russia becomes meaningful exactly when simple options no longer connect. It is easy to check: connect and run a connection check. If the address changes, there are no leaks and the speed is acceptable, there is no reason to make the setup more complicated.
What this means in practice
Pure WireGuard can be identified by the shape of its packets, not their contents.
But noise and mimicry solve different problems, and when networks move to allowlists, noise loses. Reality holds up better because it does not merely hide — it actually behaves like the thing it claims to be.
And the general rule I repeat to everyone, including myself, is this: do not build your defenses around a single protocol. One thing works today; six months from now, something else may be required.
Understanding obfuscation parameters, synchronizing client and server values and choosing new ones after every change in filtering is a hobby in itself, and I completely understand people who enjoy it. If you are not one of them, use ready-made VLESS with Reality: 14 days of testing without a card, everything configured, and node switching directly in the app. Clients are available in the downloads section, and if something does not connect, support can troubleshoot the specific carrier rather than sending a generic reply.
Frequently asked questions
What is AmneziaWG?
It is a WireGuard fork that changes the external appearance of the traffic: junk packets are added before the handshake, initiation packets are padded with random data, and message-type bytes are replaced. The original cryptography remains intact; only the masking changes. The goal is to break the signatures that filters use to identify ordinary WireGuard.
How is obfuscation different from Reality?
Obfuscation makes traffic unlike anything else — a shapeless stream without recognizable signs. Reality makes it resemble something specific: an ordinary HTTPS connection to a real popular website, including that site’s genuine certificate. The first approach helps against rules that block identified VPN traffic; the second can also handle allowlists and active server probing.
Does obfuscation slow down the internet?
Download speed after the connection is established is affected very little; most of the overhead occurs at the beginning of the session. However, the amount of service traffic and connection setup time increase, and aggressive settings are noticeable on mobile connections with data limits. The more often the tunnel reconnects, the more expensive the masking becomes.
Does everyone need obfuscation?
No. In fact, most people do not need it. If an ordinary tunnel connects and stays connected, obfuscation only adds traffic costs and another potential source of problems. It becomes useful where simple protocols no longer pass the filter. The fastest way to check is simply to connect and see whether it works; on mobile internet, also check whether the connection survives network changes.
