AmneziaWG Explained: The WireGuard Fork Built to Disappear

AmneziaWG is a fork of WireGuard-Go that modifies the protocol’s packet structure to defeat deep packet inspection. DPI identifies and blocks VPN traffic by shape rather than content, without decrypting anything. WireGuard’s Handshake Initiation is always exactly 148 bytes, with a 32-bit type field whose first octet is 0x01 and three reserved zero bytes. Its Response is always exactly 92 bytes. These values are universal across every WireGuard deployment, which means a single firewall rule identifies all of them simultaneously.

What changes is everything an observer can see without decrypting: header values, packet sizes, session timing, and the protocol behaviour the traffic appears to exhibit. The cryptographic core (Curve25519, ChaCha20-Poly1305, BLAKE2s, and the Noise_IK handshake) is identical to standard WireGuard.

What AmneziaWG is — and what it is not

Where standard WireGuard leaves every connection with an identical, universally-known packet fingerprint, AmneziaWG replaces that fingerprint with configurable, per-deployment alternatives while keeping the cryptographic core completely unchanged.

The short version, without the jargon

Standard WireGuard sends VPN traffic in a container with a fixed, recognisable shape. Every Handshake Initiation packet is exactly 148 bytes and carries a specific header byte. A deep packet inspection system learns this shape and blocks it without reading anything inside. AmneziaWG keeps everything inside the container unchanged (all the cryptography, all the encryption) and changes only the container: its dimensions, its markings, and the protocol it appears to open with. The contents are identical. The envelope is not.

Two things AmneziaWG does not do: it does not make your connection more encrypted, and it does not make you more anonymous. It makes the VPN harder to detect and block on networks that identify and suppress WireGuard traffic. If your VPN already connects without interference, AmneziaWG adds overhead with no benefit. If your WireGuard is being silently blocked by DPI, AmneziaWG addresses it.

A fork, not a wrapper

The fork-vs-wrapper distinction is not binary. Commercial obfuscation approaches for WireGuard fall into three categories, and AmneziaWG occupies the third one.

The first category is true wrappers: approaches that encapsulate an unchanged WireGuard session inside a different transport. Proton VPN’s Stealth wraps WireGuard inside an obfuscated TLS connection running over TCP. Mullvad’s Shadowsocks bridges, QUIC obfuscation, and UDP-over-TCP modes all place WireGuard traffic inside a different outer protocol. The WireGuard handshake inside is standard and unchanged; the obfuscation is an external layer. The full taxonomy of obfuscation techniques and their detection-resistance properties is covered in What Is an Obfuscated VPN?

The second category is in-place header modification: applying a scrambling operation to WireGuard packet headers without forking the protocol and without requiring matching configuration on both endpoints. Mullvad’s Lightweight WireGuard Obfuscation (LWO), launched in November 2025, works by scrambling the header of each WireGuard packet to make them harder to fingerprint, while the underlying WireGuard session remains unmodified. LWO stays on native UDP and adds minimal overhead, but it is vendor-controlled, not self-hostable with user-configurable parameters, and carries no protocol mimicry capability.

AmneziaWG occupies a third category: a fork of WireGuard-Go that modifies the protocol itself so obfuscation is an intrinsic property of every packet. H1–H4 header replacements, S1–S4 padding, junk packets, and I1–I5 protocol mimicry are all applied at the protocol level with parameters that both endpoints must share. NordLynx illustrates the contrast from another direction: WireGuard runs completely unmodified underneath NordVPN’s proprietary double-NAT layer, as covered in NordLynx Explained. AmneziaWG is the inverse: the protocol is modified at the implementation level.

The trade-off of forking rather than wrapping or scrambling is interoperability. With obfuscation parameters active, AmneziaWG is not compatible with standard WireGuard endpoints. Both sides must run AmneziaWG with matching parameters. With all parameters set to zero, AmneziaWG reverts to standard WireGuard behaviour and is fully interoperable. This backward compatibility is by design.

What AmneziaWG leaves untouched

AmneziaWG’s obfuscation operates at the transport layer only, modifying what an observer sees in packet headers and sizes. The cryptographic payload is unchanged.

The cryptographic core is identical to standard WireGuard: Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing, and the Noise_IK handshake pattern. None of these are modified. The full treatment of what each primitive does and why it was chosen is in WireGuard Explained; the AEAD mechanics of ChaCha20-Poly1305 are covered in VPN Encryption Explained.

Amnezia’s own security documentation states the architectural boundary precisely: obfuscation fields are authenticated using the same MAC tags as the primary headers. The authentication chain is unbroken.

WireGuard’s formal verification covers the cryptographic core and Noise_IK handshake, not AmneziaWG’s obfuscation layer. The obfuscation layer has been assessed through penetration testing by 7ASecurity across two engagements (July 2024, and December 2024 to January 2025) and has not been formally verified through symbolic or computational proof. The 2022 engagement (OTF Red Team Lab) reviewed the AmneziaVPN client applications before AmneziaWG existed as a protocol; it cannot be cited as coverage of the obfuscation layer. WireGuard’s cryptographic security proofs apply to AmneziaWG’s cryptographic layer. The obfuscation layer’s security rests on penetration testing evidence alone.

Origins

AmneziaWG was created by Russian internet activists. The idea for AmneziaVPN was born at the Demhack hackathon in autumn 2020, organised by Roskomsvoboda, a Russian digital rights organisation. The project continued through Roskomsvoboda’s Privacy Accelerator programme. Its founder is Mazay Banzaev, a developer and VPN expert.

The kernel module (amnezia-vpn/amneziawg-linux-kernel-module) is licensed under GPLv2, inherited from WireGuard’s kernel module. The userspace Go implementation (amnezia-vpn/amneziawg-go) is MIT-licensed, inherited from WireGuard-Go. Both repositories are public on the amnezia-vpn GitHub organisation.

In April 2023, Wired magazine featured Amnezia VPN as an example of open-source censorship circumvention operating in Russia (Masha Borak, “The Open Source VPN Out-Maneuvering Russian Censorship”). In February 2026, WhatsApp’s Help Center listed Amnezia VPN under its “Use a VPN” guidance alongside Mullvad and the Electronic Frontier Foundation.

Three engagements in total: the 2022 OTF Red Team Lab audit reviewed the client applications before AmneziaWG existed as a protocol. Both the July 2024 engagement and the December 2024 to January 2025 engagement (18 days, white-box, full ecosystem) covered the AmneziaWG protocol services alongside the client applications. Reports from all three are publicly available at 7asecurity.com.

Why WireGuard needed a fork

WireGuard was not designed to hide what it is; the protocol was built for speed and trusted networks. The consequence is a packet structure that is a deterministic fingerprint that any DPI system with a WireGuard signature loaded can match without decrypting anything.

WireGuard’s fixed packet signatures

WireGuard uses four packet types, each with a fixed message-type byte and a fixed total size:

• Handshake Initiation: type byte 0x01, always exactly 148 bytes
• Handshake Response: type byte 0x02, always exactly 92 bytes
• Cookie Reply: type byte 0x03, always exactly 64 bytes
• Transport Data: type byte 0x04, minimum 32 bytes

These values are universal across every WireGuard deployment. A DPI rule matching WireGuard’s fixed 32-bit type value (0x00000001) on a 148-byte UDP packet identifies a Handshake Initiation with certainty.

