DEV Community: Ivan Bondarev

How to install AmneziaWG 3.1 on your own VPS (Ubuntu and Debian)

Ivan Bondarev — Thu, 22 Oct 2026 21:24:42 +0000

Here's how I set up an AmneziaWG 3.1 server on a plain Ubuntu or Debian VPS: one bash script, the kernel module, no Docker and no web panel. It takes 15 to 25 minutes, mostly apt and building the kernel module.

AmneziaWG is the WireGuard fork built to get past DPI, and 3.1 is its newest generation. The official way to get a 3.1 server is the Amnezia VPN app, which logs into your server over SSH and runs AmneziaWG there in Docker. I wrote and maintain amneziawg-installer, the script I use below. Since v6.0.0 a fresh install sets up 3.1 by default.

What 3.1 changes

The big one is header encryption. Every install gets its own HeaderProtectionKey, so the header no longer tells an observer what kind of packet it's looking at. Data packets also get extra padding (ContentPaddingAddition). The obfuscation you may know from 2.0 is still there: junk packets (Jc), random padding on protocol messages (S1-S4) and the I1 packet sent before the handshake.

The Amnezia team now tells people to move even if 2.0 still works for them, because "AmneziaWG 2.0, like AmneziaWG 1.5, has become vulnerable to blocking" (Amnezia docs).

One thing before you start. If your carrier blocks the server's IP, or the whole hosting provider, a new protocol generation won't help. 3.1 changes how the packets look, but they still go to the same address.

What you need

A full virtual machine (KVM or similar) on x86_64. Containers (OpenVZ, LXC, Docker) can't load a kernel module, and the installer stops there.
Ubuntu 24.04 LTS, Ubuntu 26.04 LTS or Debian 13. 3.1 needs kernel 6.7 or newer, and all three have it.
At least 512 MB of RAM and 2 GB of disk. 1 GB of RAM is comfortable, and one vCPU is plenty for a personal VPN.
Root over SSH, ideally on a clean minimal install. The script assumes the server does nothing else: it tunes the kernel and network for a VPN and offers to remove packages like snapd.
An emergency console in your provider's panel. Make sure it works before you start. If SSH ever stops answering, that's how you get back in.

Since v6.2.0 ARM64 gets 3.1 too: Hetzner CAX, Oracle Ampere, AWS Graviton, a Raspberry Pi on a 64-bit system. For the Pi I checked that the module builds against the Raspberry Pi OS kernels, but I have not run it on a Pi itself yet. 32-bit ARM stays on AmneziaWG 2.0, and so does a stock Debian 12: its kernel is 6.1, older than 6.7. Either way, the final report tells you why.

If you plan to route traffic from Russian mobile networks, avoid Hetzner. Russian carriers block its subnets widely.

Install

wget -O install_amneziawg_en.sh https://github.com/bivlked/amneziawg-installer/releases/latest/download/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh

If SSH listens on a non-standard port, add --ssh-port=YOUR_PORT so the firewall doesn't lock you out.

The first run asks for the VPN port, the tunnel subnet, IPv6, the routing mode, client isolation and the server name shown in the Amnezia app. Enter takes the value in brackets, and the defaults are fine for most people. It also lists the packages it wants to remove and asks before touching them. Answer n if you want to keep them.

Two prompts trip people up:

"Reboot now? [y/N]". Answer y. Enter means no, and then you have to reboot by hand. Your SSH session drops. Wait a minute or two, log in again and run the same command with the same flags. The script remembers where it stopped.
"Enable UFW? [y/N]" on the third run. Answer y here too. Enter leaves the server without a firewall.

So a normal install has two reboots: one after system prep, one after the kernel module is built. After the second one the script sets up the firewall, starts the service and creates two clients, my_phone and my_laptop.

If you don't want to answer anything, add --yes. It takes the defaults, removes the packages, enables the firewall and reboots on its own. You still have to log in after each reboot and run the same command again.

Connect your devices

Each client gets four files in /root/awg/:

name.conf, the text config for AmneziaWG apps, Linux awg-quick and routers
name.png, a QR code of that same config
name.vpnuri and name.vpnuri.png, a vpn:// link for the Amnezia VPN app

The two QR codes look the same, and it's easy to scan the wrong one. The Amnezia VPN app wants name.vpnuri.png. The AmneziaWG apps want name.png.

Copy them to your computer. Run this on your own machine, not in the SSH session:

scp root@SERVER_IP:/root/awg/my_phone.png .
scp root@SERVER_IP:/root/awg/my_laptop.conf .

If SSH is on another port, scp wants it as -P (capital P): scp -P YOUR_PORT root@SERVER_IP:/root/awg/my_phone.png .

Which app to use:

Android: WG Tunnel or AmneziaWG, scan my_phone.png off your screen
iPhone, iPad and Mac: AmneziaWG
Windows: AmneziaWG, import the .conf
Linux: awg-quick with the .conf, or the nm-amneziawg plugin for NetworkManager
Any platform: Amnezia VPN, scan name.vpnuri.png

Whatever you pick, it has to be a version that understands 3.1. An older app may fail to connect, sometimes without showing any error. I keep a table of clients with the versions that work and recheck it when something changes.

