WireGuard does not connect: common causes
WireGuard most often fails to connect for one of four reasons: the operator is cutting UDP, the endpoint is specified incorrectly, AllowedIPs is wrong, or the TSPU recognized the handshake signature. Each of these produces different symptoms and is fixed in different ways.
WireGuard is a modern VPN protocol that runs over UDP and establishes a connection with one short handshake (Noise IK). Its strength is simplicity and speed; its weakness is the same simplicity: the first packet has a very recognizable structure, and any DPI can easily detect it. In Russia, this has long been the main reason for mass WG disconnects.
Next is step-by-step diagnostics: how to distinguish “my config is broken” from “the operator is cutting UDP” and from “the TSPU is killing WireGuard as a class.”
In short
- WireGuard works over UDP — if the operator cuts UDP, the handshake will not complete.
- A stuck handshake more often means “packets are not getting through” than “the server refused the connection.”
- An endpoint in host:port format is required; if it is empty or contains an error, it fails immediately.
- AllowedIPs = 0.0.0.0/0, ::/0 routes all traffic; if a subnet is set, only that subnet goes through.
- NAT and CGNAT at mobile operators can cut long-lived UDP sessions — PersistentKeepalive is needed.
- The WG signature is exposed to DPI; in RU networks, often only AmneziaWG helps.
Why WireGuard does not come up: the main reasons
WireGuard starts like this: the client sends an Initiation packet, the server replies with a Response packet, then data packets follow. If any of these steps fails, the client will show “handshake did not complete” or simply stay silent in connecting.
UDP blocking
Some operators, especially mobile operators during TSPU “drills,” cut arbitrary outgoing UDP traffic. TCP still works. An indirect sign is that the handshake does not complete on any network of that operator, but WG works without problems over a home provider’s Wi-Fi.
Incorrect endpoint
Endpoint = host:port is required. A typo in the domain, a wrong port, or an IP that is not reachable from outside sends the handshake nowhere. This is very simple to check: ping and test the port from another host.
Broken AllowedIPs
If AllowedIPs contains, say, only 10.0.0.0/24, then only that subnet goes through WG, while all other traffic bypasses the tunnel. The connection “works,” but the internet “does not work.” For a full tunnel, you need 0.0.0.0/0, ::/0.
NAT, CGNAT, and keepalive
Mobile operators use CGNAT with short timeouts for UDP sessions. If the client is silent for more than a minute, NAT may “forget” the session and return packets from the server will go nowhere. This is fixed with the PersistentKeepalive = 25 option in the [Peer] section.
Handshake signature
The first WG packet has a fixed length and a characteristic header. DPI recognizes it from a single packet and cuts the connection. This is no longer about the config — it is about the protocol itself. Here the options are either switching to a fork with obfuscation (AmneziaWG) or wrapping WG in an outer layer.
How to understand what exactly broke
| Symptom | Possible cause | What to check |
|---|---|---|
| Handshake is stuck, no packets | UDP is blocked or the server is unreachable | Try from another operator / another network |
| Handshake completes, but the internet “disappears” after 5–10 seconds | DPI recognized WG and is cutting the channel | Switch to AmneziaWG or another obfuscated fork |
| There is a connection, but only some sites open | AllowedIPs is limited to a subnet | Set 0.0.0.0/0, ::/0 |
| The tunnel drops after a minute of idle time | NAT/CGNAT killed the UDP session | Add PersistentKeepalive = 25 |
| “Endpoint not specified” or “unable to resolve” | Typo / wrong domain | Check host:port manually |
| Works over Wi-Fi, does not work over LTE | The operator is cutting UDP or WG itself | Compare measurements by operator |
How to check right now
To understand whether this is your case or a general problem, run a check through Freedom Checker. We constantly ping popular VPN protocols and services from probes across several operators and regions. The map quickly shows where WG works, where UDP is being cut, and where a specific VPN service is unavailable.
The WireGuard specification and reference implementations are available at wireguard.com — the handshake and config format documentation is there too. If you need a fork with obfuscation, look at AmneziaWG — it adds a layer to classic WireGuard that breaks the DPI signature.
Failure or blocking?
A failure is about the server or route. Symptoms: it suddenly stopped working for all users of one server, then fixed itself an hour later. The connection hangs in connecting because packets are not reaching the endpoint at all.
Blocking is about the operator and the protocol. The symptoms are stable: WG does not work on one network, but works on a neighboring one. Often the handshake completes, and then the data is cut — this is signature-based blocking. In that case, neither changing the server nor changing the port helps; you need a fundamentally different protocol (AmneziaWG, VLESS+REALITY) or an outer layer over WG.
What to pay attention to
- Enable PersistentKeepalive = 25 — this is a required setting for mobile networks.
- Check AllowedIPs: for a full VPN tunnel, it must be 0.0.0.0/0, ::/0.
- If the endpoint is specified as a domain, make sure DNS resolves it — try substituting the IP directly.
- Changing the port, for example 51820 → 443, sometimes bypasses crude UDP filters, but not signature-based DPI.
- On Android, the WireGuard app has no built-in obfuscation — for resilience, use Amnezia.
- Do not confuse AmneziaWG and AmneziaVPN — the first is a protocol fork, the second is a client.
- If the handshake does not reach any public WG server at all, the operator is almost certainly jamming UDP to non-standard ports.
Conclusion
WireGuard fails to connect for a very predictable list of reasons: UDP is not getting through, the config is broken, NAT killed the session, or DPI recognized the signature. The only difficulty is quickly understanding which of the four applies to you.
The fastest diagnostic step is to try the same config on another network or compare measurements by operator. After that, it will be clear whether to fix the config or change the protocol.