WireGuard’s exclusive use of UDP also removes the basic port-based workaround available to OpenVPN. OpenVPN can run on TCP port 443, making its traffic resemble standard HTTPS to stateless firewalls. WireGuard on UDP has no equivalent option. The full comparison of what TCP port 443 achieves and where it stops is in WireGuard vs OpenVPN. 

How DPI classifies traffic without decrypting it

A DPI system classifies traffic by observable characteristics: the first bytes of a packet, the total size, inter-packet timing, and the flow profile of a session. It identifies protocols from their structural signatures the way a trained eye reads a silhouette, and the silhouette of a WireGuard connection is distinctive enough to classify and block without ever seeing the payload.

A VPN encrypts your traffic’s content but does not conceal the fact that you are using one. A DPI system that identifies WireGuard by its packet structure can block it without knowing anything about where you are connecting or what you are doing. 

The wrapper alternative and its trade-offs

Providers who do not want to fork WireGuard either wrap the session inside a different transport or apply in-place scrambling to the packets. Proton VPN’s Stealth wraps WireGuard inside obfuscated TLS over TCP, adding a TLS processing layer and converting from UDP to TCP. Of Mullvad’s four obfuscation modes, three (Shadowsocks, QUIC, and UDP-over-TCP) are true wrappers; the fourth, Lightweight WireGuard Obfuscation (LWO), applies in-place header scrambling to WireGuard packet headers without modifying the session underneath.

Wrapping preserves interoperability with standard WireGuard: the protocol runs unchanged underneath the outer transport. The cost is the overhead of the wrapper itself and, in TCP-based approaches, the loss of native UDP operation.

AmneziaWG’s fork approach inverts this trade-off. It preserves native UDP operation and WireGuard-level performance on the Linux kernel module, and accepts interoperability loss. The right choice between wrapper and fork depends on what the censorship infrastructure is doing and what deployment constraints apply.

Russia’s TSPU — the operational pressure that drove the protocol

Russia’s TSPU (Technical Means of Countering Threats) consists of DPI boxes installed at the access network of every major ISP in Russia under the 2019 Sovereign Internet Law. Unlike China’s Great Firewall, which operates at border chokepoints, TSPU enforcement is decentralised: it is applied at individual ISP access networks. This architecture explains why WireGuard blocking in Russia happened progressively across different carriers through 2025 rather than in a single simultaneous event across the entire country.

By October 2024, TSPU could identify and suppress WireGuard, OpenVPN, IKEv2, IPsec, L2TP, and PPTP traffic. WireGuard handshakes began failing silently on affected networks: no error message, no timeout, simply no response from the server. AmneziaWG was built to outlast this adversary, and each version of the protocol responds directly to a detection capability its predecessor could not defeat.

How AmneziaWG defeats DPI — the obfuscation mechanism

AmneziaWG applies four distinct layers of obfuscation simultaneously on every connection, each targeting a different method by which a DPI system might identify WireGuard traffic.

Layer 1 — Header randomisation (H1–H4)

H1, H2, H3, and H4 are AmneziaWG’s configurable replacements for WireGuard’s four fixed 32-bit type fields, one per packet type. A DPI rule that matches WireGuard’s 0x01 type byte finds nothing to match once H1 is set to a different value.

In version 1.0, H1–H4 were fixed per-deployment values. Every connection from a given deployment used the same custom header bytes, which was better than WireGuard’s universally known values but statically learnable by a patient DPI system that observed enough traffic from that deployment.

In version 2.0, H1–H4 became ranged values. For each packet sent, a random value is drawn from the configured H1–H4 range. On receipt, any value within the range is accepted. No two packets from the same deployment necessarily carry the same header value. One constraint applies: the four ranges must not overlap, since the protocol still needs to distinguish packet types on receipt.

The result is that no universal header signature exists for AmneziaWG 2.0 connections. A DPI rule cannot be written against a stable, predictable pattern because the pattern changes per packet. H values must be 5 or greater; values 1–4 are WireGuard’s own reserved type identifiers and setting H1–H4 to those values produces standard WireGuard behaviour rather than obfuscation.

Layer 2 — Junk-byte padding (S1–S4)

WireGuard’s fixed packet sizes are its second DPI fingerprint. S1 through S4 are padding values: a configured number of random bytes prepended to each packet type.

• S1 pads the Handshake Initiation. New size: 148 + S1 bytes.
• S2 pads the Handshake Response. New size: 92 + S2 bytes.
• S3 pads the Cookie Reply. New size: 64 + S3 bytes. (Introduced in version 2.0.)
• S4 pads Transport Data packets. New size: payload + S4 bytes, with S4 capped at 32 bytes. (Introduced in version 2.0.)

Before version 2.0, only the two handshake messages had variable sizes. Transport Data packets retained their fixed overhead. Version 2.0 extended variable sizing to all four message types, removing the last predictable size signature from the observable packet stream.

One non-obvious constraint applies to S1 and S2: S2 must not equal S1 + 56, and S1 must not equal S2 + 56. The Init packet is 148 bytes; the Response is 92 bytes; the difference is 56. If S2 = S1 + 56, the padded Init and padded Response become the same size, reintroducing a size-based signature. The same relationship holds between S3 and S4 on Cookie Reply (64 bytes) and Transport Data. Every AmneziaWG installer enforces this constraint automatically; users setting parameters manually must verify it. Example values of S1 = 50, S2 = 30 satisfy it; S1 + 56 = 106, which does not equal 30.

Layer 3 — Junk packets (Jc, Jmin, Jmax)

Before every handshake, the client sends Jc packets of random size between Jmin and Jmax bytes. These carry no payload and are discarded by the server upon receipt. They blur the characteristic two-message WireGuard handshake sequence, turning the session opening into a variable-length burst with no fixed structure or predictable timing.

Junk packet parameters are configured on the client side only. The server accepts and discards them without server-side configuration.

One constraint applies to Jmax: if it is set to a value at or above the system’s MTU, junk packets may be fragmented across multiple IP packets before the handshake begins. Fragmented UDP traffic in that position is itself an unusual observable pattern to a DPI system. Jmax should be set below the system MTU.

Layer 4 — Protocol mimicry: I1–I5 and CPS

The first three layers defeat signature-based DPI by removing predictable header values and packet sizes. Layer 4 addresses a different detection approach: heuristic classification that treats all non-fingerprinted, high-entropy UDP traffic as suspicious.

Version 1.5 introduced I1–I5: up to five UDP packets sent before every handshake. Only I1 carries the protocol snapshot: a hex snapshot of the opening of a legitimate, permitted UDP protocol such as QUIC, DNS, or SIP. I2–I5 increase entropy through counters, timestamps, and random data. To a passive DPI classifier, the session’s opening resembles a known, permitted protocol type rather than unidentified encrypted data.

Version 2.0 formalised this capability into the CPS (Custom Protocol Signature) system: a structured tag builder that makes it possible to construct protocol-mimicry packets from composable components. CPS uses six tag types, each with a precise function:

