Classic ticket: "site works at office, not on 4G." You inspect application logs — nothing. TLS certificate valid. TTFB fine from monitoring. Then a phone test shows a page loading header, freezing on heavy image or JS bundle, timing out with no useful message.
Not always a front-end bug. Sometimes a packet too large for a tunnel, and a firewall swallowing ICMP needed for automatic resize.
MTU, fragmentation, and PMTUD in two minutes
MTU (Maximum Transmission Unit) is max IP packet size on a link — often 1500 bytes on Ethernet, less on VPN or mobile.
PMTUD (Path MTU Discovery) lets hosts discover usable size by receiving ICMP "Fragmentation Needed." If firewall blocks those ICMP, connection enters blackhole: small packets pass, large ones stall.
| Context | Typical MTU | Risk |
|---|---|---|
| Datacenter Ethernet | 1500 | Low |
| PPPoE / DSL | 1492 | Medium |
| WireGuard / OpenVPN | 1420–1450 | High if unclamped |
| Site-to-site GRE / IPsec | Variable | High |
A "fast" site in lab can fail on mobile production because network path, not code, limits packet size.
Symptoms suggesting MTU
Partial load (HTML yes, assets no). SSH or HTTPS OK for small requests, freeze on large transfers. Issue only via corporate VPN or certain ISPs. Light REST API OK, upload or download hangs.
Correlate where it breaks: client, VPN, CDN, load balancer, server.
Step-by-step diagnosis
Ping with Don't Fragment
ping -M do -s 1472 your-server.tld
Reduce -s until it passes. Useful size plus 28 bytes (IP/ICMP headers) ≈ path MTU.
Use mtr or tracepath with large sizes to spot dropping hop. Server-side, check ip link show on tunnel interfaces — explicit MTU too high is suspect. CDN/WAF: some edge-to-origin tunnels have their own MTU; origin behind site-to-site VPN is frequent case.
Durable fixes
MSS clamping on router or VPN server. Explicit MTU on tunnel interface (WireGuard: MTU = 1420 in config). Allow ICMP type 3 code 4 (fragmentation needed) on firewalls — often dropped "for security." tcp_mtu_probing on Linux as last resort.
Do not blindly lower public interface MTU without measuring — target faulty tunnel or link.
The summit: monitoring will not see the blackhole
Decide and move forward without blind spots
Reproduce from reported network (4G, client VPN, affected ISP) before touching application code. Test ping DF and mtr to locate faulty hop. Document MTU of every tunnel between you and host. Choose host with responsive network support via our comparator if issue persists on origin side.
Frequently asked questions
What is an MTU problem in practice?
Oversized packets plus filtered ICMP: hung connection without clear browser error. Small requests pass, large transfers fail silently.
Why does it appear only on some networks?
VPNs, tunnels, and mobile carriers reduce effective MTU. Without working PMTUD, large packets cannot traverse that specific path.
How do you confirm MTU blackhole?
ping -M do with decreasing sizes, mtr, tracepath — until identifying hop dropping oversized packets.
What to fix server or host side?
MSS clamp, explicit tunnel MTU, allow ICMP fragmentation needed, tcp_mtu_probing as last resort.
When a page "fails for no reason," ask: do large packets pass on this path? — not only whether the server responds.