Where is the MTU setting on my router?

By Dmytro Tishchenko · Updated 2026-09-23

You measured the value — now it has to go somewhere. On almost every consumer box the MTU field sits in the WAN or Internet section, never under Wi-Fi, and it is a single text field you overwrite. The table below gives the admin address and the exact path on the five boxes providers hand out most. The rest of this page is the part the forum threads skip: which number belongs in the field, what breaks when it is wrong in each direction, and how to confirm the change actually took.

Finding the field on your own box

1. Get into the admin page. The address and the default login are printed on the sticker underneath the router. If the sticker is gone, the address is your default gateway — NetDiag+ shows it as the router row it pings before everything else, and every desktop OS lists it in the settings of the active connection.
2. Look under WAN or Internet, not under Wi-Fi. MTU belongs to the connection your router makes to the provider, so it lives in the section that configures that connection — the table below has the exact path on Huawei, ZTE, TP-Link, Zyxel and Nokia firmware. Where the WAN is split into several profiles, edit the profile that actually carries internet traffic, not the management profile the provider uses for remote support.
3. Write the old value down, then save and let the link come back up. MTU is negotiated when the connection is established, so a new value only applies after the WAN reconnects. Most firmware does that for you when you press Save or Apply; if yours does not, reboot the router. The old number is what you put back if this turns out not to be your problem.

Menu names vary by model and firmware version. On some firmware the field only becomes editable after the connection type is switched from automatic to manual. Most consumer routers only accept values between 1280 and 1500 — 1280 is the minimum MTU required for IPv6.

Free · 31 tools · one-time purchase · no subscription

Which number belongs in the field

There is no universally correct MTU, because the number is 1500 minus whatever your provider wraps around every packet. What gets wrapped depends on how the line is delivered, which is why a value that fixed a neighbour’s connection can quietly cost you throughput on yours.

• Plain DHCP over Ethernet, cable or fibre. Nothing is wrapped, the full 1500 applies, and usually there is nothing here to fix. If large packets still vanish on a 1500 line, the narrow point is somewhere further along the path and not in this field — which is an argument for measuring rather than experimenting.
• PPPoE, still the norm on DSL and on plenty of fibre. The session header costs 8 bytes, so the usable MTU is 1492. Firmware that knows it is dialling PPPoE normally sets this itself; firmware left on 1500 after somebody changed the connection type will not, and that is one of the most common causes of a connection that works for everything small and stalls on everything large.
• DS-Lite, CGNAT and other carrier tunnels. Your IPv4 traffic is carried inside an IPv6 packet, so the encapsulation eats into the 1500 and the exact cost depends on how the carrier built it. This is the case where a number copied off a forum is worthless: the only honest way to get it is to measure the path end to end and read what came back.
• A VPN on top of any of the above. The tunnel takes its own share — roughly 1420 for WireGuard over IPv4, around 1400 for a typical OpenVPN — but that number goes into the VPN client, not into the router. The router still carries the outer packet at the line’s own MTU.

Too low and too high fail differently

Too low is the safe mistake, and it is not free. Every packet carries the same IP and transport headers whether it holds a lot of payload or a little, so a smaller MTU means more packets, more header overhead and more per-packet work for every device on the path. Drop to 1280 on a link that would happily carry 1492 and you lose throughput on every transfer and add load to a router that was already the slowest thing in the house. Nothing looks broken; the line is simply slower than it should be, permanently, and nobody ever goes back to check.

Too high is the mistake that makes a connection look haunted. Everything small works — ping replies, DNS, the router’s own admin page — while anything that fills a packet stalls. TCP usually survives it: an oversized segment is dropped, the router that dropped it returns an ICMP fragmentation-needed message, and the sender shrinks. When a firewall along the way swallows that ICMP message, the sender never learns, and the transfer hangs at the same point every time. UDP has no such recovery. Large UDP packets are simply gone, which is why VPN handshakes stall halfway through, QUIC sites load their first bytes and then stop, and a video call connects with audio and never shows a picture. Packets that are merely fragmented rather than dropped are cheaper but not free: each fragment is another chance to lose the whole packet, and one lost fragment discards everything that was sent with it.

How to tell it worked

1. Re-measure the path instead of trusting the field. Saving a value proves only that the router accepted it. Run the Path MTU measurement again from a device on that network: the recommended value should now agree with what you typed, and the probe rows should stay green all the way up to it rather than turning orange below it.
2. Retry the exact thing that was broken. If large UDP was the symptom, the symptom is the test: bring the VPN tunnel up, open the site that used to hang, start the call that carried no picture. A change that does not fix what sent you here is the wrong change, and the old number goes back in the field.
3. Check that you did not pay for it. Run a speed test and a latency check before and after. A correct MTU costs nothing measurable; a value set far too low shows up as throughput that never recovers. If the numbers dropped, raise the field toward the measured maximum rather than leaving a round number in it because it felt safe.

If the field is greyed out or missing

Many provider-supplied boxes lock the MTU field, or hide the whole WAN section behind a support account. That is deliberate rather than broken: the provider manages the line remotely and does not want the connection profile edited. Four ways round it, in rough order of effort. Set the MTU on the device itself — macOS, Windows and Linux all expose it in the network settings of the adapter, and it is the right fix when only one machine is affected. Set it in your VPN client instead (WireGuard: MTU, OpenVPN: tun-mtu), which is the right fix when the tunnel is what breaks. Ask the provider: the value is one field in their provisioning system and support can often change it remotely within minutes, especially if you can tell them the number you measured and name what fails without it. And the heavy-handed option, if none of that lands: put the box in bridge mode and run your own router behind it, which moves the whole WAN configuration, MTU included, onto hardware you control.

iOS and Android do not expose an MTU setting at all, so a phone that struggles behind a locked router can only be helped in its VPN client or by the provider. Measuring, though, works from the phone either way — a measurement needs permission from nobody.

Questions people actually ask

All of this assumes you already have a number to type. If you do not, that is one measurement away. Next: measure your real Path MTU on iPhone →