AmneziaWG Monitoring

To monitor AmneziaWG, you must complete a real handshake through the obfuscation layer: junk packets first, then a padded, re-typed initiation the server will actually accept. A vanilla WireGuard probe can't even get a reply. TunnelHQ speaks AmneziaWG natively, using the Jc/Jmin/Jmax, S1/S2, and H1–H4 values from your config, and alerts the moment handshakes stop completing. Free for 5 monitors.

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 = 203.0.113.7: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 US, EU, APAC, and SA regions with sub-second alerts on 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 monitors (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 monitor 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://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.

Pricing for AmneziaWG monitoring

AmneziaWG is one of the 11 protocols TunnelHQ monitors, first-class on every plan.

See full plan comparison →

AmneziaWG monitoring FAQ

Can I just use a WireGuard monitor for AmneziaWG?

No, unless your AmneziaWG server runs with neutral parameters that make it behave like vanilla WireGuard. With real obfuscation values set, standard WireGuard initiations are silently dropped, so a WireGuard-only monitor reports a healthy server as down. If some of your fleet is plain WireGuard, monitor those with the WireGuard checks and the AWG nodes with AmneziaWG checks.

Does TunnelHQ need my private key?

Yes. A real handshake requires it, the same as for WireGuard. Configs are encrypted with AES-256-GCM at rest and never shared. Generate a dedicated monitoring peer so its key can be revoked independently of user configs.

How does TunnelHQ know a config is AmneziaWG and not WireGuard?

The obfuscation parameters. A config carrying Jc/Jmin/Jmax, S1/S2, or H1–H4 lines is treated as AmneziaWG automatically when you paste it.

We run AmneziaWG for DPI evasion. What else fits that stack?

AmneziaWG pairs well with an Xray-based fallback like VLESS with REALITY for networks where even obfuscated UDP is throttled. TunnelHQ monitors both with protocol-correct checks, so you can see which layer of your censorship-resistance stack is actually reachable from each region.