On 13 October I connected to a fresh 3.1 server from Android (AmneziaWG and WG Tunnel) and from Windows. When the phone switched from Wi-Fi to mobile data, both Android apps reconnected in under a second. I didn't test iPhone or Mac that day.

To add a client later:

sudo bash /root/awg/manage_amneziawg.sh add my_tablet

Check that it works

Connect a device, then run this on the server:

sudo awg show awg0

You want a latest handshake from the last two or three minutes. On the device, any "what is my IP" site should show the server's address (with the default routing mode, which sends all traffic through the tunnel).

To see the server's health and which generation it runs:

sudo bash /root/awg/manage_amneziawg.sh check

Look for the line "Installation protocol generation".

When to stay on 2.0

A client without 3.1 support can't connect to a 3.1 server. If any of your devices is a router on stock firmware (stable KeeneticOS, GL.iNet, OpenWrt with an older amneziawg package), uses Hiddify or runs an app that hasn't been updated, install the server on 2.0 from the start:

sudo bash ./install_amneziawg_en.sh --protocol=2.0

Better to decide before you install: switching generations later means a reinstall and a new profile for every client.

Optional: your own I1 packet

I1 is a packet the client sends before the handshake, so the start of the connection looks like some other protocol. By default my installer puts a packet shaped like a DNS response there. Since v6.1.0 you can set your own at install time:

sudo bash ./install_amneziawg_en.sh --i1='<your I1 string>'

A popular choice is a QUIC-shaped packet from Mini QUIC Generator: enter an SNI and copy the "AmneziaWG 1.5+ (I1 = )" field. I tried it with several SNIs, and the strings it gave me (53 to 99 bytes) passed the installer's check as is.

That check runs before anything gets installed. It only allows the tags that both the kernel module and amneziawg-go understand: <b 0xHEX>, <r N>, <rc N>, <rd N> and <t>, written back to back, with the whole packet at most 1024 bytes. It refuses <c>, because amneziawg-go, which the Android, iPhone, Mac and Windows apps run on, won't load a profile with it.

The installer remembers your value, so a later reinstall keeps it. --no-cps, --preset, --mobile, --jc, --jmin and --jmax drop it, with a warning.

On a server that's already running, use --force --i1='...'. That's a full reinstall pass with the same two reboots, so expect a few minutes of downtime. Keys, clients and the other parameters stay as they were, only I1 changes. When it's done, reissue the client profiles with sudo bash /root/awg/manage_amneziawg.sh regen and import them on your devices again. The client is the one sending I1, so the new value only kicks in once it's in their profiles.

Questions I get often

Can I upgrade my 2.0 server to 3.1 in place? No. Updating the scripts keeps the generation. To move over, you run --uninstall and then a fresh install, and every client needs a new profile. Before that, run sudo bash /root/awg/manage_amneziawg.sh backup and copy the archive to your own machine, because --uninstall deletes /root/awg/ along with the backups folder inside it. That backup is also your way back to 2.0 if you need it.

Why does the profile leave out RandomTrailers and DisableCookies? RandomTrailers has to be on at both ends, so a server with it cuts off every client that doesn't have it. In my tests it also cut throughput 85 to 133 times when combined with the rest of the obfuscation. DisableCookies removes the protection against handshake floods. 3.1 works fine without either, so the installer doesn't write these lines at all.

Will it get through my ISP? I can't promise that. It depends on the network and on the parameters. If the handshake shows up but traffic dies after a few kilobytes, read the section on AS-level blocking before you reinstall anything.

The full guide, with every flag, updates and uninstall, is INSTALL_VPS. If something here doesn't match what you see on your server, open an issue in the repository.

amneziawg-installer v5.34.0: full tunnel by default, and a signing key you can check outside GitHub

Ivan Bondarev — Sun, 13 Sep 2026 19:01:46 +0000

Two things in this post. The first is the public key that signs my installer releases, published here on purpose, away from the GitHub repository. The second is v5.34.0, which changes what a fresh install hands to clients by default.

Why the signing key is on dev.to

Since v5.29.0 every release of amneziawg-installer ships detached minisign signatures for the six scripts, plus KEYS.txt with the public key. The private key stays offline on my machine and never reaches GitHub Actions; the release workflow only verifies, and it refuses to publish a release whose signatures do not check out.

That protects the download on its way to you. It does not protect you from a compromise of the GitHub account itself: whoever can replace the script can replace KEYS.txt next to it, and a check against a key taken from the same place will pass. A signature starts to mean something when the key comes from somewhere else, or when you saved it earlier.

So here it is, outside the repository. A copy here only helps if whoever takes over the GitHub account cannot also edit this post, so save the key somewhere of your own:

untrusted comment: minisign public key 3E598A1C01907E17
RWQXfpABHIpZPttqrwYrQNHRTk/iLIz4cVh9KkRwAElHP+CoW/NPEysN

Key ID 3E598A1C01907E17. The same ID is printed in SECURITY.md and in the README, and the full key is KEYS.txt in the repository. If any of them ever disagrees with this post, do not run the script.

Verifying a release with the key from this post

sudo apt install minisign

