Path MTU Discovery

📏

mtu

An MTU black hole is why a connection can look perfectly healthy and still hang. Small packets get through, so DNS resolves, TCP connects and TLS negotiates. Then the first full-size data packet vanishes with no error and the transfer stalls forever. Pages load halfway. VPNs connect but move no traffic.

Input

Target: any host or IP (for example 1.1.1.1, 8.8.8.8, or example.com).
Pick a target that answers ICMP echo. Public resolvers are reliable; many web servers are not.

Options

Mode — Auto (default) searches for the path MTU. Well-known values are probed first (9216, 9000, 4000, 1500, 1492, 1480, 1460, 1400, 1280, 576), then the search narrows to the exact byte. Because MTU is monotonic the ladder is bisected rather than walked, so a full search costs roughly eight probes.
Mode — Manual sends a single probe at one size you choose, the equivalent of ping -D -s. It reports not just pass or fail but which failure: a router reporting Fragmentation Needed, or a silent drop.
IP Version: Auto, IPv4, or IPv6. Auto prefers IPv4 because more hosts answer ICMPv4 echo.
Size (Manual mode) is the MTU — the total IP packet size — not the ICMP payload. The derived payload is shown beneath the field, so MTU 1500 = 1472 bytes payload + 8 ICMP + 20 IP. That 1472 is the number ping -s would take.
Locate the constriction (Auto mode) walks the route after measuring, to find which hop stops forwarding full-size packets. Adds one probe per hop.

Output

Local link: medium (Wi-Fi, Ethernet, Cellular), interface name, and link MTU. Any active VPN tunnel is listed with its own MTU.
Result: the measured path MTU, the matching well-known value if there is one (1492 is reported as PPPoE), the derived payload, and the next-hop MTU if a router reported one.
Verdict — the part that matters: No constraint; Reduced MTU, working correctly; MTU black hole; or Inconclusive when the target blocks ICMP entirely.
Where it drops, when the per-hop sweep runs: the first hop that refuses to forward a full-size packet.
Tunnel planning: safe inner MTU for WireGuard, IPsec, OpenVPN, L2TP/IPsec, GRE, and PPPoE at the measured path MTU.
Probes: every size tried and what came back, in order.

Tips

A reduced MTU is not automatically a problem. If routers report it, path MTU discovery is doing its job. Only the black-hole verdict needs fixing.
Fix a black hole at the router, not on this device. Enable MSS clamping, or remove a double-NAT layer. Lowering this device's MTU only helps this device.
TCP often survives; UDP does not. Most PPPoE routers rewrite the TCP handshake (MSS clamping) so browsing works even with a mismatch. There is no equivalent for QUIC/HTTP3, WireGuard or IPsec, which is why "the web is fine but my VPN is broken" is the classic symptom.
Double NAT makes black holes more likely. The ICMP that reports the smaller MTU is addressed to whichever NAT last rewrote the packet, and every extra NAT layer is another chance for it to be lost on the way back.
Jumbo frames need a wired link. The search is capped at what your interface can actually emit, so on Wi-Fi (1500) jumbo sizes are skipped and the reason is stated in the output. On an Ethernet-connected Apple TV, or an iPad with a USB-C Ethernet adapter negotiating jumbo, those sizes are probed automatically.
A VPN lowers the ceiling. When a tunnel is up, its MTU governs what the device can emit, and it is reported alongside the physical link.
Pair it with Traceroute: Traceroute shows where the path goes, Path MTU Discovery shows how much it will carry.

Deeplink

netdebug://mtu?target=1.1.1.1&family=v4&hops=true
netdebug://mtu?target=1.1.1.1&mode=manual&size=1500

A size below the family minimum (68 for IPv4, 1280 for IPv6) is ignored. A size above your link MTU is accepted — the resulting local rejection is itself a useful result.

Tip: in the app, open the Export menu (the share icon) on this screen and choose Copy Deeplink to copy this link as a Universal Link with your current target and options already filled in.