• <b hex_data>: static bytes for protocol imitation (arbitrary length)
• <t>: a 32-bit Unix timestamp in network byte order
• <r length>: cryptographically secure random bytes (length ≤ 1000)
• <rc N>: random ASCII letters [A–Za–z], for text-protocol fields such as connection IDs (N ≤ 1000)
• <rd N>: random decimal digits [0–9], for numeric field simulation (N ≤ 1000)
• <c>: packet counter, a 4-byte field containing the count of packets sent by AmneziaWG, used to increase entropy in subsequent I-packets

A typical I1 packet targeting QUIC mimicry is structured as: i1 = <b 0x...><rc 8><t><r 50>. The static bytes open with the QUIC Initial header pattern; random ASCII characters fill a connection ID field; a timestamp provides a plausible time value; and cryptographically secure random bytes fill the remaining payload.

The I1–I5 signature-packet capability was introduced in version 1.5; the CPS tag builder that structures those packets was introduced in version 2.0. Amnezia’s own self-hosted documentation settles the point: “compared to the AmneziaWG 1.0 protocol, AmneziaWG 1.5 introduced the I1–I5 parameters, which are also used in the AmneziaWG 2.0 protocol.”

What the four layers achieve together

A DPI system examining an AmneziaWG 2.0 connection sees: an opening sequence resembling a permitted UDP protocol (I1–I5 via CPS), followed by a variable-length burst of packets with no fixed structure (Jc junk packets), then a stream of traffic with per-packet randomised headers (H1–H4 ranges) and variable sizes on all four message types (S1–S4 padding). No universal signature exists because every deployment uses different parameter values and every packet within a session draws a different header value from its configured range.

These four layers address passive DPI and heuristic classification. They do not provide active probing resistance: the server ignores CPS and junk packets and waits for a valid WireGuard handshake; it does not respond to probes as though it were the service it impersonates. 

A third-party server-side proxy, the WireSock proxy (wiresock/amneziawg-install), adds active probing resistance above AmneziaWG for self-hosters who need it.

A minimal AmneziaWG configuration, annotated

All four obfuscation layers map directly onto an AmneziaWG configuration file. Assembled, they also make visible the constraints that apply between parameters. The following is a representative client-side configuration:

[Interface]
PrivateKey = [your-private-key]
Address = 10.0.0.2/32
DNS = 1.1.1.1
MTU = 1280    # Community troubleshooting floor; official default is 1420
 
# Layer 3 — junk packets before the handshake (client-side only)
Jc = 4         # Send 4 junk packets before each handshake
Jmin = 64      # Minimum junk packet size in bytes; documented floor is 64
Jmax = 1000    # Maximum junk packet size; must remain below MTU
 
# Layer 2 — padding on each message type (must match server)
S1 = 50        # Random bytes prepended to Handshake Init; range 0-64 (v1.0+)
S2 = 30        # Random bytes prepended to Handshake Response; range 0-64 (v1.0+)
S3 = 20        # Random bytes prepended to Cookie Reply; range 0-64 (v2.0+)
S4 = 15        # Random bytes appended to each Data packet; range 0-32 (v2.0+)
 
# Layer 1 — header replacement ranges (must match server; ranges must not overlap)
# v1.0/1.5: single fixed value, e.g. H1 = 1234567
# v2.0: range notation; each packet draws a random value from the range
H1 = 100000-200000          # Replaces WireGuard's 32-bit 0x00000001 Init type field
H2 = 1000000-2000000        # Replaces WireGuard's 32-bit 0x00000002 Response type field
H3 = 10000000-20000000      # Replaces WireGuard's 32-bit 0x00000003 Cookie Reply type field
H4 = 100000000-200000000    # Replaces WireGuard's 32-bit 0x00000004 Data type field
# Valid span: 0 to 4,294,967,295; keep values below 2,147,483,647 for
# broadest client compatibility (some Windows builds cap at INT32_MAX)
 
# Layer 4 — protocol mimicry (client-side only; v1.5+)
# I1-I5 are CPS-tagged hex snapshots of permitted UDP protocol openings
# NOTE: omitting I1 drops the client into AWG 1.0 fallback mode; both endpoints
# must agree on I-packet presence or absence. Do not omit unless running AWG 1.0.
 
[Peer]
PublicKey = [server-public-key]
Endpoint = server.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Three constraints to note from the configuration. First, the header and padding values (H1–H4 and S1–S4) must match on both client and server; a mismatch on any of these parameters produces a silent connection failure. The junk packet parameters (Jc, Jmin, Jmax) and the I1–I5 protocol-mimicry packets are client-side only; the server accepts and discards whatever arrives before the handshake without requiring any corresponding configuration. Second, setting all AmneziaWG fields to zero, or removing them entirely, reverts the configuration to standard WireGuard behaviour and restores interoperability with standard WireGuard endpoints. Third, AmneziaWG 2.0 and 1.0 configurations require separate ports and separate key pairs; they cannot share a server listener.

The 1.0 to 1.5 to 2.0 evolution

Each version of AmneziaWG responds directly to a detection method its predecessor could not defeat. The three versions are not incremental improvements; they are a record of the technical escalation between DPI infrastructure and the protocol’s countermeasures.

Version 1.0 — defeating the signature (2024)

AmneziaWG 1.0 was released in 2024. It introduced the foundational obfuscation parameters: fixed per-deployment H1–H4 header replacements, S1 and S2 junk-byte padding on the Init and Response messages, and Jc/Jmin/Jmax junk packets before every handshake.

Version 1.0 defeated signature-based DPI: a rule matching WireGuard’s 0x01 type byte on a 148-byte UDP packet found nothing to match against an AmneziaWG 1.0 connection. Its limitation was static H1–H4 values. A DPI system observing enough traffic from a specific deployment could learn its custom header values and begin classifying that traffic. Transport Data packets also retained fixed overhead, as S3 and S4 did not yet exist.

Version 1.5 — defeating protocol classification

Version 1.5 added the I1–I5 signature-packet capability. Before each handshake, the client sends up to five UDP packets whose content mimics the opening of a known permitted protocol: QUIC, DNS, SIP, or another configurable alternative. H1–H4 remained fixed per-deployment in version 1.5; S3 and S4 were not yet present.

This version responded to a specific detection approach that had become operationally significant: treating all fully-encrypted, non-fingerprinted UDP traffic as suspicious regardless of its header values. This heuristic was deployed by China’s Great Firewall and adopted within Russia’s TSPU infrastructure. Giving traffic a protocol identity that a classifier recognises as permitted addresses this approach directly.

Version 2.0 — defeating statistical analysis (late 2025 / March 2026)

AmneziaWG 2.0’s protocol specification was completed in late 2025. Client rollout began on 24–25 March 2026 and requires AmneziaVPN app version 4.8.12.9 or later. At launch, version 2.0 was available for self-hosted deployments only; Amnezia Premium and Free managed tiers remained on AmneziaWG 1.5, with a 2.0 upgrade described as forthcoming.

Version 2.0 introduced three substantive changes. H1–H4 became ranged rather than fixed: each packet draws a random value from the configured range, making it significantly harder for a statistical classifier to learn a deployment’s header pattern from observed traffic. S3 and S4 extended variable-size padding to Cookie Reply and Transport Data packets, so all four message types now have unpredictable sizes. The CPS tag builder formalised the I1–I5 protocol-mimicry capability into a six-tag composition system (b, t, r, rc, rd, and c).