TAG=v5.34.0
BASE="https://github.com/bivlked/amneziawg-installer/releases/download/$TAG"
curl -LO "$BASE/install_amneziawg_en.sh"
curl -LO "$BASE/install_amneziawg_en.sh.minisig"

minisign -Vm install_amneziawg_en.sh \
  -P RWQXfpABHIpZPttqrwYrQNHRTk/iLIz4cVh9KkRwAElHP+CoW/NPEysN

Note the -P: the key is passed on the command line, so KEYS.txt from the repository is not involved at all.

Expected output:

Signature and comment signature verified
Trusted comment: amneziawg-installer v5.34.0 install_amneziawg_en.sh

Read the second line, not only the first. The trusted comment is signed along with the file, so it cannot be edited, but minisign does not compare it with what you expected: an older script with its own older signature verifies just as well and simply prints an older tag. Accept the download only if that line says exactly amneziawg-installer v5.34.0 install_amneziawg_en.sh; otherwise stop.

A changed byte gives Signature verification failed and a non-zero exit code. Releases before v5.29.0 have no signatures, so there is nothing to check there.

v5.34.0: the default is now the full tunnel

A fresh install used to give clients a list of 34 IPv4 subnets ("Amnezia List + DNS"): all public IPv4, minus private and a few reserved ranges. Starting with v5.34.0 the default is AllowedIPs = 0.0.0.0/0, ::/0.

Why the change:

The Amnezia app shows its own split-tunneling page only when it sees 0.0.0.0/0 among the client routes. Given a subnet list, it decides that the server already splits traffic, says the server does not support split tunneling, and hides the toggle.
On Linux, awg-quick turns on its fwmark handling only for a /0 route. A list-shaped IPv4 config has none, and on my test bench that ended in a routing loop: packets to the server itself went back into the tunnel.
The Amnezia app's own server template emits the same 0.0.0.0/0, ::/0 pair, which is the form its split-tunneling page recognises.

The cost, plainly: the default profile no longer keeps private networks out of the tunnel, so whether your LAN stays reachable while the VPN is on depends on the client, not on the config. If you need home devices over IPv4, install with --route-amnezia to keep the previous mode. That mode does not bring back LAN access over IPv6: it also sends ::/0 into the tunnel.

A running server keeps its mode. The new default applies to new installs only; a reinstall takes the mode saved in the server settings, and existing client profiles do not change by themselves. To move a running server to another mode, rerun the installer with --force and the mode you want (without --force it refuses to touch a configured server), then reissue the profiles:

sudo bash ./install_amneziawg_en.sh --force --route-all      # or --route-amnezia
sudo bash /root/awg/manage_amneziawg.sh regen --reset-routes

--reset-routes replaces every client's own route list with the server-wide mode, including lists you edited by hand. The regenerated profiles have to be imported on the devices again.

The release also tidies up the routing menu and its edge cases: every mode now names both its benefit and its price, an unrecognised answer no longer falls back to the default silently, and a reinstall no longer changes the mode of a working server.

Full notes: v5.34.0 on GitHub.

Install

The installer is meant for a clean Ubuntu or Debian VPS (Ubuntu 24.04 or Debian 13 for a new server, Ubuntu 26.04 works too). If you verified the script above, run that same file instead of downloading it again:

sudo bash ./install_amneziawg_en.sh

Without verification, the quick path from the README is:

wget -O install_amneziawg_en.sh https://github.com/bivlked/amneziawg-installer/releases/latest/download/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh

About 20 minutes and two reboots; after each reboot, run the same command again and it picks up where it stopped.

Links:

Questions or problems? Open an issue on GitHub or leave a comment here.

AmneziaWG 3.1 on Oracle Cloud Always Free ARM: a Self-Hosted DPI-Bypass VPN

Ivan Bondarev — Thu, 16 Apr 2026 16:48:49 +0000

Updated in November 2026 for installer v6.2.2.

AmneziaWG 3.1 runs on Oracle Cloud's Always Free ARM instances (Ampere A1), so you can have your own DPI-resistant VPN server for $0 a month. I maintain amneziawg-installer, and since v6.2.0 it sets up the 3.1 generation on ARM64 too. This is a rewrite of my guide from April.

Why not plain WireGuard? In Russia, Iran and a few other places DPI recognizes the WireGuard handshake and drops it. AmneziaWG is a WireGuard fork that disguises those packets. It sends a few junk packets first, pads the handshake to random sizes and adds a packet that looks like ordinary traffic (my installer makes it look like a DNS reply). In 3.1 the packet headers are also encrypted with a per-server key, HeaderProtectionKey, so the type field that gives WireGuard away is hidden.

The installer does the server side: kernel module, firewall, sysctl, client configs. On Oracle it comes down to running one command three times.

What you need

An Oracle Cloud account on the Always Free tier. Oracle asks for a card to verify you, but Always Free resources are not charged.
An SSH key. If you have none, run ssh-keygen -t ed25519.
A client app that supports AmneziaWG 3.1: AmneziaWG for Android or iOS 3.1.4+, AmneziaWG for Windows 3.1.0+, Amnezia VPN 5.0.1.5+, or WG Tunnel 5.6.0+ on Android. Routers and other clients are in the client table. The stock WireGuard app cannot import these configs.

What Oracle gives for free now

