On a mobile network — and sometimes on hotel, airport and shared WiFi — a VPN tunnel can look connected while pages stall, name lookups time out, and then everything comes back a minute later. Almost always it is one of two settings on your device, not the service. Both are fixed in the WireGuard app in under a minute, and neither needs a new config file.
MTU = 1280 on a mobile
connection, and PersistentKeepalive = 25 on any connection that sits idle
behind a carrier or hotel NAT. If your tunnel works on WiFi and drops on mobile data, the
MTU is the one to try first.
MTU — the largest packet your device will put through the tunnel. A mobile path often carries less than a desktop one, so a tunnel set too high handshakes fine and then silently drops the bigger packets: the tunnel says it is up, small requests work, and anything larger hangs. 1420 is right for a normal wired or WiFi path; 1280 is the safe value on mobile data, and it is what the WireGuard apps use when a config does not say.
Keepalive — a small packet every 25 seconds, so the carrier's NAT never forgets your tunnel. Mobile carriers drop an idle mapping after 30–60 seconds; with no keepalive the first thing you do after a pause has nowhere to go, which is the "connected but dead for a minute" pattern exactly.
MTU and set it to 1280.PersistentKeepalive = 25 to the [Peer] section if it is
not already there.The app's default is 1280 when a config has no MTU line, so a phone that was imported from an older file is usually already safe — check before changing it, and leave 1280 in place if it is there.
MTU to 1280.PersistentKeepalive is
25.[Interface] section add or change the line to
MTU = 1280 (mobile tethering / hotspot), or MTU = 1420 on a
normal connection.[Peer] section has PersistentKeepalive = 25.MTU under Interface to 1280 (mobile) or
1420 (fixed line).PersistentKeepalive = 25 under Peer./etc/wireguard/ — the file you imported, e.g.
sudo nano /etc/wireguard/ymr.conf.MTU = 1280 to the [Interface] section.PersistentKeepalive = 25 is in the [Peer] section.sudo wg-quick down ymr && sudo wg-quick up ymr.Configs generated before that date carry no keepalive line at all. The private key in a config is delivered once, so an older config cannot be re-issued or re-rendered — editing the tunnel in the app is the only way to add it. That is the case the connection check on your dashboard flags for you, per device.
New devices get both settings from the portal: an
explicit MTU line chosen for the device class (1280 for a phone, 1420
otherwise) — overridable from the Advanced section when you add the device — and
PersistentKeepalive = 25.
The connection check on your dashboard measures, from this browser, on this connection: whether the request arrived through the tunnel, the round trip through it to our endpoint and how much that round trip varies, and how long a name takes to resolve. Those are the three signals a bad mobile link actually produces.
It cannot detect a wrong MTU from the browser, and no page can: TCP path-MTU problems are absorbed at our edge so HTTP never sees them. That is why the MTU is written into your config explicitly — it is prevented, not detected. It also cannot test anything before the tunnel is up, because this website is not the tunnel.
Still dropping after both settings? Reply to any message from us or write to info@ymrtech.com with the device name and what the connection check showed — that is enough for us to tell a link problem from a service one.