Starlink MTU size: path MTU measured at 1500 bytes

1500-byte packets reached all three test hosts, over IPv4 and IPv6

A link's maximum transmission unit (MTU) is the largest packet it carries in one piece, and a path's MTU is the smallest link MTU along it. RFC 8201 puts it as "the minimum link MTU of all the links in a path between a source node and a destination node" (section 2, checked October 2026).

The test ran in October 2026 from a wired computer on the home network, on a home Starlink connection, in two reads a few minutes apart. Every route to the test hosts left through the wired interface, so no VPN, exit node or tunnel carried the traffic. In each read, for each host, over IPv4 and over IPv6, tracepath ran to its end. Then three pings sized to make 1500-byte packets went out with don't-fragment set and a 2-second reply timeout. Three more, sized to make 1501-byte packets, were refused by the computer before they were sent.

The three hosts are public machines that their operators offer for network tests (each page checked October 2026):

• scanme.nmap.org, which the Nmap project set up so people can "test and make sure that their Nmap installation (or Internet connection) is working properly";
• speedtest.newark.linode.com, whose home page is titled "Linode, now Akamai, Speedtest";
• proof.ovh.net, an OVHcloud network speed-test host.

Path MTU discovery starts from the MTU of the sender's first link. Over IPv4 the sender sets the Don't Fragment (DF) bit, and a router that can't forward such a packet whole discards it and returns an ICMP message meaning "fragmentation needed and DF set" (RFC 1191, section 2, checked October 2026). Over IPv6, a router that can't forward a packet because it is larger than the next link's MTU must return a Packet Too Big message (RFC 4443, section 3.2, checked October 2026). Either way, the sender lowers its estimate (RFC 8201, section 3). tracepath traces a path "discovering MTU along this path" and shows the path MTU where it changes (iputils 20250605, checked October 2026). In every trace here it stayed at 1500 from start to end, and no ping drew a "too big" message, so no hop reported a smaller MTU.

The pings check the same thing from end to end. Each 1500-byte ping reached its host and its reply came back. That covers hops that don't answer tracepath, which only the pings test. The path also starts at the home router, so the router's own settings are part of the result: nothing on these paths, the home router and Starlink's network included, cut packets below 1500 bytes at the time.

Over IPv4, the traces began with the same kinds of hops as the trace in the guide to self-hosting without a public IPv4 address, which this page doesn't repeat.

A 1472-byte ping is a 1500-byte IPv4 packet

ping's -s option sets the number of data bytes, and ICMP adds an 8-byte header to them (ping(8), iputils 20250605, checked October 2026). An ICMPv6 echo message also has 8 bytes before its data: type, code, checksum, identifier and sequence number (RFC 4443, section 4.1, checked October 2026). A minimum IPv4 header is 20 bytes, and an IPv6 header is 20 bytes longer, 40 (RFC 8200, section 8.3, checked October 2026).

A ping with don't-fragment set that gets replies with 1472 bytes of data over IPv4 means a 1500-byte packet crossed the path. 1472 is the ping's payload, and the MTU is the whole packet.

Over IPv6, routers never split a packet: "fragmentation in IPv6 is performed only by source nodes", RFC 8200 says (section 4.5). So a 1500-byte IPv6 ping either crosses whole or meets a router that must answer with a Packet Too Big message (RFC 4443, section 3.2).

To repeat the test on Linux with iputils, run these commands, shown here with one of the three hosts:

tracepath -4 -n scanme.nmap.org
ping -4 -M do -n -c 3 -W 2 -s 1472 scanme.nmap.org
tracepath -6 -n scanme.nmap.org
ping -6 -M do -n -c 3 -W 2 -s 1452 scanme.nmap.org

-M do turns don't-fragment on, -c 3 sends three pings and -W 2 sets a 2-second reply timeout (ping(8)). The Nmap page asks visitors to go easy on its host: "A few scans in a day is fine". Other systems' ping commands take different options, and this page doesn't cover them.

1501-byte packets never left the computer

On a computer whose own link MTU is 1500 bytes, a ping with -M do and 1473 bytes of data (IPv4) or 1453 (IPv6) that fails at once, with a local error saying the message is too long for an MTU of 1500, was refused by that computer. The failure says nothing about your provider.

If the error names an MTU smaller than 1500, that reading doesn't apply. The computer is checking the packet against a lower limit than its link's, and that limit can come from the path: a sender lowers its estimate after a "too big" message from a router (RFC 1191, section 2; RFC 8201, section 3).

Tunnel tools count WireGuard's headers as 80 bytes

In the Linux kernel, a new WireGuard interface gets dev->mtu = ETH_DATA_LEN - overhead (device.c, Linux 6.18). ETH_DATA_LEN is 1500, Ethernet's maximum payload (if_ether.h). The overhead is WireGuard's smallest data message, plus an 8-byte UDP header (RFC 768) and the larger of the IPv6 and IPv4 headers, IPv6's 40 (RFC 8200). That message is 32 bytes: a 4-byte type, a 4-byte key index, an 8-byte counter and a 16-byte authentication tag (messages.h, with the tag's size in chacha20poly1305.h). So the overhead is 80 bytes, and the interface starts at 1420. All checked October 2026.

The tag comes after the encrypted data: in RFC 8439's AEAD (authenticated encryption with associated data), the output is the ciphertext, then the tag (section 2.8, checked October 2026).

wg-quick on Linux uses the MTU line of the interface's config when there is one. Without it, the script reads the MTU of the routes to the peers' endpoints, falls back to the default route's and then to 1500, and sets the interface 80 bytes lower (linux.bash, wireguard-tools v1.0.20250521, checked October 2026). On a 1500-byte route, that is 1420.

Tailscale counts the same 80 bytes for the worst case, an IPv6 outer header. Its list is a "20-byte IPv4 header or 40-byte IPv6 header", an 8-byte UDP header, a 4-byte type, a 4-byte key index, an 8-byte nonce and a 16-byte authentication tag (mtu.go, Tailscale v1.90.0, checked October 2026). In this file the size doesn't depend on the link: DefaultTUNMTU(), which the file uses to set the interface's MTU, returns 1280, its default "safe" MTU, unless the debug setting TS_DEBUG_MTU gives another size. It returns 1280 even with TS_DEBUG_ENABLE_PMTUD, the debug setting for path MTU probing, turned on. With the 80 bytes added, 1280 is 1360 bytes on the wire. 1280 is also the smallest MTU that IPv6 allows on any link (RFC 8200, section 5).

The paths in this test carried 1500-byte packets. No tunnel ran over them, so this page doesn't show what a tunnel's packets did.

When a packet is too big for a link and the "too big" message never reaches the sender, RFC 8201 describes connections that "complete the TCP three-way handshake correctly but then hang when data is transferred" (section 1). This test didn't look for that.

Not tested here

• A tunnel's MTU over this connection, for WireGuard, Tailscale or a work VPN. Whether changing an MTU fixes a VPN problem is untested too.
• A maximum or a default. Nothing above 1500 bytes could leave the test computer, so this page shows no maximum. Starlink's own pages on MTU haven't been read for this page, so it shows no default either.
• Wi-Fi. Both reads ran over a wired link.
• Other connections and other times. The two reads were a few minutes apart, and a path's MTU "may change over time, due to changes in the routing topology" (RFC 8201, section 3).

See how this fits with the other home tests, for a homelab.