Oracle has cut the Always Free allowance for Ampere A1. It is now 1,500 OCPU hours and 9,000 GB hours a month, which Oracle itself counts as 2 OCPUs and 12 GB of RAM around the clock. Older guides, my own included, said 4 and 24. A personal VPN uses a small part of that, since the tunnel runs inside the kernel.

Outbound traffic is free up to 10 TB a month, and both AmneziaWG and the installer are open source (the installer is MIT). Inside the allowance the whole setup costs nothing.

Create the instance

In the OCI console: Compute → Instances → Create instance.

Image: Canonical Ubuntu 24.04. The installer is tested on it the most. Ubuntu 26.04 and Debian 13 work too. Skip Debian 12. Its kernel is 6.1, and on kernels older than 6.7 the installer falls back to AmneziaWG 2.0.
Shape: VM.Standard.A1.Flex with 2 OCPUs and 12 GB, the whole free allowance. A smaller shape is fine as well.
Networking: a VCN with a public IPv4 address.
SSH keys: paste your ~/.ssh/id_ed25519.pub.

Ampere capacity in the free regions is hit and miss. If you get "Out of capacity", try another availability domain or come back later.

Open the VPN port

The default security list of a new VCN lets in SSH and not much else. The installer listens on UDP 39743 by default (--port=N sets your own). Go to Networking → Virtual Cloud Networks → your VCN → Security Lists → Default Security List → Add Ingress Rules and add:

Source CIDR: 0.0.0.0/0
IP Protocol: UDP
Destination Port Range: 39743, or the port you pass with --port

If your mobile carrier drops unfamiliar UDP ports, install with --mobile: the server then uses 443/udp with a mobile preset, so open 443/udp instead.

Install

ssh ubuntu@<your-public-ip>
wget -O install_amneziawg_en.sh https://github.com/bivlked/amneziawg-installer/releases/latest/download/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh --yes

The script comes from the latest release rather than the main branch, so you get a version that went through the release checks. --yes accepts the defaults: full tunnel, UFW on, and the packages the installer considers unneeded on a VPN-only box removed, snapd and unattended-upgrades among them. Without unattended-upgrades nobody installs security updates for you, so run sudo apt upgrade from time to time, or add --keep-packages to keep those packages. Leave out --yes if you would rather answer the questions yourself.

What follows:

First run: system update and preparation. With --yes the server reboots by itself and SSH drops. Wait a minute, log back in and run the same command.
Second run: the kernel module. On ARM64 it is built with DKMS from the Amnezia PPA for whatever kernel the instance runs, and it rebuilds itself after kernel updates. Oracle instances use Oracle's own kernel, 7.0 on Ubuntu 24.04 at the moment; I checked that the module builds for it. Then another automatic reboot.
Third run: firewall, configs, the service. The VPN works right away, no extra reboot needed.

It takes about 10 to 15 minutes, most of it the first system update. Progress is saved on disk, so an interrupted run continues where it stopped. If apt fails to download a package on a flaky network, the installer stops instead of retrying (since v6.2.1, because of the apt vulnerability CVE-2026-109518); just run it again.

Oracle's own firewall rules

Oracle's Ubuntu images ship their own iptables rules in /etc/iptables/rules.v4, loaded at boot by netfilter-persistent. They end with a REJECT in INPUT and FORWARD, so the VPN port would stay closed even after you open it in the security list. Installing UFW removes netfilter-persistent, but the rules already loaded stay in memory above UFW's rules until the next boot. Earlier versions of this guide had you reboot once more by hand because of that.

Since v6.2.2 the installer handles it: after setting up UFW it removes exactly that REJECT if it sits above UFW and is listed in rules.v4, and notes it in the log. A REJECT that is not in that file may be your own, so the installer leaves it, warns you and prints the iptables -D command to delete it.

I checked this on an Ubuntu 24.04 ARM64 server with a real rules.v4 and Oracle's rules reproduced, not on a real Oracle instance.

Check the result

The installer finishes with a report. Find the line "Protocol generation", it should say 3.1. If it says 2.0, the report gives the reason, an old kernel for example. Later on, sudo bash /root/awg/manage_amneziawg.sh check shows the same plus the server's health.

Then check the address your clients will connect to:

sudo grep Endpoint /root/awg/my_phone.conf

The instance sits behind Oracle's NAT, and its network interface has a private 10.x address. The installer asks an outside service for the public one, so normally you see your Oracle public IP here and do not need --endpoint. If you see a 10.x address, run the installer again with --endpoint=<your-public-ip>.

Connect your phone

The install creates two clients, my_phone and my_laptop. To add another one:

sudo bash /root/awg/manage_amneziawg.sh add tablet

Each client gets four files in /root/awg/:

my_phone.conf: the config for AmneziaWG desktop apps, Linux awg-quick and routers;
my_phone.png: a QR code of that config, for the AmneziaWG mobile apps;
my_phone.vpnuri and my_phone.vpnuri.png: a vpn:// link and its QR code, for the Amnezia VPN app.

The two QR codes are different, and Amnezia VPN only takes the vpnuri one.

The quickest way onto a phone is to print the QR code right in the terminal and scan it:

sudo bash /root/awg/manage_amneziawg.sh qr my_phone

