Troubleshooting

In order of how often each one turns out to be the answer.

No handshake at all

sudo wg show          # "latest handshake" missing or minutes old

It has been up for less than a minute. A peer you have just created reaches our edge on the next reconciliation pass, which takes up to sixty seconds. Nothing is wrong before then, and this is the first minute of every tunnel anybody has ever made.
A source-routed config off Linux. By far the most common. That mode is written with PostUp rules that call ip: a graphical client has nowhere to run them, and on macOS the command-line one runs them, fails, and deletes the interface. Create the tunnel with Named destinations, or a full tunnel if it has to receive connections — see macOS & Windows.
Outbound UDP is blocked. We listen on UDP 51820, and 51821 for AmneziaWG. Some hosting providers and most corporate networks filter outbound UDP without saying so.
```
nc -zvu edge.anchoredip.com 51820
```
Something else already holds the default route. A managed VPN client — Cloudflare WARP under Zero Trust is the usual one — cannot be turned off from the machine and will not let a full tunnel take the route. Nothing is sent, and it looks like a filtered port.
The handshake itself is being recognised and dropped. Deep packet inspection identifies WireGuard by a fixed-size handshake packet. If UDP is open and nothing arrives, create the tunnel with the AmneziaWG transport and use an AmneziaWG client.
The config was edited. Keys, the endpoint and the obfuscation parameters must be exactly as issued. An AmneziaWG config against a stock wg, or the reverse, produces silence at both ends.

Your dashboard shows the last handshake per peer. “No handshake yet” means it has never connected — the list above. “Idle — last seen 3 h ago” means it worked and has nothing to send, which is normal for source routing.

Handshake works, but curl shows my own address

Expected in source-routing mode: only traffic whose source is a leased address goes through us, and curl with no arguments binds to whatever the default route gives it.

curl -s --interface 194.0.108.99 https://api.ipify.org

If that prints your leased address, everything is working and the job left is to make your application bind the same way — see Linux. If you want no binding at all, use a full tunnel, in a container so the rest of the host is unaffected.

Expected in Named destinations mode too, for the same kind of reason: only the addresses you listed go through us, and api.ipify.org is not one of them unless you put it there. Test that mode by reaching a destination you did list and asking it what it saw.

On a full tunnel the same symptom means something else, and it is worth recognising rather than debugging: a recent handshake, and every request still leaving from your ordinary address. That is an always-on corporate VPN capturing traffic below the routing table — it forwards our handshake happily, because that is ordinary outbound UDP, and takes everything else before any route is consulted. No tunnel on that machine can get around it. Whoever manages the policy has to exclude our address range.

It worked, then stopped

The lease expired. Traffic stops on the expiry date; the address is held for another seven days and is not reassigned. Paying restores exactly the same one.
The peer was revoked — from your dashboard or by an API call in a shutdown hook.
Two machines are using the same config. One configuration is one peer. Copies fight over a single session: handshakes succeed and traffic disappears, intermittently. Create a tunnel per machine.
The interface did not come back after a reboot.
```
sudo systemctl enable wg-quick@aip0
```

Some traffic works and some does not

Outbound mail. TCP 25, 465 and 587 are blocked on every lease until you ask. Sending from a cold address damages the reputation of the whole block, so it is off by default and we turn it on after a short conversation about what you are sending.
Large responses stall, small ones are fine. An MTU problem. The config ships 1420, which is right almost everywhere; behind PPPoE or a nested tunnel, try 1380.
IPv6 goes nowhere. Your /48 is delegated and works between your own machines over the tunnel, but is not yet reachable from the public internet — our upstream does not carry the announcement. Use the IPv4 address for anything the internet must reach.

Everything is slow

Traffic through us goes to Karaganda and back, one way. For allowlisted API calls a few times a minute that is invisible; for a chatty protocol between continents it is not, and no configuration will change the distance. Before treating it as a fault, check what it should be: Latency lists the round trip from our edge to every major region, and the command to measure your own leg.

The fix is to send less through us: source routing rather than a full tunnel, or an egress proxy with a careful NO_PROXY so in-cluster calls stay local. See Kubernetes.

Still stuck

Reply to any email we have sent you, or write to support@mail.anchoredip.com. Include your lease reference and what wg show prints. We can see our side of the handshake, which usually settles it in one message.