Describe the bug
After updating WG Tunnel to the current release, general web browsing became unusably slow. DNS lookups take a long time to resolve, and pages then render in fragments — images, scripts, and subsequent origins appear in staggered bursts, similar to a dial-up connection.
Throughput itself does not appear to be the problem. Large downloads over the same tunnel remain acceptable. The regression is specifically in interactive use: name resolution, first-byte time, and multi-host page assembly.
This is not a server, config, or upstream DNS change. The comparison was done with:
- the same WireGuard configuration file
- the same peer / endpoint / server
- the same DNS servers specified in the config
- the same AllowedIPs, keepalive, and routing
- the same device, network path, and ISP
The previous WG Tunnel build was snappy for both surfing and downloading. The current build is still fine for downloading, but the browsing delay is a deal-breaker. I have reverted to the previous version and will stay there until this is resolved.
Environment
- Device: Samsung A50 , Redmi 4A, Xiaomi Mi5x
- Android version: 11, 11 & 8.1
- WG Tunnel version with the bug: 5.7.1 both GitHub and F-Droid
- App mode: VPN
- Split tunneling: off
- DNS settings in the app: ControlD (DOT)
- Private DNS : Off
- IPv6 on the tunnel and on the underlay: No
- Network when reproducing: Both
Configuration notes
The WireGuard interface and peer settings were not edited between the good build and the bad build. Endpoint, DNS addresses, AllowedIPs, PersistentKeepalive, and MTU are identical. Only the WG Tunnel application version changed.
To reproduce
- Import or keep the existing WireGuard configuration that worked on the previous WG Tunnel version.
- Confirm the endpoint, DNS, AllowedIPs, and server are unchanged.
- Update WG Tunnel to the current store / F-Droid / GitHub release.
- Bring the tunnel up (manual or auto-tunnel).
- Wait until the handshake is established and the tunnel shows as connected.
- Open a typical multi-origin site in a browser (news site, search, documentation, social).
- Observe DNS wait and piecemeal page load.
- Start a large file download over the same tunnel and note that download throughput is still acceptable.
- Uninstall / sideload the previous WG Tunnel version with the same config.
- Repeat steps 4–8 and observe that browsing is immediately snappy again.
Expected behavior
With an established handshake, name resolution and page loads should feel as they did on the previous version: short DNS wait, pages populate as a whole, subsequent navigations stay responsive. Updating the client must not add multi-second stalls to ordinary browsing when the config, server, and DNS are unchanged.
Actual behavior
- Queries take a noticeable time to resolve after the update.
- Pages load in pieces; assets trickle in as if each hostname is resolved serially and slowly.
- The session feels like a high-latency, low-interactivity link rather than a working VPN.
- Downloads of large files remain reasonably fast, so raw tunnel bandwidth is not the limiting factor.
- Reverting to the previous WG Tunnel version, with no other change, restores the old snappy behavior.
This points to a client-side change in DNS handling, split-DNS policy, resolver bootstrapping, dual-stack lookup order, or how Android is given the VPN DNS, not to the WireGuard peer or the network path.
Impact
Everyday browsing is the primary use of this tunnel. A client that downloads well but cannot resolve and render pages promptly is not usable as a daily driver. I have rolled back and will not run the current release until this is fixed.
Additional context
Recent public changes around 5.7.x that look relevant from the outside (I cannot confirm they are the cause):
- 5.7.0 (2026-09-05) includes a core bump for tunnel split-DNS policy.
- Shortly after, master received
fix: core custom tunnel dns memory leak.
- The product now advertises split / encrypted DNS (plain DNS, DoT, DoH) and deferred endpoint bootstrapping.
Those features are valuable, but something in the new resolution path appears to serialize or stall lookups that used to complete quickly. Happy-Eyeballs-style A/AAAA delays, split-DNS suffix matching, DoH/DoT fallback, or a leak/stall in the custom tunnel DNS path would all produce exactly this symptom: downloads OK, multi-host browsing feels like dial-up.
What I have already ruled out
- Server load or peer change — same server, same config.
- DNS provider change — same DNS servers in the config.
- ISP or local Wi-Fi — same path; only the app version changed.
- “The tunnel is down” — handshake succeeds; downloads work.
- A single broken site — general browsing is affected.
- Tried both versions back and forth. Older version is snappier and working perfectly fine.
Thank you for the project — the previous version was excellent. I want to come back to current as soon as browsing latency is restored.
Describe the bug
After updating WG Tunnel to the current release, general web browsing became unusably slow. DNS lookups take a long time to resolve, and pages then render in fragments — images, scripts, and subsequent origins appear in staggered bursts, similar to a dial-up connection.
Throughput itself does not appear to be the problem. Large downloads over the same tunnel remain acceptable. The regression is specifically in interactive use: name resolution, first-byte time, and multi-host page assembly.
This is not a server, config, or upstream DNS change. The comparison was done with:
The previous WG Tunnel build was snappy for both surfing and downloading. The current build is still fine for downloading, but the browsing delay is a deal-breaker. I have reverted to the previous version and will stay there until this is resolved.
Environment
Configuration notes
The WireGuard interface and peer settings were not edited between the good build and the bad build. Endpoint, DNS addresses, AllowedIPs, PersistentKeepalive, and MTU are identical. Only the WG Tunnel application version changed.
To reproduce
Expected behavior
With an established handshake, name resolution and page loads should feel as they did on the previous version: short DNS wait, pages populate as a whole, subsequent navigations stay responsive. Updating the client must not add multi-second stalls to ordinary browsing when the config, server, and DNS are unchanged.
Actual behavior
This points to a client-side change in DNS handling, split-DNS policy, resolver bootstrapping, dual-stack lookup order, or how Android is given the VPN DNS, not to the WireGuard peer or the network path.
Impact
Everyday browsing is the primary use of this tunnel. A client that downloads well but cannot resolve and render pages promptly is not usable as a daily driver. I have rolled back and will not run the current release until this is fixed.
Additional context
Recent public changes around 5.7.x that look relevant from the outside (I cannot confirm they are the cause):
fix: core custom tunnel dns memory leak.Those features are valuable, but something in the new resolution path appears to serialize or stall lookups that used to complete quickly. Happy-Eyeballs-style A/AAAA delays, split-DNS suffix matching, DoH/DoT fallback, or a leak/stall in the custom tunnel DNS path would all produce exactly this symptom: downloads OK, multi-host browsing feels like dial-up.
What I have already ruled out
Thank you for the project — the previous version was excellent. I want to come back to current as soon as browsing latency is restored.