In AmneziaVPN 4.8.12.9 and later, version 1.0 configurations appear in the app labelled as “AmneziaWG Legacy.” Version 2.0 configurations are not backward-compatible with version 1.0: separate configuration files and private keys are required. Both versions can coexist in the app but must operate on separate ports.

The pattern behind the versions

China’s Great Firewall deployed entropy-based heuristic passive detection of fully-encrypted protocols starting in November 2021. The mechanism, documented by Wu, Sippe, Sivakumar and colleagues in a paper presented at USENIX Security 2023, works by exemption rather than flagging: the GFW applies heuristic rules to identify traffic that is unlikely to be fully encrypted (based on common protocol fingerprints, crude entropy tests, and the fraction and position of ASCII characters) and exempts that traffic; everything that does not earn an exemption is blocked. This is why I1–I5 mimicry works: traffic carrying recognisable protocol signatures earns an exemption from the block rather than evading detection of a specific VPN signature. Russia’s TSPU developed comparable capabilities over 2024 and 2025, learning to classify traffic that version 1.0 had made unrecognisable. The dynamic H1–H4 ranges and full-message-type S4 padding of version 2.0 were the direct response to that capability escalation.

Where AmneziaWG sits in the obfuscation landscape

AmneziaWG fills a gap no other mainstream obfuscation technique currently occupies.

The gap it fills

AmneziaWG’s distinctive combination: a full Layer 3 VPN tunnel, operating on native UDP, with DPI resistance applied at the protocol level, from an open self-hostable implementation where both endpoints share user-configurable parameters, with protocol mimicry (CPS) as a built-in capability. No other mainstream approach delivers all of these simultaneously.

Mullvad’s Lightweight WireGuard Obfuscation (LWO, launched November 2025) comes closest on several attributes: it is a full WireGuard tunnel on native UDP with in-place header scrambling and minimal overhead; but LWO is vendor-controlled, available only to Mullvad subscribers, not self-hostable with user-configurable parameters, and carries no protocol mimicry equivalent to CPS. The scrambling pattern is fixed across Mullvad’s infrastructure rather than parameterised per deployment.

Shadowsocks is a SOCKS5 proxy, not a full tunnel. DNS queries and non-TCP traffic can leak outside the proxy path. Applications using non-TCP protocols (gaming, VoIP, and video calling) must either go unprotected or route through a proxy with higher latency and incomplete traffic coverage. AmneziaWG routes all traffic through the tunnel.

VLESS+REALITY provides the strongest available impersonation: a TLS certificate borrowed from a real high-profile domain, with active probe responses routed through to that domain. It is proxy-based and requires complex server-side configuration. It does not provide a full Layer 3 tunnel.

Proton VPN’s Stealth wraps WireGuard inside obfuscated TLS over TCP. AmneziaWG modifies the WireGuard packets themselves, stays on UDP, and avoids the TCP conversion and TLS overhead Stealth carries. Different trade-offs, not a ranking.

AmneziaWG versus the alternatives, head to head

The clearest way to place AmneziaWG is to set it directly beside the tools it is most often confused with or compared to.

The two distinctions that drive most selection decisions: AmneziaWG, standard WireGuard, and Mullvad LWO are the only full Layer 3 tunnels on native UDP; the proxy-based options route traffic at the application layer and leave non-TCP protocols outside the tunnel. Second, only VLESS+REALITY provides genuine active probing resistance as a protocol property; AmneziaWG’s protocol core does not, though the WireSock server-side proxy adds this capability for self-hosters who need it.

Where it is weaker

AmneziaWG provides passive DPI resistance, not active probing resistance at the protocol level. The WireSock third-party proxy addresses active probing for self-hosted deployments, but as a server-side add-on rather than a protocol property.

AmneziaWG is UDP-only. On networks that block all non-TCP traffic, it will not connect. This is the same constraint as standard WireGuard, not an additional one introduced by the fork. On those networks, a TCP-based approach is required: OpenVPN TCP 443, Proton Stealth, or Shadowsocks bridges.

CPS signatures mimic specific protocol openings at the moment of session establishment. They are not dynamically sustained throughout the session. A DPI system sophisticated enough to verify that a claimed QUIC session exhibits QUIC-compliant behaviour beyond the opening handshake will find the mimicry does not hold. For threat models requiring sustained, end-to-end protocol impersonation, VLESS+REALITY remains the stronger tool.

Performance — kernel module vs userspace

AmneziaWG’s performance depends almost entirely on which implementation is running. The two available implementations produce substantially different results, and most circulating performance claims attribute figures to “AmneziaWG” without specifying which.

Two implementations, two performance profiles

The Linux kernel module (amnezia-vpn/amneziawg-linux-kernel-module, installed via DKMS) runs at near-WireGuard performance. Packet processing happens in kernel space with no change to the cryptographic path. The overhead comes only from the padding bytes (S1–S4) and junk packet operations (Jc/Jmin/Jmax). The theoretical maximum overhead from padding alone is under 12%. Informal testing by the maintainer of the amneziawg-installer project reports approximately 3% overhead in practice (around 92 Mbps versus WireGuard’s 95 Mbps on the same hardware). No rigorous independent benchmark of the kernel module has been published; these figures are from developer community testing, not controlled measurement.

The userspace Go build (amnezia-vpn/amneziawg-go) carries substantially higher overhead. The Amnezia development team attributes the widely circulated “65% overhead” figure specifically to this implementation. The amneziawg-installer documentation estimates 30–50% CPU overhead at 1 Gbps for the Go build. Both figures are developer-attributed. The Go build is what runs on macOS, Windows, iOS, and Android via AmneziaWG client applications.

What the overhead actually consists of

AmneziaWG’s overhead has two sources: S1–S4 padding adds bytes to packets, and Jc junk packets add handshake-phase traffic. Neither touches the cryptographic path. ChaCha20-Poly1305 encrypts exactly the same payload it would encrypt in standard WireGuard.

The CPS packet burst and junk packet sequence are paid before every handshake. Since WireGuard initiates a new handshake approximately every 120 seconds on an active session to rotate keys, the Jc junk packets and any I1–I5 CPS packets recur roughly every two minutes for the duration of an active connection. S4 padding on Transport Data packets (capped at 32 bytes per the protocol specification) is the steady-state per-packet overhead between handshakes.

On mobile platforms running the userspace Go build, the higher CPU utilisation compared to standard WireGuard’s kernel module will affect battery life. The correct comparison is between AmneziaWG’s Go build and other userspace Go VPN implementations, not between AmneziaWG and WireGuard’s kernel module. On that basis, the Go build remains more CPU-efficient than OpenVPN for comparable traffic volumes.

Deployment constraints

The kernel module requires Linux and either KVM virtualisation or bare-metal hardware. LXC containers are not supported: the DKMS build fails because LXC shares the host kernel and cannot load custom kernel modules from inside the container. The userspace Go build can run in an LXC container with /dev/net/tun device access and CAP_NET_ADMIN capability.

Interoperability, limitations, and operational considerations

AmneziaWG’s fork architecture creates one unavoidable trade-off and several operational considerations.

The interoperability constraint

With active obfuscation parameters, AmneziaWG is not compatible with standard WireGuard endpoints. A standard WireGuard client sends type byte 0x01 in its Handshake Initiation. An AmneziaWG server configured with a non-zero H1 range does not recognise this value and silently discards the packet. From the client’s perspective, the server simply does not respond.

