AmneziaWG monitoring

What AmneziaWG changes on the wire

AmneziaWG is a WireGuard fork built for networks with deep packet inspection. The cryptography is untouched. Same Noise handshake, same Curve25519 keys, same ChaCha20-Poly1305 transport. What changes is how packets look on the wire, controlled by parameters in the [Interface] section:

• Jc, Jmin, Jmax. Before each handshake, the client sends Jc junk packets of random size between Jmin and Jmax bytes, burying the handshake in noise
• S1, S2. Random-byte padding prepended to the handshake initiation and response, changing their sizes away from WireGuard's fingerprintable 148 and 92 bytes
• H1–H4. Remapped message-type headers replacing WireGuard's standard types 1–4, so packets no longer carry WireGuard's signature

The result is traffic that DPI equipment can't classify as WireGuard. Which is exactly why generic monitoring can't classify it either.

Why ordinary WireGuard monitors fail against AmneziaWG

An AmneziaWG server with non-default parameters only answers packets that match its obfuscation profile. A monitoring tool that speaks standard WireGuard sends a normal initiation with message type 1 and no padding. The server sees an unrecognized header and drops it silently. No error, no ICMP, nothing. That's the DPI resistance working as designed.

So teams running AmneziaWG usually end up in one of two bad places:

• A WireGuard-generic monitor marks a perfectly healthy AmneziaWG server as permanently down
• They fall back to ping or UDP port probes, which mark dead servers as up, because UDP probes prove nothing and the host answering ICMP says nothing about the tunnel

The only meaningful check is a handshake performed through the obfuscation layer, with the exact parameter set the server expects. That's what TunnelHQ does.

How TunnelHQ monitors AmneziaWG

Paste your full AmneziaWG config. TunnelHQ auto-detects the protocol from the obfuscation parameters and parses everything it needs:

[Interface]
PrivateKey = yAnz5TF+...
Address = 10.8.1.2/32
Jc = 4
Jmin = 40
Jmax = 70
S1 = 116
S2 = 61
H1 = 1239174714
H2 = 2113136509
H3 = 420684291
H4 = 1213418516

[Peer]
PublicKey = xTIBA5rb...
Endpoint = 176.61.144.20:51820
AllowedIPs = 0.0.0.0/0

Each check then behaves exactly like an AmneziaWG client: send the junk-packet burst, send the padded initiation with your remapped headers, and require the server's valid handshake response. Only a completed cryptographic handshake counts as "up". Checks run from the general pool, or from the countries you pin a tunnel to (Pro and Business), with an alert on every state change.

One detail worth knowing: TunnelHQ connects to the [Peer] Endpoint host from your config. The [Interface] Address is your tunnel-internal IP (like 10.8.1.2) and is never used as the check target, a mix-up that breaks many hand-rolled monitoring scripts.

Tune Jc before you blame the server

A pattern we see in the field: AmneziaWG checks (and clients) failing intermittently while the server looks fine. The cause is often the junk-packet burst itself. With a large Jc and generous Jmax, every single handshake is preceded by tens of kilobytes of random UDP, and hosting-provider flood protection can read that burst as an attack and drop part of it, taking the handshake down with it. Sometimes.

Small values are enough to defeat DPI signature matching. A Jc in the single digits with moderate sizes evades classification without looking like a flood. If your tunnel shows a flapping pattern on an otherwise healthy AmneziaWG server, lowering Jc on both server and clients is the first thing to try. Because TunnelHQ uses your real config, its checks reproduce exactly what your users experience, flapping included, which is precisely the signal you need.

Common AmneziaWG failure modes TunnelHQ catches

• Obfuscation parameter drift. A server reinstall generates new random S1/S2/H1–H4 values and every old client config dies silently
• Key rotation that didn't reach all peers
• UDP flood protection eating oversized junk-packet bursts (see above)
• Oversized S1/S2 padding pushing handshake packets past the path MTU
• Endpoint or port migration with stale client configs
• The AWG interface down while the host still answers ping

Automate checks with the REST API

Send the config as one field. TunnelHQ extracts the endpoint automatically:

curl -X POST https://app.tunnelhq.com/api/v1/check/public \
  -H "Content-Type: application/json" \
  -d '{
    "protocol": "amneziawg",
    "config": "[Interface]\nPrivateKey=...\nJc=4\nJmin=40\nJmax=70\n..."
  }'

Monitoring a fleet? The REST API also accepts a servers array of config entries, so one call can register checks for every AmneziaWG node you run. You can also run a one-off check right now in the free protocol tester. Paste the config, no account needed.

What a failed check tells you

A failed check comes with a message that says where to look. On an AmneziaWG tunnel the most common are Tunnel unreachable and Tunnel established - Internet is stuck, and, less often, a rejected configuration.

• Tunnel unreachable. The handshake didn't complete. Check that the server is running, that the UDP port in Endpoint is reachable, that the server has this client's public key as a peer, and that the obfuscation parameters match the server's.
• Tunnel established - Internet is stuck. The handshake worked, but traffic didn't reach the internet. Check the server's routing and NAT, its DNS, and whether its outbound traffic is blocked.
• Couldn't complete this check — the monitor's configuration or credentials were rejected. The server's status is unknown. The config couldn't be used. The tunnel shows Unknown, with no alert. Check the config against one that works in an AmneziaWG client.

Need this on a schedule?

Obfuscation failures are silent by design. No error ever comes back, things just stop connecting. TunnelHQ completes a real handshake through your junk-packet and header parameters every 1 to 5 minutes by plan, and fires Slack, email, Telegram, Discord, or webhook alerts as soon as a missed handshake is confirmed.

Pricing for AmneziaWG monitoring

All plans include AmneziaWG monitoring.

See the full plan comparison

Read more

• AmneziaWG in the docs
• Why WireGuard port monitoring misses real outages
• WireGuard monitoring
• VLESS monitoring