MTU on Windows 11: The Three-Letter Setting Nobody Touches Until Their Games Start Randomly Disconnecting

1. What MTU Actually Is, Without the Textbook Language

MTU stands for Maximum Transmission Unit, and here's the plain version: it's the biggest single chunk of data your network connection is willing to send in one piece before it has to be split up. Think of it like a delivery truck that can only carry boxes up to a certain size. Anything bigger than that has to be broken down into smaller boxes first, shipped separately, then reassembled at the other end. That size limit — for most home internet connections — is 1500 bytes. It's been the standard for Ethernet since basically forever, which is exactly why almost nobody ever has a reason to think about it.

The problem shows up when something in the path between you and wherever your data is going has a smaller truck. A VPN, for instance. Or a PPPoE-based connection, which a lot of DSL and fiber providers still use. Both of those add a bit of extra wrapping around your data — headers, encryption overhead, tunnel information — which eats into that 1500-byte limit without you asking for it or seeing it happen.

2. Why the Correct Value Actually Matters

Here's where it actually bites you. If your device keeps sending 1500-byte packets, but somewhere along the route the real limit has effectively shrunk to, say, 1400, one of two things happens. Either the oversized packet gets fragmented — split into pieces, sent separately, reassembled at the destination, which adds overhead and slows things down — or, if something in the path has fragmentation blocked (which happens more often than you'd expect, especially with real-time traffic), the packet just gets silently dropped. Not slowed down. Dropped. Gone. And your device usually has no idea why, so it just retries, which looks to you like lag, stuttering, or a connection that randomly drops for no visible reason.

3. The Gaming Example That Makes This Click

Here's a real, specific scenario, because this stops being abstract the moment you've lived through it. Say you're connected to a VPN — maybe for privacy, maybe because a friend is hosting a private game session through one, maybe your work requires it and you forgot to disconnect before booting up a match. VPNs wrap your regular traffic inside an extra layer of encryption, and that wrapping takes up space. Your connection's effective MTU might drop from the usual 1500 down to something like 1400 or lower, depending on the VPN protocol.

Online games, especially fast-paced ones, rely heavily on small, frequent UDP packets to keep your position, actions, and the game state in sync in real time. A lot of that traffic gets sent with something called the "don't fragment" flag turned on, specifically because fragmenting real-time data adds delay nobody wants in a competitive match. Combine that flag with an MTU mismatch, and here's what actually happens: instead of your game traffic getting fragmented and slowed down, it just gets dropped outright by whatever network device first notices the packet doesn't fit. From inside the game, this looks exactly like classic bad connection symptoms — rubber-banding where your character snaps backward, sudden disconnects mid-match, failure to even join a lobby in the first place, or a connection that times out specifically only while the VPN is active and works fine the moment it's turned off.

Lower the MTU on the affected network adapter to match what the VPN tunnel can actually carry, and in a genuinely large share of these cases, the exact same symptoms just disappear. Nothing about your internet speed changed. The packets just stopped being too big for the road they were traveling on.

4. Checking and Changing MTU on Windows 11

Windows 11 makes this fully accessible through the command line, no third-party tools needed.

Checking your current MTU

1. Open Command Prompt as administrator — search "cmd" in the Start menu, right-click, and choose Run as administrator.
2. Type netsh interface ipv4 show subinterfaces and press Enter.
3. You'll see a list of your network interfaces (Wi-Fi, Ethernet, and so on) along with the current MTU value for each one — 1500 is the typical default.

Changing it, once you know the right value

1. In the same elevated Command Prompt, type: netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
2. Replace "Ethernet" with the exact interface name shown in the previous step — it might be "Wi-Fi" instead, depending on how you're connected.
3. Replace 1400 with your actual target value once you've determined it using the testing method below.
4. Restart the network adapter, or reboot the PC, for the change to fully take effect everywhere it needs to.

5. iOS, Android, and Your Home Router

iOS (iPhone and iPad)