Active AmneziaWG deployments require AmneziaWG-specific clients. These are available on Windows (GitHub download), macOS (awg-apple), Linux (amneziawg-tools), Android (Google Play), and iOS (App Store).

The backward-compatibility path: all parameters set to zero produces standard WireGuard behaviour, full interoperability with standard WireGuard clients and servers, and no obfuscation overhead.

Version compatibility

AmneziaWG 2.0 is not backward-compatible with version 1.0. The ranged H1–H4 headers and S3/S4 padding fields introduced in 2.0 are not understood by version 1.0 clients. Separate configuration files and private keys are required for each version. In AmneziaVPN 4.8.12.9 and later, version 1.0 configurations are labelled “AmneziaWG Legacy”; version 2.0 is the primary implementation. Both can coexist in the app but must operate on separate ports.

Firewalla’s AmneziaWG VPN Server (beta, firmware 1.982 and later) supports the version 1.0 parameter set: H1–H4, S1/S2, and Jc/Jmin/Jmax (no I1–I5 or CPS). wg-easy also omits I1–I5. Deployments requiring full version 2.0 CPS functionality need a fully updated AmneziaWG stack on both ends.

MTU and the “handshake succeeds but no traffic flows” problem

The most commonly encountered AmneziaWG deployment problem is a handshake that completes successfully followed by no application traffic. This is the standard WireGuard tunnel-MTU versus path-MTU mismatch, documented across multiple official GitHub issues (amnezia-client #1823, #1041, and #2048; amneziawg-go #145). AmneziaWG’s per-packet S4 overhead (at most 32 bytes per Transport Data packet) can aggravate this mismatch at the margin, but S1–S4 padding values are too small to be the primary driver.

The official AmneziaWG interface default MTU is 1420, identical to standard WireGuard. Third-party installer tools and several hosting guides recommend setting the interface MTU to 1280 as a troubleshooting floor. The rationale for 1280 is that it is the minimum MTU required for IPv6 compatibility, and it accommodates cellular networks, particularly iOS, where the effective path MTU is frequently below 1420 and where Path MTU Discovery is strictly enforced. This is a community-recommended value from installer tooling practice, not an official Amnezia default, and it does not resolve every instance of the problem.

A related issue applies to Jmax: junk packets that exceed the system MTU are fragmented across multiple IP packets before the handshake begins. Fragmented UDP in that position is an unusual observable pattern. The official amneziawg-go documentation explicitly flags this: set Jmax below the system MTU.

CPS signature maintenance

CPS signatures mimic specific protocol openings at the moment of session establishment. They are not dynamically updated. A DPI system that observes a consistent CPS configuration across enough traffic from the same deployment can eventually learn to classify that configuration. For long-term deployments in high-adversarial environments such as Russia and China, periodic review and refresh of CPS template configuration is an operational maintenance task rather than a one-time setup decision.

What AmneziaWG cannot do

AmneziaWG’s server ignores CPS and junk packets and waits for a valid WireGuard handshake; it does not respond to active probes as a QUIC endpoint or DNS resolver would. For threat models where an adversary actively tests suspected VPN endpoints (a technique documented in operation against Shadowsocks and Tor bridges), VLESS+REALITY’s approach of proxying probe traffic through a real domain is the appropriate tool.

AmneziaWG is UDP-only and will not connect on networks that block all non-TCP traffic. On those networks, OpenVPN TCP 443, Proton Stealth, or Shadowsocks bridges are required. 

AmneziaWG inherits WireGuard’s static peer table architecture. A self-hosted AmneziaWG server maintains a mapping of peer public keys to internal IP addresses that persists across sessions.

Who uses AmneziaWG — the current ecosystem

AmneziaWG is available through three consumer-facing providers and can be self-hosted on Linux. The largest commercial VPN providers have not adopted it as of mid-2026.

AmneziaVPN

AmneziaVPN is the project’s own client. It supports two deployment models. For self-hosted users who supply their own VPS, the client connects to the server over SSH, installs Docker automatically, and starts one container per protocol. The AmneziaWG server runs in a dedicated container (amnezia-awg). Docker is the required deployment mechanism for self-hosted use through the AmneziaVPN app, not one option among several.

Managed tiers are Amnezia Free, targeting users in censorship-affected regions, and Amnezia Premium at $4 per month as of mid-2026. Amnezia Free reported 2.5 million monthly active users by 2026, a vendor-reported figure relayed via CNET in March 2026. Managed tiers (Amnezia Free and Premium) were running AmneziaWG 1.5 at the time of the March 2026 self-hosted launch, confirmed by Tom’s Guide’s coverage of the announcement. Amnezia stated a 2.0 upgrade was forthcoming but had not shipped it as of mid-2026.

AmneziaVPN client apps are available on Windows, macOS, Linux, Android, and iOS.

NymVPN

NymVPN adopted AmneziaWG as its default Fast Mode protocol in early 2025, with a detailed technical blog post explaining the integration published shortly after launch.

NymVPN’s implementation is client-side only: junk packets are sent and headers are obfuscated by the client, but the server does not run AmneziaWG and does not remap headers. In a full bilateral deployment, both endpoints run matching AmneziaWG parameters.

NymVPN added the Lewes Protocol for post-quantum key exchange on Fast Mode connections. After an opt-in phase in April and May 2026, the Lewes Protocol became the default for all Fast Mode connections in NymVPN v2026.9, approximately 2 June 2026. NymVPN describes the Lewes Protocol as a novel protocol; its specific cryptographic mechanism has not been publicly documented by NymVPN. For the fundamentals of post-quantum VPN key exchange, including the hybrid model and the harvest-now-decrypt-later threat, see Post-Quantum VPN Encryption Explained.

Windscribe

Windscribe integrated AmneziaWG natively starting with a mobile beta launched on 24–26 February 2026, followed by desktop integration in March 2026. AmneziaWG is built directly into the Windscribe app on Windows and macOS (v2.21.3 and later), Android (v3.98.2061 and later), and iOS (v3.9.13 and later). No external client or separate configuration file is required.

Windscribe’s own documentation confirms AWG 1.5 support: “AmneziaWG 1.5 features are also supported.”

Self-hosted and community ecosystem

amneziawg-installer is a third-party installer script maintained by bivlked on GitHub that simplifies kernel module installation and parameter configuration on Linux VPS deployments. It sets the interface MTU to 1280 by default, including an MSS clamp derived from that value, to address the tunnel-MTU versus path-MTU mismatch common on cellular networks.

Firewalla supports AmneziaWG as a VPN Server option in beta (firmware 1.982 and later, app 1.68 and later). Server parameters are limited to the version 1.0 set: H1–H4, S1/S2, and Jc/Jmin/Jmax (no I1–I5). VPN Client support (the Firewalla box connecting outbound to an external AmneziaWG server) is planned for a future firmware update. WireGuard and AmneziaWG VPN Server clients share the same total client limit.

Keenetic routers support AmneziaWG in client mode: the router imports an AmneziaWG configuration file and connects to an external AmneziaWG server. This capability is available now. Version support splits by firmware channel. AmneziaWG 1.0 configuration files work on KeeneticOS 4.2 Alpha 2 and above, which is available on the stable firmware channel. AmneziaWG 1.5 and 2.0 configuration files require KeeneticOS 5.1 Alpha 3 or later, available only on the developer (beta) firmware channel. (Third-party userspace workarounds exist for KeeneticOS 5.0.8 and below for users who cannot access the developer channel.) Loading a version 1.5 or 2.0 configuration file on KeeneticOS 5.0.8 or below produces an invalid H1 value error.

wg-easy, the browser-based WireGuard management interface, supports AmneziaWG via the EXPERIMENTAL_AWG=true environment variable, with this becoming the default from version 16. I1–I5 and CPS parameters are not yet configurable through wg-easy.

WireSock proxy (wiresock/amneziawg-install, maintained by Vadim Smirnov) is a third-party Rust-based UDP obfuscation proxy that runs as a server-side layer above AmneziaWG. It is not part of the official AmneziaWG protocol and does not appear in the official amnezia-vpn GitHub organisation. It provides active probing resistance: when a censorship system sends a QUIC Initial, DNS query, STUN Binding Request, or SIP request to the endpoint, the proxy replies with a valid protocol response, so the port behaves like the service the CPS packets impersonate when actively probed. Windscribe publicly credited Smirnov for assistance with their AmneziaWG server-side implementation.

Major commercial providers

NordVPN, ExpressVPN, Proton VPN, Mullvad, and Surfshark have not adopted AmneziaWG as of mid-2026. Each uses its own obfuscation approach: NordVPN uses XOR-scrambled OpenVPN for its obfuscated servers; Proton VPN uses Stealth; Mullvad uses a four-mode WireGuard obfuscation stack; ExpressVPN uses proprietary obfuscation on Lightway; Surfshark uses Camouflage Mode on OpenVPN. 

AmneziaWG in censorship environments

AmneziaWG was designed for one adversary, Russia’s TSPU, and its effectiveness in other environments is best understood by how closely each environment resembles the one it was built for.

Russia

Russia is AmneziaWG’s home environment by design. The TSPU’s decentralised ISP-level deployment and its progressive capability escalation drove each version of the protocol. An active Russian-speaking developer community maintains and deploys the tool; Roskomsvoboda remains associated with the project.

The TSPU’s capability as of October 2024 encompasses WireGuard, OpenVPN, IKEv2, IPsec, L2TP, and PPTP. AmneziaWG 2.0’s dynamic H1–H4 ranges and full-message-type S4 padding were the direct response to the statistical classification methods TSPU had developed to identify version 1.0 and 1.5 traffic on Russian networks.

Evidence for effectiveness: vendor documentation (Windscribe lists Russia as a primary strong-performance environment), the direct lineage between TSPU capability escalation and each protocol version release, and community deployment reports from Russian users. DPI capabilities continue to evolve; no configuration should be treated as permanently effective without ongoing verification.

China

AmneziaWG is reported effective against China’s Great Firewall, with a weaker evidence base than for Russia. The available evidence consists of vendor documentation (Windscribe lists China alongside Russia and Iran), protocol design rationale (the I1–I5/CPS system directly targets the entropy-based heuristic detection the GFW deployed in November 2021), and user anecdotes. No rigorous independent field testing of AmneziaWG specifically in China has been published.

The GFW is more sophisticated and faster-adapting than Russia’s TSPU. The GFW’s entropy-based detection heuristic documented by Wu et al. (USENIX Security 2023) initially focused on TCP traffic. Since then, a USENIX Security 2025 paper (Zohaib, Sippe, Alaraj, Houmansadr, Durumeric, and Wustrow) documented that the GFW began blocking QUIC connections to specific domains from April 7, 2024, decrypting QUIC Initial packets at scale and applying SNI-based heuristic filtering against a domain blocklist. This finding directly bears on AmneziaWG’s CPS mechanism: the default I1 signature mimics a QUIC Initial, which means the GFW can inspect the SNI field inside it. This is the mechanism behind the community workaround for hosting-provider IP filtering: embedding a CPS I1 packet with a permitted SNI value allows the traffic to pass the SNI-matching check. The technique is operator-specific, requires testing, and does not help against true IP-range blocking where packets are dropped without protocol inspection.

Windscribe’s own guidance notes that port selection matters in practice: switching AmneziaWG from port 443 to port 80 is sometimes necessary in China and Iran. No configuration should be relied upon for the first time after arrival; verify before departure.

Iran

Iran’s censorship infrastructure relied primarily on SNI inspection and IP blacklisting before 2026. After January 2026 protests, Amnezia’s own reporting notes that Iranian censors, with assistance from Russian counterparts, introduced partial traffic analysis methods, automating DPI-based blocking that was previously manual. AmneziaWG remains effective against the signature-based filtering still in use; Windscribe confirms Iran as a strong-performance environment.

2026 brought two distinct nationwide internet disruptions. On 8 January 2026, amid escalating protests over currency collapse and inflation, Iran imposed a near-total nationwide blackout, with connectivity at approximately 2–3% of normal. That first shutdown was relaxed around 28 January (roughly 20 days). On 28 February 2026, following Israeli–US strikes, a second near-total blackout followed, with NetBlocks measuring connectivity falling to approximately 1% of ordinary levels through March. This second shutdown ran for 88 consecutive days before President Pezeshkian ordered restoration on 25 May 2026, with services beginning to return on 26 May 2026, making it the longest documented nationwide internet disruption in any country on record. Post-restoration traffic measurement showed 86% of pre-cutoff capacity (NetBlocks) or approximately 53% of pre-January-2026 levels (Kentik); Iranian internet researchers described VPNs as no longer effective or affordable for many users during and after the outage. Heavy filtering, including restrictions on WhatsApp, remained in place after restoration.

These events are the clearest real-world demonstration that obfuscation tools of any kind provide no utility when the link itself is severed at the infrastructure level. AmneziaWG, Shadowsocks, and VLESS+REALITY all become irrelevant when there is no connection to obfuscate.

Myanmar and other environments

Amnezia identifies Myanmar as a primary deployment environment. An Amnezia spokesperson confirmed to TechRadar that Amnezia Free operates primarily in countries including Russia, Myanmar, and Iran. A Medianama interview with Amnezia’s founder addressed Myanmar directly following the 2021 coup, noting that ISPs had blocked Facebook, WhatsApp, and Wikipedia, and that Amnezia VPN could restore access. Amnezia deploys both AmneziaWG and its XRay VLESS protocol in Myanmar, suggesting the blocking infrastructure there combines DPI-based and IP-based techniques rather than relying solely on protocol fingerprinting.

If OpenVPN TCP 443 fails and UDP is not blocked entirely, AmneziaWG is the appropriate next step for DPI-filtered networks. If UDP is also blocked, a TCP-based approach is required.

Should you use AmneziaWG?

AmneziaWG solves one problem: WireGuard traffic that is being identified and suppressed by DPI. Whether that problem describes your situation determines whether it belongs in your setup.

When it is the right tool

Your WireGuard connection is being suppressed by DPI, not by port filtering. Port filtering (a network that blocks UDP traffic or non-standard ports) is resolved by OpenVPN TCP 443 without requiring AmneziaWG. DPI-based protocol identification of WireGuard traffic, the situation in Russia and in environments running active protocol-classification DPI, is what AmneziaWG addresses.

You need a full VPN tunnel rather than a proxy. Gaming, VoIP, and applications that use non-TCP protocols require either a full tunnel or a direct connection. Proxy-based solutions such as Shadowsocks and VLESS+REALITY do not route all traffic. AmneziaWG provides the full tunnel model with DPI resistance as a protocol property.

You are self-hosting on Linux with KVM or bare-metal hardware available. The approximately 3% overhead of the kernel module makes AmneziaWG’s performance effectively equivalent to standard WireGuard in practice.

You are on a provider (NymVPN, Windscribe, or AmneziaVPN) that has integrated AmneziaWG and you want to understand the protocol and its limitations.

When it is not the right tool

Your VPN connects and works without interference. Obfuscation adds overhead (padding bytes, junk packets, and the CPS exchange at session establishment) for no benefit on networks that do not filter VPN traffic by protocol. Standard WireGuard is simpler, fully interoperable, and marginally faster.

Your network blocks all UDP traffic. AmneziaWG will not connect. OpenVPN TCP 443, Proton Stealth, or Shadowsocks bridges are required instead.

Active probing resistance is your primary requirement. VLESS+REALITY is the stronger tool for that threat model. The WireSock proxy provides active probing resistance above AmneziaWG for self-hosters willing to operate an additional server-side component.

You cannot control both endpoints. AmneziaWG requires matching parameters on both the server and client. If you are connecting to infrastructure you do not control that runs standard WireGuard, AmneziaWG with active obfuscation parameters will not connect to it.

Your deployment environment is an LXC container and you need kernel-module performance. Use a full VM or bare metal for the kernel module. The userspace Go build is the alternative for LXC deployments.

Is it legal to use AmneziaWG?

AmneziaWG’s technical effectiveness in a censorship environment is a separate question from whether using it there is lawful. What follows is informational and does not constitute legal advice; local law changes and enforcement patterns shift, and anyone with specific legal exposure should consult a qualified local practitioner.

The relevant legal distinction in most jurisdictions is between using a circumvention tool as an individual and operating or distributing circumvention infrastructure.

In Russia, Federal Law 276-FZ (2017) requires VPN providers to register in the FGIS system and connect to Roskomnadzor’s register of prohibited resources; non-compliant providers are blocked. That framework targeted providers, not users. The position shifted on 1 September 2025, when amendments introduced administrative fines of 3,000–5,000 rubles under Article 13.53 for deliberately accessing materials on Russia’s federal extremist list online, including via VPN, and designated VPN use as an aggravating circumstance for other offences. The first known administrative case under the amended statute (Sergey Glukhikh, Kamensk-Uralsky) was filed in October 2025, reported in November, and returned to police to correct procedural mistakes; as of early 2026 the law had not been widely applied.

Individual VPN use itself remains lawful in Russia; accessing designated extremist material via VPN does not. Separately, from April 2026 major Russian platforms including Ozon and Kinopoisk began blocking visitors connecting via VPN, in compliance with a Digital Development Ministry deadline; the practical constraint for many users is now application-layer blocking rather than legal penalty. On the app-store side, Apple removed approximately 25 VPN apps from the Russian App Store at Roskomnadzor’s request in July 2024 (including Le VPN, Red Shield VPN, AdGuard VPN, and HideMyName), and over 2024 as a whole removed at least 60 VPN apps affecting major providers including NordVPN, ExpressVPN, and Proton VPN. In early 2026 Apple removed a further set of proxy and custom-VPN clients (Streisand, V2Box, v2RayTun, and others). Google Play has largely not complied with removal demands. 

In China, individual use of an unauthorised cross-border internet channel is expressly prohibited under State Council Decree 195, Article 6, and carries a fine of up to RMB 15,000 under Article 14. The law is unambiguous; enforcement against individuals is sporadic but documented, with fines ranging from a few hundred yuan to the statutory ceiling. The legally permitted path is through state-licensed international gateways available to enterprises via the three licensed carriers. A separate but distinct pattern is that DPI-based VPN blocking intensifies sharply around major political events such as the annual Two Sessions and National Party Congresses; this is a technical blocking phenomenon, not a concentration of administrative punishment against individuals. The 2026 Cybersecurity Law amendment (effective 1 January 2026) targets network operators and platforms, not individual VPN use. A draft cybercrime law published in January 2026 would extend prohibitions to circumvention tools, but as of mid-2026 it remains at the ministerial drafting stage and has not entered the NPC legislative process.

In Iran, VPN use is prohibited by a Supreme Council of Cyberspace resolution approved by the SCC on 14 November 2023, endorsed on 9 January 2024, and announced into effect on 19–20 February 2024. The resolution prohibits unlicensed VPN use; a theoretical licensing path exists for state-approved access, though in practice no such licences are issued to ordinary individuals. Iranian legal specialists note that the Supreme Council of Cyberspace is a policy-making body without legislative authority, and dispute whether the resolution constitutes criminal law under the principle of legality of crimes and punishments. Sale and distribution of VPN tools were separately criminalised earlier. Enforcement against individual users is variable. That 88-day blackout made the legal question largely moot: the binding constraint for Iranian users in 2026 was infrastructure, not law.

In Myanmar, the Cybersecurity Law (enacted 1 January 2025, in effect 30 July 2025) criminalises operating or providing VPN services without ministry approval; individuals face one to six months’ imprisonment and fines up to MMK 10 million. Individual use of VPN services is not directly addressed by the statute. In practice, security forces conduct phone checks at checkpoints and arrest people under counter-terrorism legislation when VPN apps are found on devices, with documented demands of MMK 300,000 to 3 million from those found with VPN software. The post-coup blocks on Facebook, WhatsApp, and Wikipedia are confirmed and remain in effect. A DPI-based nationwide VPN block was implemented in May 2024.

Using AmneziaWG does not create legal exposure unique to the tool itself beyond the exposure that applies to VPN and circumvention tool use generally in each jurisdiction.

Choosing the right version

For new self-hosted deployments, AmneziaWG 2.0 is the current version and the correct starting point. The only reason to deploy 1.0 parameters rather than 2.0 is a dependency that lacks 2.0 support: Firewalla’s server-side support covers the 1.0 parameter set only (no I1–I5), and wg-easy does not yet auto-populate I1–I5.

For existing version 1.0 deployments, migrating to 2.0 requires generating new configuration files and private keys. This is not a configuration upgrade; the two versions are incompatible and must run on separate ports. Test the new configuration before cutting over from a working 1.0 deployment.

Frequently asked questions

What is AmneziaWG?

AmneziaWG is a fork of WireGuard-Go that modifies the protocol’s transport layer to defeat deep packet inspection while leaving the cryptographic core unchanged. It replaces WireGuard’s fixed message-type headers with configurable, per-packet randomised values; adds variable-size padding to every packet type via S1–S4 parameters; sends Jc junk packets before each handshake to blur session timing; and can disguise session openings to resemble legitimate UDP protocols such as QUIC or DNS via I1–I5 signature packets and the CPS tag builder. Its cryptographic primitives (Curve25519, ChaCha20-Poly1305, BLAKE2s, and the Noise_IK handshake) are identical to standard WireGuard.

Is AmneziaWG the same as WireGuard?

No. AmneziaWG is a fork of WireGuard-Go that modifies the packet structure at the transport layer. The cryptographic operations, key exchange, and session model are identical to standard WireGuard. With all obfuscation parameters set to zero, AmneziaWG is fully interoperable with standard WireGuard. With active obfuscation parameters, it is not: both sides of a connection must run AmneziaWG with matching parameters, and standard WireGuard clients cannot connect to an AmneziaWG server running non-zero H1–H4 values.

Is AmneziaWG secure?

The cryptographic layer is identical to standard WireGuard, so all existing security analyses of WireGuard’s cryptographic core apply to AmneziaWG’s cryptographic layer. The obfuscation layer has been assessed through penetration testing by 7ASecurity (two engagements: July 2024 and December 2024 to January 2025) but has not been formally verified through symbolic or computational proof.

What is the difference between AmneziaWG 1.0 and 2.0?

Version 1.0 (2024) introduced fixed per-deployment H1–H4 header replacements, S1/S2 junk-byte padding on the Handshake Init and Response messages, and Jc/Jmin/Jmax junk packets before each handshake. Version 1.5 added I1–I5 signature packets that mimic the opening of legitimate UDP protocols before each handshake. Version 2.0 (spec: late 2025; client rollout: March 2026) extended H1–H4 to dynamic per-packet ranges drawn from configured intervals, added S3/S4 padding to the Cookie Reply and Transport Data packets, and formalised the protocol-mimicry capability into the CPS tag builder system. AmneziaWG 2.0 configurations are not backward-compatible with version 1.0; separate configuration files and private keys are required for each.

Is AmneziaWG slower than WireGuard?

It depends on which implementation is running. The Linux kernel module runs at near-WireGuard performance; informal developer testing places overhead at approximately 3%, with the theoretical maximum from padding alone under 12%. The userspace Go build, which is what runs on macOS, Windows, iOS, and Android, carries substantially higher overhead. The Amnezia development team attributed a 65% throughput overhead figure to the Go implementation; the amneziawg-installer documentation estimates 30–50% CPU overhead at 1 Gbps. These measure different things (throughput vs CPU) and should not be collapsed into a single range. The overhead in both cases comes from padding bytes and junk packets, not from any change to the cryptographic path. ChaCha20-Poly1305 encrypts the same payload it would encrypt in standard WireGuard.

Can I use a standard WireGuard client with AmneziaWG?

Only if all obfuscation parameters are set to zero. In that case AmneziaWG behaves identically to standard WireGuard and is fully interoperable. With active obfuscation parameters, a standard WireGuard client cannot connect: the 0x01 type byte it sends in its Handshake Initiation will not fall within the server’s configured H1 range, and the server will silently discard the packet. Active AmneziaWG deployments require AmneziaWG-specific client apps, available on Windows, macOS, Linux, Android, and iOS.

Does AmneziaWG work in China?

It is reported to work, with significant caveats. Vendor documentation (Windscribe) lists China as a strong-performance environment. The protocol’s I1–I5/CPS mimicry directly targets the entropy-based heuristic detection the GFW deployed in November 2021. No rigorous independent field testing of AmneziaWG in China has been published. The GFW is more sophisticated and faster-adapting than Russia’s TSPU; port selection (port 80 rather than 443) is sometimes necessary. Test before arrival. No AmneziaWG configuration should be relied upon without pre-departure verification against current GFW conditions.

Does AmneziaWG work in Russia?

Yes, with the caveat that DPI capabilities continue to evolve. AmneziaWG was created to counter Russia’s TSPU system. Each protocol version responds directly to a TSPU capability escalation: version 1.0 defeated signature-based DPI; version 1.5 defeated protocol-classification heuristics; version 2.0 addressed statistical classifiers that had learned to identify 1.0 and 1.5 traffic. Community deployment reports support effectiveness, and the tool has significant active use among Russian internet users.

Does AmneziaWG have post-quantum encryption?

Not by default in the protocol itself. AmneziaWG inherits WireGuard’s optional pre-shared key slot, which can accommodate a post-quantum key exchange layer, but this is not built into or enabled by default in AmneziaWG’s specification. NymVPN, which uses AmneziaWG as its default Fast Mode protocol, added the Lewes Protocol for post-quantum key exchange on Fast Mode connections; this became the default in NymVPN v2026.9 (approximately June 2026). NymVPN describes the Lewes Protocol as a novel protocol; its specific cryptographic mechanism has not been publicly documented. 

What is CPS (Custom Protocol Signature)?

CPS is a structured tag builder introduced in AmneziaWG 2.0 that constructs protocol-mimicry packets from six composable components, allowing the opening of a VPN session to resemble QUIC, DNS, SIP, or other permitted UDP protocols. Up to five such packets (I1–I5) are sent before each handshake. The I1–I5 capability dates from version 1.5; the CPS tag builder that structures it was introduced in version 2.0.

Can I self-host AmneziaWG?

Yes. AmneziaWG can be self-hosted on any Linux server. The AmneziaVPN client app automates the process: it connects to your VPS over SSH, installs Docker, and starts an AmneziaWG server container (amnezia-awg). The amneziawg-installer script (third-party, bivlked on GitHub) provides an alternative kernel-module installation path without Docker. The kernel module requires KVM virtualisation or bare-metal hardware; LXC containers are not supported for the DKMS build. The userspace Go build can run in LXC with /dev/net/tun access and CAP_NET_ADMIN capability.

Which VPN providers use AmneziaWG?

As of mid-2026: AmneziaVPN (the project’s own client, self-hosted and managed tiers), NymVPN (default Fast Mode protocol since early 2025), and Windscribe (native integration since February–March 2026). Firewalla supports AmneziaWG as a beta VPN Server option on firmware 1.982 and later, with the version 1.0 parameter set only (H1–H4, S1/S2, Jc/Jmin/Jmax; no I1–I5). NordVPN, ExpressVPN, Proton VPN, Mullvad, and Surfshark have not integrated AmneziaWG as of mid-2026.

Is it legal to use AmneziaWG in Russia, China, or Iran?

In Russia, individual VPN use itself remains lawful; since September 2025, Article 13.53 introduced fines of 3,000–5,000 rubles for accessing materials on Russia’s federal extremist list via VPN; Russian authorities clarified this does not penalise ordinary social media access via VPN. In China, individual use of an unauthorised cross-border internet channel is expressly prohibited under State Council Decree 195 (fine up to RMB 15,000), though enforcement against individuals is sporadic rather than systematic. In Iran, VPN use is prohibited by a Supreme Council of Cyberspace resolution (February 2024); Iranian legal specialists dispute whether this constitutes criminal law under the principle of legality. In Myanmar, the 2025 Cybersecurity Law criminalises VPN provision, not individual use; users face checkpoint enforcement under counter-terrorism legislation in practice. In none of these jurisdictions does AmneziaWG create exposure unique to the tool itself.

How do I set up AmneziaWG?

The parameters (H1–H4, S1–S4, Jc/Jmin/Jmax, and I1–I5) are explained in the mechanism sections; the annotated configuration shows them assembled into a working file. For the self-hosted setup process, two paths exist: the AmneziaVPN client app, which connects to your VPS over SSH and deploys the server automatically via Docker, and the amneziawg-installer script (third-party, bivlked on GitHub), which installs the kernel module directly without Docker. For managed deployment without running your own server, AmneziaVPN, NymVPN, and Windscribe all have AmneziaWG built into their client apps with no manual parameter configuration required.