MTU Discovery Tool

Your measurement

Both numbers are read server→client on this connection. Effective MSS is the payload — excluding IP and TCP headers — that this server can put in one segment toward you: the smaller of what your side permitted and what the path allows, less the TCP options in use. It is not your device's own MSS advertisement, and it does not yield your device's MTU. This path is a stand-in for the path to your own VPN server — the constraining hop is almost always your access link.

WireGuard MTU calculator

1. Run this test from your VPN server location (no VPN active) and note the path MTU.
2. Run it from your travel location (no VPN active) and note that path MTU.
3. Enter both below — set the result in your WireGuard config.
4. Activate the tunnel and re-run this test. The new reading is your inner path MTU and should match the calculator's prediction. This also reveals the negotiated inner MTU for auto-tuned tunnels like OpenVPN.

Which number goes in? Use the Path MTU from each card when it is shown. When a card reports a Demonstrated floor instead, use that — it is the largest packet the path was actually proven to carry, so sizing from it is conservative and the tunnel fits. Re-running from a different attachment point (hotel Wi-Fi, phone hotspot, home LAN) and comparing the results is how you find where the path narrows.

From a terminal or router

The best server-side reading comes from the VPN endpoint itself — SSH to your home router and run:

curl -s https://mtu.remotetohome.io        # add -4 or -6 to force a family
wget -qO- https://mtu.remotetohome.io      # BusyBox/OpenWrt routers without curl

Scripting? curl -s 'https://mtu4.remotetohome.io/?format=json' | jq '.path_mtu // .demonstrated_mtu' — that yields the route's path MTU when it was established and the demonstrated floor when it was not, which is the number you want for sizing either way. Use jq '{converged, path_mtu, demonstrated_mtu, reason}' when you need to know which of the two you got. Reading .path_mtu alone is fine but hands you a bare null with no explanation on a narrowed path (.reason carries it).

Verify it yourself (manual DF ping)

From any machine with a real ping, probe with the Don't Fragment bit set. Largest payload that succeeds + 28 = your IPv4 path MTU.

ping -M do -s 1472 -c 3 8.8.8.8   # 1472 + 28 = 1500
ping -M do -s 1464 -c 3 8.8.8.8   # 1464 + 28 = 1492 (PPPoE-typical)

If even tiny DF pings fail, the target filters ICMP — that is filtering, not your link's MTU.