WireGuard Connected but DNS Not Working on Linux
Troubleshoot WireGuard DNS failures on Linux. Check handshake evidence, inspect systemd-resolved settings and verify each change in the affected app.
FreeGuard Editorial Team · 2026-11-04
A WireGuard connection can exchange encrypted packets while applications still fail to look up names. On Linux, check the tunnel, the resolver settings and the affected application separately. These checks help narrow down which part needs attention before you change a working configuration.
This guide covers Linux systems using WireGuard tools and systemd-resolved. It explains documented diagnostic commands and includes no live-VPN test results. Use the interface name from your own setup in place of wg0.
Establish which connection is failing
Record one failing hostname and the application reporting the error. Note whether public websites, internal names or both are affected. If a comparison on another trusted network is appropriate, test only a public hostname and keep VPN protection enabled. Keep internal or sensitive names on the approved network and resolver; do not send them to another network’s DNS service.
Keep those observations together. They give you a repeatable test instead of a sequence of configuration changes with no clear result. A successful test in one browser is useful evidence about that browser; repeat the check in the application that originally failed.
Check WireGuard without exposing the configuration
For a Linux system with WireGuard tools installed, inspect the runtime state:
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer
The WireGuard tool manual documents these two views. Check them around a controlled connection attempt. A recorded handshake is one observation, not a complete explanation of application connectivity.
Keep the output local while diagnosing. Avoid posting full configuration files or machine-readable configuration dumps: they can contain private or preshared keys. If you need support, prepare a small summary with addresses and identifiers removed.
Inspect the active resolver
On systems using systemd-resolved, run:
resolvectl status
resolvectl query example.com
The resolvectl manual describes status as the global and per-link settings view. A query reports the lookup result and information about how the name was resolved. Replace example.com with the failing public name when you repeat the test.
Record the result before editing anything. If the command is missing, or reports that the resolver service is unavailable, identify the DNS manager used by your distribution. This branch of the guide assumes systemd-resolved is running.
Match the settings to the tool that starts the tunnel
The wg-quick manual treats DNS as an extra interface option. On startup, wg-quick invokes resolvconf to apply those DNS settings; on shutdown, it removes them. With the default Table = auto, routes are derived from peer AllowedIPs; a default route (0.0.0.0/0 or ::/0) receives special handling using ip-rule. Table = off disables automatic route creation, while another Table value selects a routing table. Check this option before drawing conclusions about the routes wg-quick should install.
Check how you actually start WireGuard. If a desktop network manager or another client manages the tunnel, inspect its own DNS and routing settings. A field in a configuration file is a starting point for investigation; compare it with the active settings you recorded.
For internal names, inspect which link receives the relevant DNS queries. systemd-resolved uses routing and search domains when selecting DNS servers, as explained in its resolver service documentation. An internal lookup and a public lookup can therefore need different investigation paths.
Make one change and verify the result
Use the observations to choose the next check:
| Observation | Next step |
|---|---|
| The controlled attempt produces no useful tunnel evidence | Investigate the tunnel before assuming DNS is the cause |
| The resolver query fails for the affected name | Review the active resolver settings and reachability of the intended DNS server |
| The query succeeds but the application still fails | Investigate that application’s own connection and resolver behavior |
| Public names work while internal names fail | Review the internal DNS server and domain routing configuration |
Save the original settings before a change. Repeat the same query and application action afterward, and record what changed. Restore the previous settings if the result is worse. Avoid resetting the entire firewall or changing several network components at once.
For related configuration guidance, see the Clash troubleshooting guide if you also use a separate proxy client. Keep that configuration separate from your WireGuard test so the result stays understandable.
The workflow above is specific to Linux WireGuard tools and systemd-resolved. Use the branches that match the software managing your tunnel.