Worth being upfront here: standard iOS doesn't offer a simple, general MTU setting sitting in the regular Settings app the way Windows does. Apple keeps this managed automatically for normal Wi-Fi and cellular connections. If you genuinely need to adjust MTU on an iPhone, it's typically done through a specific VPN app's internal settings, since some VPN clients expose their own MTU field for the tunnel they create, or through a configuration profile pushed by a company's device management system. There isn't a native "just go here and type a number" path for the average user, and any tutorial claiming otherwise is likely describing an outdated version of iOS or a jailbroken setup.

Android

Android is a similar story on most stock devices — there's no universal MTU field sitting in standard Wi-Fi or mobile data settings. Some Android phones expose MTU adjustment specifically within the settings of individual VPN connections you've configured, under Settings > Network & internet > VPN, tap the gear icon on a specific saved VPN profile. Beyond that, adjusting MTU system-wide on Android generally requires either a rooted device using a terminal app, or relying on your router and VPN provider to hand out a correctly sized MTU automatically, which is genuinely the more common and more reliable fix for phones and tablets anyway.

Home Router

This is where MTU adjustments are most commonly made, especially for whole-household fixes rather than tweaking every device individually.

1. Log into your router's admin page, usually by typing its IP address (commonly something like 192.168.1.1 or 192.168.0.1) into a browser.
2. Look for a section labeled WAN Setup, Internet Settings, or occasionally tucked under Advanced settings — the exact label varies quite a bit by router brand and model.
3. If your connection type is PPPoE, you'll frequently find an MTU field there specifically, often already set to 1492 by default to account for PPPoE's overhead.
4. Adjust the value, save, and reboot the router for the new setting to apply across every device connecting through it.

6. Finding the Actual Right Number for Your Connection

Guessing a number and hoping is not the move here — there's a genuinely reliable way to find your exact correct MTU, and it takes about two minutes.

1. Open an elevated Command Prompt
   Same as before — search "cmd," right-click, Run as administrator.
2. Run a ping test with the "don't fragment" flag
   Type: ping -f -l 1472 8.8.8.8 — this sends a packet of 1472 bytes and refuses to let it fragment along the way.
3. Read the result
   If it succeeds cleanly, your connection handles at least 1472 bytes of payload. If you instead see a message about needing to fragment the packet, your path can't handle that size.
4. Narrow it down if it fails
   Lower the number in the command — try 1400, then adjust up or down from there — until you find the largest payload size that succeeds without a fragmentation warning.
5. Add exactly 28 bytes to that final working number
   This is the step people get wrong most often, so it's worth spelling out precisely: the -l value in the ping command only measures the ICMP payload — it does not include the packet headers that ride along with every single packet regardless of what you're sending. Those headers are 20 bytes for the IPv4 header plus 8 bytes for the ICMP header, which is exactly 28 bytes, every time, on every standard IPv4 connection. So if your largest successful payload was 1472, your true MTU to set on the adapter isn't 1472 — it's 1472 + 28, which is 1500. If your largest successful payload was 1400, your real MTU value is 1428, not 1400. Skipping this addition is the single most common reason people end up setting an MTU that's 28 bytes smaller than it actually needs to be.

7. Automating the Check With PowerShell

Running netsh commands by hand works fine for a one-off fix, but if you're checking MTU across several interfaces regularly, troubleshooting a fleet of machines, or just want a cleaner output than parsing raw netsh text, PowerShell handles this more directly. Both scripts below are plain text — save either one with a .ps1 extension and run it locally.

Script 1: List the current MTU of every active interface

# Get-CurrentMTU.ps1
# Lists the current MTU value for every active IPv4 network interface.
#
# HOW TO RUN:
#   powershell -ExecutionPolicy Bypass -File .\Get-CurrentMTU.ps1

Get-NetIPInterface -AddressFamily IPv4 |
    Where-Object { $_.ConnectionState -eq "Connected" } |
    Select-Object InterfaceAlias, InterfaceIndex, NlMtu, ConnectionState |
    Sort-Object InterfaceAlias |
    Format-Table -AutoSize