Add --vpn at the end to get the one for Amnezia VPN.

If you want the files on your computer instead: /root/awg is readable by root only, and on Oracle you log in as ubuntu. So first copy them to your home directory on the server:

sudo install -m 600 -o ubuntu -g ubuntu /root/awg/my_phone.conf /root/awg/my_phone.png ~/

Then, on your computer:

scp ubuntu@<your-public-ip>:my_phone.conf ubuntu@<your-public-ip>:my_phone.png .

Afterwards delete the copies on the server with rm ~/my_phone.*, since the config holds the client's private key.

Once the phone is connected, sudo awg show awg0 on the server should show a latest handshake from the last minute or two, and a "what is my IP" site on the phone should show the Oracle address.

No handshake?

Before changing settings, look at what reaches the server. Run these on the server while the phone tries to connect (put in your own port, or 443 with --mobile):

sudo tcpdump -ni any udp port 39743
sudo awg show awg0

tcpdump shows nothing from the phone: the port is closed in the security list, or the traffic is blocked on the way to Oracle.
Packets arrive, but the peer's endpoint in awg show does not change: run sudo iptables -S INPUT and look for a -j REJECT line above the ufw- lines. If there is one, it is dropping them (tcpdump sees packets before the firewall does). The installer removes Oracle's own rule by itself and warns about any other such rule, on screen and in /root/awg/install_amneziawg.log. Otherwise the client does not support 3.1, or its config does not match the server.
Packets arrive, the peer's endpoint switches to the phone's address and its received bytes grow, but latest handshake stays empty: the network filters the burst of packets sent before the handshake. When I measured this in September on one Russian mobile carrier, the shape of the I1 packet decided it, not the number of junk packets: lowering Jc did not help, a DNS-shaped I1 did. New installs already get a DNS-shaped I1. Other carriers behave differently, and some need I1 removed entirely.

The full walk-through is in ADVANCED: no connection, and the cellular case in handshake fails on mobile data.

Worth knowing before you rely on it

Oracle reclaims idle Always Free instances. Idle means that over 7 days the 95th percentile of CPU use stayed under 20 %, and network and memory use were under 20 % too. A personal VPN often fits that, and a cron job that loads the CPU twice a week does not move a 95th percentile. Oracle's own advice is to upgrade the account to Pay As You Go. Reclaiming applies only to Always Free accounts, and Always Free resources stay free after the upgrade. A stopped instance can be started again if the shape is available in your region.
Host IPv6 is off by default. --allow-ipv6 keeps it on, and --allow-ipv6-tunnel also gives clients IPv6 inside the tunnel.
An ARM64 server set up before v6.2.0 stays on 2.0. A newer installer does not change the generation of a running server; moving to 3.1 means a reinstall and new configs on every device, see the update flow.
No VPN is guaranteed to get through. AmneziaWG makes the tunnel much harder to recognize, but networks also block by address and by packet shape, and results differ from one network to another. Known cases and workarounds are collected in ADVANCED.

What I have tested

On 3 and 4 November I ran ARM64 with 3.1 on an Ampere server at another provider: clean installs of Ubuntu 24.04, Debian 13 and Ubuntu 26.04, traffic through the tunnel, and a kernel update with the module rebuilt automatically. On 9 November I checked v6.2.2 with a clean install on Ubuntu 24.04 ARM64 with Oracle's firewall rules reproduced. I have not run this release on an actual Oracle instance. If Oracle behaves differently for you, tell me in the comments or in the repo.

Not on Oracle?

The same installer works on any full VM or bare-metal server with Ubuntu 24.04 / 26.04 or Debian 13, x86_64 or ARM64 (AWS Graviton, Hetzner CAX and others). It does not work in containers such as OpenVZ or LXC, because they cannot load a kernel module. On a Raspberry Pi with a 64-bit OS the 3.1 module builds against the Raspberry Pi OS kernels, but I have not run it on a Pi yet.

General install guide: INSTALL_VPS.md
ARM details: Raspberry Pi and ARM64 support
Releases: github.com/bivlked/amneziawg-installer/releases
The AmneziaWG protocol: docs.amnezia.org

If you hit a problem with a particular carrier, open an issue or a discussion in the repo and mention the carrier and the region. A good part of the mobile fixes in the installer started from reports like that.

AmneziaWG 2.0 in 5 Minutes: DPI-Resistant VPN That WireGuard Can't Match

Ivan Bondarev — Mon, 06 Apr 2026 16:56:11 +0000

WireGuard is blocked or throttled in Russia, China, Iran, UAE, Turkmenistan, and a bunch of other countries. If yours stopped working - you can replace it with AmneziaWG 2.0 in about 5 minutes. Same WireGuard speed, same crypto, but the traffic looks like random noise to DPI.

No Linux skills needed. Three commands and you're done.

What You Need

A clean VPS - any $3-5/month server works (1 GB RAM is plenty)
Ubuntu 24.04 / 25.10 or Debian 12 / 13 on that server
SSH access - your provider gives you an IP, login, and password

