Amnezia not working: what to check in your config and on your server before you change everything

Handshake on your own AmneziaWG server (through Amnezia or another client) suddenly stopped going through, even though nobody touched the config? Or a brand-new config never came up in the first place? What follows is not guesswork — it is an order of checks: five steps where we have found the cause ourselves on our own test rigs, plus what our own measurement across three mobile carriers showed in July 2026.

Five checks, in order

Order matters here: the next step is only worth checking once the previous one did not help. Otherwise it is easy to burn an evening tweaking obfuscation when the real culprit is MTU.

1. The server's address answers from this exact network, right now. Start with a plain ping or curl to the server's address, no tunnel involved. No answer at all means the problem is not AmneziaWG — this network cannot reach the server in the first place, and the rest of the list will not tell you anything.
2. Jc/Jmin/Jmax/S1–S4/H1–H4 match on both sides. We measured this directly: S and H are a shared alphabet — off by one and there is no handshake at all — while Jc, Jmin, Jmax and I1–I5 are the client's own business; the server never checks them. The full breakdown of what has to match and why is in “How to set up AmneziaWG: what every line of the config means” — we do not repeat it here.
3. Module and client version. AmneziaWG 3.1 added fields that 1.5 and 2.0 never had (header protection, timers). A config from an older generator will not "partially apply" — the tool answers Line unrecognized and stops parsing the file, and the same happens in reverse. One command on the server tells you the version: awg --version.
4. MTU has not been eaten by padding. The S4 field adds bytes to every data packet after MTU was already computed. The tell-tale symptom: the handshake goes through, light pages load, heavy ones hang. How to count MTU for AmneziaWG — the byte-by-byte breakdown.
5. Whether IPv6 exists on this particular path. If the server is reachable over IPv6 but the client insists on IPv4 (or the other way round), and that specific path is the one that gets filtered, there will be no handshake even though both sides work fine on their own. What changes and how to check it yourself — IPv4 vs IPv6, measured.

If there is still no handshake after all five checks, and the server's address does answer from your network, the problem is probably not the config at all. What we measured about that case is in the next section.

What our carrier bench showed

If the address answers, the parameters match, the versions line up, and MTU and IPv6 have both been checked, and there is still no handshake — that is no longer a config question. We have our own measurement for exactly this case: on 28 July 2026, in Moscow, we ran the same server and the same phone through three mobile carriers, changing exactly one thing in the config at a time (how we measure; the full rows are in our write-ups on Megafon and MTS).

The port itself made no difference: on Megafon, port 443 without obfuscation never helped, while obfuscation on an ordinary high port worked just as well as on 443. What decides it is the content of the first packet, not the port number. The different working masks we tried (QUIC, STUN, SIP, each on its own port) gave between 96.9 and 127 Mbit/s — a spread smaller than the spread between two runs of the very same variant on a mobile network, so comparing them by speed is not meaningful: any working variant gives roughly a hundred megabits where nothing connects at all without it. Tele2 was not part of this run.

⚠️ The date and place of the measurement are part of the result, not fine print: this is Moscow, 28 July 2026. A different region, or today, may behave differently — we update these numbers only with new measurements, never with reasoning.

If you do not have your own server

Running a server, checking every one of those config fields, and keeping the package version current is work not everyone wants to sign up for. Mayak already does this: AmneziaWG 3.1 runs on every exit, the server hands out the obfuscation parameters, and nobody assembles a config by hand or copies it between devices. If one path still does not get through, the app switches to the next one instead of getting stuck on a single route — how that works is in “One button, three paths”.

What we measured

• Versions, taken on 26 September 2026. Our own app, site channel, version 0.7.37: amneziawg-go/v3 v3.1.20260814, amneziawg-tools v1.0.20260223 (our fork, tagged v0.7.37). On exit nodes nl2 and pl1: kernel module amneziawg 3.1.20260812, amneziawg-tools v3.1.20260812 (taken around 13:55 Moscow time). Tool: scripts/check-versions-everywhere.sh.
• The carrier rows. From our own bench log — measured on 28 July 2026, in Moscow, across three networks back to back, one variable changed at a time.
• What must match in the config. Measured separately, the same day — which fields are shared between client and server and which belong to the client alone; the full table is in the config breakdown, not repeated here.

What we do not know

• We have not tested a self-hosted server on someone else's hosting. Every carrier row above was measured through our own bench and our own app, not through a reader's arbitrary VPS — that hosting's own path to its server was not part of this measurement.
• We have not tested the Amnezia client itself. The AmneziaWG versions above come from our Android app and our own nodes, not from the Amnezia app on a phone or a computer — how it behaves with the same config, we have not measured.
• Only Moscow, only 28 July. A different city, or today, may look different — that is exactly why we date and locate every measurement instead of leaving the conclusion unattributed.
• We have not re-run a full handshake failure on newer carriers since 28-07. If your network is not in the table above, the honest answer is "not measured," not a guess.

Short answers

Amnezia stopped working specifically today — how do I tell a temporary problem from a lasting one? Before hunting for a cause, run the first of the five checks: does the server's address answer from your network at all, with no tunnel. If it does, and there is still no handshake, work through checks 2–5 in order; if the server worked yesterday and nothing changed on it, but the network is unfamiliar, that is closer to what we measured on three carriers in July (the section above) than to something broken on your end.

Amnezia keeps failing even though the config is the same — why? The config itself is rarely to blame if it used to work. What usually changes is something around it: the package version on the server, MTU after an update, whether IPv6 is even available on the new network. Every place we ourselves have found the cause is in “Five checks, in order” above.

AmneziaWG will not connect at all, no handshake — where do I start? With the first check, not the last: confirm the server's address answers from this network with no tunnel, then compare S/H on both sides — in our own measurement, a mismatch there removes the handshake entirely rather than degrading it.

What changed in AmneziaWG 3.1? Header protection (HeaderProtectionKey) and a handful of timers that 1.5 and 2.0 never had. A config from an older generator will not partially work on 3.1 — either every field matches or you get Line unrecognized. The full field list by version is in the config breakdown.

Where do I get a config for Amnezia? The server you are connecting to hands it out — your own, or a service's. These fields are not something you configure from scratch by hand: half of them must match the other side exactly, and only that side knows the values; the field-by-field breakdown is in a separate article. If running your own server is not something you want to do, Mayak's config arrives in the app already assembled — see the section above.

AmneziaWG will not work over mobile data — is that the same thing? It might be, or it might not be, and confusing the two gets expensive. If the config and every parameter match on both sides, and the handshake only fails on cellular, look at “What our carrier bench showed” above: on one of the three carriers we saw exactly this picture, and no parameter fixed it except obfuscation.

AmneziaWG is a project of the Amnezia team, distributed under an open license. Mayak Networks is not affiliated with or endorsed by the Amnezia team.