Write-Host ""
Write-Host "NlMtu is the current MTU in bytes for each listed interface." -ForegroundColor Cyan

Running this prints a clean table with each connected interface's name and its current MTU under the NlMtu column — the same information netsh interface ipv4 show subinterfaces gives you, just easier to read and easier to pipe into other scripts or logs if you're checking multiple machines.

Script 2: Automatically find the optimal MTU via Path MTU testing

This one goes further than a manual ping test — it uses .NET's native ping class directly, which allows explicit control over the "don't fragment" flag the same way the manual ping -f -l method does, but automates the entire binary search and applies the 28-byte correction for you at the end.

# Find-OptimalMTU.ps1
# Automatically determines the true optimal MTU to a target host
# using ICMP with the Don't Fragment flag set, then applies the
# standard 28-byte IPv4+ICMP header correction to the result.
#
# HOW TO RUN:
#   powershell -ExecutionPolicy Bypass -File .\Find-OptimalMTU.ps1 -TargetHost 8.8.8.8

param(
    [string]$TargetHost = "8.8.8.8",
    [int]$StartSize = 1472,
    [int]$MinSize = 500
)

$HeaderOverhead = 28
$Ping = New-Object System.Net.NetworkInformation.Ping
$Options = New-Object System.Net.NetworkInformation.PingOptions
$Options.DontFragment = $true

$Size = $StartSize
$LastSuccess = 0

Write-Host "Testing path to $TargetHost with Don't Fragment set..." -ForegroundColor Cyan

while ($Size -ge $MinSize) {
    $Buffer = New-Object byte[] $Size
    $Reply = $Ping.Send($TargetHost, 2000, $Buffer, $Options)

    if ($Reply.Status -eq "Success") {
        $LastSuccess = $Size
        Write-Host "  Payload $Size bytes: OK" -ForegroundColor Green
        break
    } else {
        Write-Host "  Payload $Size bytes: FAILED ($($Reply.Status))" -ForegroundColor DarkGray
        $Size = $Size - 20
    }
}

if ($LastSuccess -gt 0) {
    $TrueMTU = $LastSuccess + $HeaderOverhead
    Write-Host ""
    Write-Host "Largest successful payload: $LastSuccess bytes" -ForegroundColor Yellow
    Write-Host "Header overhead added:      $HeaderOverhead bytes (20 IPv4 + 8 ICMP)" -ForegroundColor Yellow
    Write-Host "Recommended MTU to set:     $TrueMTU bytes" -ForegroundColor Green
    Write-Host ""
    Write-Host "Apply it with:" -ForegroundColor Cyan
    Write-Host "  netsh interface ipv4 set subinterface `"Ethernet`" mtu=$TrueMTU store=persistent"
} else {
    Write-Host "No successful reply found down to $MinSize bytes. Check connectivity to $TargetHost." -ForegroundColor Red
}

This starts at a 1472-byte payload and steps downward in 20-byte increments until it finds a size the path accepts without needing to fragment, then prints the corrected true MTU along with the exact netsh command to apply it — no manual arithmetic required, and no guessing whether you remembered to add the 28 bytes.

8. MTU by Protocol: A Reference Table for Deeper Work

For anyone troubleshooting this professionally rather than fixing a single home connection, the 1500/1492 numbers mentioned earlier are really just the two most common cases. Different tunneling and encapsulation methods each carve out their own chunk of overhead, and knowing the typical range for each saves a lot of manual binary-searching.

These are typical starting points, not guarantees — the only way to know your actual figure for a given path is the ping test or the automated script above, since real-world values shift depending on your specific provider, VPN configuration, and everything in between. For anyone documenting this at a protocol level, RFC 1191 defines the Path MTU Discovery mechanism referenced throughout this piece, and RFC 894 defines the standard 1500-byte Ethernet frame size that everything else here is measured against.

MTU isn't a setting that needs constant fiddling once it's right — you set it once for the specific circumstance causing trouble, whether that's a VPN, a PPPoE line, or a router that's quietly been misconfigured since the day it was installed, and then you leave it alone.