Don't have a VPS yet? Grab one from DigitalOcean, Vultr, or wherever - just make sure the datacenter is outside your country. Cheapest tier is fine. One 2026 caveat for readers in Russia: traffic to some datacenter networks (Hetzner AS24940 is the loudest example) is now cut at the AS level - the handshake completes, then data flow dies. There is a workaround via an I1 packet that mimics QUIC with an allowlisted SNI; see the AS-blocking section in ADVANCED.

Step 1 - Install (3 commands)

SSH into your server and run:

wget -O install_amneziawg_en.sh https://raw.githubusercontent.com/bivlked/amneziawg-installer/main/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh

The installer asks a few questions (port, subnet, number of clients) - defaults work for most setups. Hit Enter through them or use --yes for fully automatic mode:

sudo bash ./install_amneziawg_en.sh --yes

It reboots twice (kernel updates). Just re-run the same script after each reboot - it picks up where it left off. Whole thing takes about 5 minutes.

Step 2 - Connect Your Devices

After installation, you'll find client config files in /root/awg/:

.conf files - import into any AmneziaWG client
.png files - QR codes, scan from your phone
.vpnuri files - one-tap import for Amnezia VPN app

Which client to use:

Platform	Client	Link
All platforms	Amnezia VPN (recommended)	Download
Windows	AmneziaWG	Download
Android	AmneziaWG	Google Play
iOS	AmneziaWG	App Store
Android (FOSS)	WG Tunnel	F-Droid / GitHub

Quickest way: Install Amnezia VPN on your phone, scan the QR code. Done.

Step 3 - Verify

Open a browser and go to ifconfig.me. If you see your server's IP instead of your home IP - you're on the VPN.

On the server:

sudo awg show awg0

Look for latest handshake under your peer - if it shows a recent timestamp, you're good.

Managing Clients

Need to add a phone, laptop, or share access with someone?

# Add a new client
sudo bash /root/awg/manage_amneziawg.sh add my_laptop

# Give someone temporary access (auto-expires)
sudo bash /root/awg/manage_amneziawg.sh add guest --expires=7d

# See who's connected and how much traffic they used
sudo bash /root/awg/manage_amneziawg.sh stats

# Remove a client
sudo bash /root/awg/manage_amneziawg.sh remove guest

# List all clients
sudo bash /root/awg/manage_amneziawg.sh list

Each add generates a new .conf + QR code + vpn:// URI.

What's Running Under the Hood

The installer sets up AmneziaWG 2.0 - a WireGuard fork that randomizes packet headers, adds padding, and sends decoy packets before the handshake. DPI can't fingerprint it because every server speaks its own "dialect" of the protocol.

It runs as a kernel module (not the slower userspace Go implementation), so you get near-WireGuard speeds. The crypto is identical - Curve25519, ChaCha20-Poly1305, same as stock WireGuard.

The installer also hardens the server - UFW firewall with deny-all policy, Fail2Ban, and some kernel/network tuning.

I wrote a detailed breakdown of how the obfuscation works here.

Want a more detailed guide?

The full VPS deployment walkthrough lives at INSTALL_VPS.md on GitHub. It covers provider selection, OS choice, common troubleshooting (PPA fallback, DKMS recovery, mobile carrier patterns), and the full update + uninstall lifecycle.

What's new since publication

The installer keeps moving. v5.15.0 added opt-in dual-stack IPv6 inside the tunnel (--allow-ipv6-tunnel), and v5.15.4 documented the AS-blocking workaround mentioned above. For what landed since, see the releases page.

AmneziaWG 2.0: Self-Host an Obfuscated WireGuard VPN That Bypasses DPI

Ivan Bondarev — Wed, 11 Mar 2026 14:10:22 +0000

The Problem: WireGuard Is Easy to Block

WireGuard is a great VPN protocol - fast, lean, well-audited crypto. But it has one glaring weakness: predictability.

Every WireGuard packet starts with a 4-byte header containing a message type: 1 for handshake initiation, 2 for response, 3 for cookie, 4 for data. The handshake init is always exactly 148 bytes. These are strong, static signatures that DPI systems fingerprint without breaking a sweat.

And they do. WireGuard is actively blocked in 10+ countries right now. In Russia, standard WireGuard has roughly a 12% success rate. Iran sees 98% packet loss. China's Great Firewall picks it up within seconds. Egypt, Turkmenistan, Myanmar, Pakistan, UAE, Turkey, Belarus, Uzbekistan, Kazakhstan - all confirmed blocking or throttling at the DPI level.

I'm based in Russia, and I watched this unfold firsthand. Through most of 2024, my WireGuard tunnels worked fine. Then they started dropping - not all at once, but ISP by ISP, week by week. Russia's TSPU (Technical Means of Countering Threats - essentially DPI boxes installed at every major provider) learned to identify WireGuard traffic and silently kill it. Handshakes just stopped completing. No error, no timeout message - the packets simply vanished.

That's what pushed me to build an open-source installer for AmneziaWG 2.0, a WireGuard fork with protocol-level obfuscation. Here's how the protocol works under the hood, and how to get it running on your own server.

How DPI Catches WireGuard

Standard WireGuard uses fixed 32-bit message types for its four packet types. A DPI system needs a trivially simple heuristic:

UDP packet + known header value (1-4) + predictable packet size = WireGuard

