How to Fix WireGuard Not Connecting
When WireGuard refuses to connect, the problem is usually small but hidden: a bad endpoint, a blocked UDP port, a wrong key, or a routing conflict.
This guide walks through the most effective checks for understanding how to fix WireGuard not connecting across desktop and mobile devices.
WireGuard is intentionally simple, which makes it fast and secure—but it also means a single misconfiguration can stop the tunnel from coming up at all.
The good news is that most failures can be narrowed down quickly with a few structured tests.
Start With the Most Common Failure Points
Before changing advanced settings, verify the basics that cause most WireGuard handshake failures.
These are the first things to inspect because they affect every platform and every deployment.
- Endpoint address: Confirm the server hostname or IP is correct and reachable.
- Port: Make sure the UDP listen port matches on both sides.
- Public and private keys: Ensure each peer has the correct key pair.
- AllowedIPs: Check that the routes match the traffic you want to send through the tunnel.
- Firewall rules: Confirm UDP traffic is not blocked on the server, router, or local device.
If WireGuard shows “No recent handshake,” it usually means the client is sending packets but the server is not responding, or the response never reaches the client.
Check the WireGuard Configuration for Mistakes
A config file that looks nearly correct can still fail to connect.
Review both the [Interface] and [Peer] sections carefully because small errors in either section can break the tunnel.
Verify the endpoint
The Endpoint field must point to the public address of the WireGuard server, not a private LAN address unless the client is on the same network.
If you use a domain name, confirm that DNS resolves to the correct IP address.
Match the keys correctly
Each side must use the other side’s public key.
A swapped key, missing character, or extra whitespace can prevent the handshake from completing.
Regenerate keys if you suspect the pair has been copied incorrectly.
Review AllowedIPs
AllowedIPs is both a routing rule and a peer selector.
A tunnel may appear to connect while traffic fails if this field is too narrow, too broad, or points to the wrong subnet.
For full-tunnel setups, common values include 0.0.0.0/0 and ::/0; for split tunneling, use only the specific subnets you want routed through WireGuard.
Inspect Firewall and Port Forwarding Rules
WireGuard uses UDP, so firewalls and NAT devices often cause silent failures.
If the server is behind a router, port forwarding must send the WireGuard UDP port to the correct internal host.
On the server, allow inbound UDP traffic on the configured port in the host firewall.
On cloud platforms such as AWS, Azure, or Google Cloud, also verify security groups or network security policies.
- Server firewall: Allow the WireGuard UDP port.
- Router NAT: Forward the same UDP port to the server’s LAN IP.
- Cloud security rules: Permit inbound UDP from the client or any source, depending on your policy.
- Client network: Some public Wi-Fi and enterprise networks block UDP or VPN traffic entirely.
If you can connect from one network but not another, the remote network is likely filtering UDP or the WireGuard port specifically.
Confirm That the Server Is Listening
A WireGuard server must be up and bound to the correct port.
On Linux, you can inspect the service and listening socket to ensure the interface is active and the port is open.
- Check whether the WireGuard interface is running.
- Confirm the configured UDP port matches the client endpoint.
- Verify the service starts without errors after boot.
- Review logs for key mismatch, address binding, or routing errors.
If the interface is down, restart the service and reapply the configuration.
On systems using wg-quick, a syntax error in the config can prevent the interface from starting.
Test DNS and Reachability
If your endpoint uses a hostname, DNS is a common weak point.
A wrong record, stale cached value, or split-horizon DNS issue can make the client try the wrong IP.
What to test
- Resolve the hostname from the client device.
- Compare the resolved IP with the actual server public IP.
- Test whether the server responds to the chosen UDP port from an external network.
- Try connecting with the raw public IP instead of the hostname.
If the tunnel works with the IP address but not with the hostname, the problem is almost certainly DNS-related.
Fix Routing and NAT Problems
Many people assume WireGuard is broken when the handshake succeeds but internet access or local network access still fails.
In these cases, the tunnel is connected, but traffic is not routed properly.
For a remote-access VPN, the server often needs IP forwarding enabled so packets can move between the WireGuard interface and the external network.
On Linux, this usually means enabling IPv4 forwarding and configuring NAT masquerading on the outbound interface.
- Enable IP forwarding: Required for traffic to pass through the host.
- Set NAT masquerading: Needed when client traffic exits through the server’s public interface.
- Check subnet overlap: If the client LAN and server LAN use the same range, routing conflicts can occur.
- Update AllowedIPs: Add the correct internal subnets to route them through the tunnel.
Subnet overlap is especially common when both locations use private ranges like 192.168.1.0/24.
In that case, the client may send packets to the wrong local gateway instead of the VPN.
Look at Handshake Timing and Packet Flow
WireGuard does not continuously chatter the way some older VPNs do.
That makes its logs and status output especially useful.
If no handshake appears, packets are not successfully reaching the peer or the peer is rejecting them.
Useful checks include:
- Last handshake time: Shows whether peers are exchanging packets.
- Transfer counters: Confirms whether data is moving in either direction.
- Persistent Keepalive: Helps clients behind NAT stay reachable.
Clients on mobile networks, hotel Wi-Fi, or home routers with aggressive NAT may benefit from Persistent Keepalive = 25.
This keeps the mapping open so the server can reply consistently.
Platform-Specific Checks
Different operating systems fail in different ways, so a platform-aware approach saves time.
Windows
- Run the WireGuard app as administrator if routes are not applied.
- Check whether another VPN client is competing for the same routes.
- Verify Windows Defender Firewall allows WireGuard traffic.
macOS
- Confirm the tunnel profile is active in the WireGuard app.
- Review system network settings for conflicting VPN or content filter software.
- Restart the app if the interface appears connected but traffic does not pass.
Linux
- Inspect
wg showfor handshakes and transfer counters. - Check
iptables,nftables, orufwrules. - Make sure the server has correct forwarding and NAT settings.
Android and iOS
- Switch between Wi-Fi and cellular to test network-specific blocking.
- Reinstall or reimport the profile if the config was edited externally.
- Check battery optimization or VPN permissions that may suspend background traffic.
Use Logs and Packet Tests to Narrow the Problem
When configuration checks are not enough, logs and packet captures reveal where traffic stops.
On Linux, tools such as wg show, journalctl, tcpdump, and ip route can show whether packets leave the client, reach the server, and return successfully.
A simple packet test can answer three important questions: Is the UDP packet leaving the client?
Does the server receive it?
Does the server reply and does the reply return to the client?
If the server sees inbound packets but the client never receives a reply, the problem is usually NAT, firewall, or endpoint reachability.
If the server sees nothing at all, the endpoint, DNS, or port forwarding is likely wrong.
When Recreating the Tunnel Makes Sense
If you have checked the endpoint, keys, ports, firewall rules, and routing settings and the tunnel still fails, rebuilding the configuration from scratch can be faster than continuing to patch a damaged profile.
This is especially true after migrations, firmware upgrades, or router changes.
When recreating the tunnel, keep the process disciplined:
- Generate a fresh key pair if corruption is suspected.
- Re-enter the endpoint and port manually.
- Copy AllowedIPs carefully and validate each subnet.
- Test the tunnel after each change instead of changing everything at once.
This approach helps isolate the exact step that restores connectivity, which is often the fastest path to a reliable fix.