Handshake init is always 148 bytes. Response is always 92 bytes. These invariant sizes are a dead giveaway. Once the DPI box flags a WireGuard session, it can block the IP, throttle the connection, or silently drop every packet.

What AmneziaWG 2.0 Does About It

AmneziaWG is a WireGuard fork by the Amnezia VPN team. It changes the transport layer to resist DPI while leaving the cryptographic core (Curve25519, ChaCha20-Poly1305, Noise IK) untouched.

The first version (AWG 1.x) replaced standard headers with custom fixed values. Helped for a while, but a patient DPI system could learn the new static values just as well.

AWG 2.0 (late 2025) took a different path: randomize everything, every time.

How the Obfuscation Actually Works

Dynamic Headers (H1-H4)

Instead of fixed header values, AWG 2.0 uses ranges. Every time a packet goes out, a random value is picked from within the configured range:

H1 = 100000-800000         # Handshake init
H2 = 1000000-8000000       # Handshake response
H3 = 10000000-80000000     # Cookie
H4 = 100000000-800000000   # Data transport

Ranges must not overlap - the protocol still needs to tell packet types apart. But the result is that every packet looks different on the wire. There's no single header value for DPI to latch onto.

Random Padding (S1-S4)

AWG pads packets with random bytes to break the fixed-size signatures:

Parameter	Packet Type	What happens
S1	Handshake init	Init becomes 148 + S1 bytes (bye-bye fixed 148)
S2	Handshake response	Response becomes 92 + S2 bytes
S3	Cookie (new in 2.0)	Pads cookie packets
S4	Data transport (new in 2.0)	Pads every data packet

S3 and S4 are the big additions in 2.0. S4 matters most - it touches every single data packet, which makes traffic analysis across the whole session much harder.

One gotcha: S1 + 56 must not equal S2. Why? Because 148 - 92 = 56, so if the padding values differ by exactly 56, the padded init and padded response end up the same size. That's a pattern you don't want.

CPS - Custom Protocol Signature (I1-I5)

Before the real WireGuard handshake, the client sends decoy packets that mimic another protocol's signature.

Parameters I1 through I5 define the content of up to 5 decoy packets using a tag format:

Tag	What it does
`<b 0xHEX>`	Insert specific bytes (hex-encoded)
`<r N>`	N cryptographically random bytes
`<rc N>`	N random alphanumeric chars [A-Za-z0-9]
`<rd N>`	N random decimal digits [0-9]
`<t>`	Current UNIX timestamp (4 bytes)
`<c>`	Packet counter (4 bytes)

Simple version: <r 128> - blast 128 random bytes. DPI sees a random UDP packet from who-knows-what.

Sneakier version: <b 0xc000000001><r 64><t> - starts with bytes that look like a QUIC Initial packet header, then random data, then a timestamp. A DPI box might classify this as the start of a normal QUIC session.

The server ignores CPS packets entirely - it just waits for the real handshake init that comes after.

In 2026 this stopped being theoretical. When traffic to an entire hosting network is cut at the AS level (Hetzner AS24940 is the best-known case: handshake passes, then data dies), a generic random I1 does not help - but an I1 that mimics a QUIC Initial with an allowlisted SNI inside can break through. Which SNI works turned out to be operator-specific, so expect some trial and error. Symptom, tooling and field results are written up in ADVANCED.

Junk Packets (Jc, Jmin, Jmax)

Before each handshake, the client fires off Jc junk packets with random sizes between Jmin and Jmax bytes. Pure noise that makes the connection setup profile less recognizable.

What This All Adds Up To

Each AmneziaWG 2.0 server ends up with its own unique parameter set. There's no universal DPI signature that catches all AWG 2.0 traffic - every server is, in effect, speaking its own dialect.

Here's the 1.x-to-2.0 changelog:

Parameter	AWG 1.x	AWG 2.0
H1-H4	Fixed values	Ranges (random per packet)
S1-S2	Padding for init/response	Unchanged
S3	-	New: cookie padding
S4	-	New: data packet padding
I1-I5 (CPS)	Late addition	Fully supported
Jc/Jmin/Jmax	Junk packets	Unchanged
Crypto	WireGuard (untouched)	WireGuard (untouched)

What About Speed?

People always ask this, so let's get it out of the way.

You might have seen a "65% overhead" number floating around online. The AmneziaWG developers tracked that down to the userspace Go implementation (amneziawg-go), not the protocol itself. The kernel module (what my installer uses via DKMS) runs at near-WireGuard speeds.

Metric	WireGuard	AmneziaWG 2.0	OpenVPN
Crypto overhead	~4%	~4% (same crypto)	~15-20%
Obfuscation overhead	-	+3-7% (padding/junk)	+10% (obfs4)
Total overhead	~4%	<12%	~25-28%
Battery drain (4h streaming)	18%	19% (+1%)	~25%

Real-world benchmark on an uncensored network: WireGuard 95 Mbps, AmneziaWG 92 Mbps. That's a 3% difference - you won't notice it.

And in a censored network? The comparison is "92 Mbps vs 0 Mbps." If WireGuard is blocked, raw speed numbers don't mean much.

How It Stacks Up Against Alternatives

	WireGuard	AmneziaWG 2.0	OpenVPN+obfs4	Shadowsocks	VLESS+Reality
DPI resistance	None	High	Medium	Low (detectable)	Very High
Speed	Fastest	Near-WG (<12% OH)	Slow (~25% OH)	Medium	Medium-Fast
Full VPN tunnel	Yes	Yes	Yes	No (proxy)	No (proxy)
Runs in kernel	Yes	Yes (DKMS)	No	No	No
Setup complexity	Simple	Simple (installer)	Complex	Simple (Outline)	Complex
Transport	UDP	UDP (obfuscated)	TCP/UDP + TLS	TCP	TCP
Audited crypto	Yes	Inherits WG audit	Yes	Partial	No

No DPI in your country? Plain WireGuard is simpler, just use that. Need the absolute maximum DPI resistance and OK with a proxy? VLESS+Reality is worth a look, but it's a proxy, not a VPN tunnel. AmneziaWG 2.0 fills the gap between them: WireGuard-grade performance with real obfuscation in a full tunnel.

One-Command Setup

Setting up AmneziaWG 2.0 by hand means building a kernel module, generating 10+ obfuscation parameters with the right constraints, writing server and client configs, configuring firewall rules. Lots of moving parts, lots of places to get something wrong.

I automated all of it in amneziawg-installer. It builds the kernel module via DKMS (not the slower Go userspace implementation), so you get the speed numbers from the table above.

What You Need

A clean Ubuntu 24.04 / 25.10 or Debian 12 / 13 server
Root SSH access
~1 GB RAM (any $2-4/month VPS is enough)

Install

wget -O install_amneziawg_en.sh https://raw.githubusercontent.com/bivlked/amneziawg-installer/main/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh

The script walks through 8 steps:

System hardening - strips bloat (snapd, modemmanager), tunes kernel params (BBR, network buffers), sets up swap
DKMS build - installs the AmneziaWG kernel module from Amnezia PPA
Firewall - UFW with deny-all default, SSH rate-limiting, VPN port only
Config generation - all AWG 2.0 parameters auto-generated with proper constraints, server + client configs + QR codes
Service start - Fail2Ban, awg-quick@awg0 enabled and running

Two reboots happen along the way (kernel updates + module loading). The script saves its state, so you just re-run it after each reboot and it picks up where it left off.

Non-Interactive Mode

For scripted or automated deployments:

sudo bash ./install_amneziawg_en.sh --port=51820 --disallow-ipv6 --route-amnezia --yes

Since v5.15.0 you can also enable dual-stack IPv6 inside the tunnel with --allow-ipv6-tunnel (off by default). Clients then get a ULA IPv6 address next to IPv4, and with native IPv6 on the server the client routes ::/0 through the tunnel. Existing IPv4-only clients keep working; recreate a client (remove + add) to make it dual-stack.

Managing Clients

After installation, use the management script:

# Add a client (generates .conf + QR code + vpn:// URI)
sudo bash /root/awg/manage_amneziawg.sh add my_phone

# List all clients
sudo bash /root/awg/manage_amneziawg.sh list

# Remove a client
sudo bash /root/awg/manage_amneziawg.sh remove my_phone

# Check server status
sudo bash /root/awg/manage_amneziawg.sh check

# Temporary client - auto-removed after 7 days
sudo bash /root/awg/manage_amneziawg.sh add guest --expires=7d

# Traffic stats per client
sudo bash /root/awg/manage_amneziawg.sh stats

# Backup all configs
sudo bash /root/awg/manage_amneziawg.sh backup

Connect using any client with AWG 2.0 support:

Amnezia VPN - full-featured, all platforms (>= 4.8.12.7)
AmneziaWG - lightweight tunnel manager, Windows (>= 2.0.0)
VeilBox - open-source, Windows/macOS

Checking That It Works

On the server:

sudo awg show awg0

Look for latest handshake under your peer. If it's there, the AWG 2.0 handshake went through.

From the client side:

curl ifconfig.me

If you see your server's IP instead of your home IP - you're connected through the VPN.

Final Thoughts

I've been running this on my own servers for several months now. From Russia, through ISPs with active TSPU filtering, AWG 2.0 connections hold where stock WireGuard has been dead since mid-2025. The crypto hasn't changed, so every WireGuard audit still applies. The overhead? Under 12% on paper, closer to 3% in my testing. And since the installer uses the kernel module, you skip the userspace performance hit entirely.

If you're in a country where WireGuard stopped working, give it a shot. And if you run into issues or have suggestions, I'd genuinely like to hear about it.

Full deployment walkthrough

For a step-by-step VPS-side walkthrough covering provider selection (Hetzner CAX, Oracle Free Tier ARM, generic), OS choice, install flow, first client setup, update flow, uninstall, and troubleshooting common issues - see the canonical install guide on GitHub: INSTALL_VPS.md.

Links:

amneziawg-installer on GitHub - star it if it's useful to you
AmneziaWG 2.0 Documentation
Amnezia VPN Client
Junker - AmneziaWG Signature Generator (for manual setup)

Router firmware with AWG support:

AWG Manager - Keenetic routers
AmneziaWG for Merlin - ASUS routers with GeoIP/GeoSite routing

Questions, bugs, feature requests? Open an issue on GitHub or leave a comment here.