Gluetun keeps refusing the connection after you set WIREGUARD_MTU
· Updated 31 July 2026 · SparkBox team
You followed the advice to set WIREGUARD_MTU=1320, then dropped it to 1280, and Gluetun still refuses to pass traffic. The reason is simple and slightly embarrassing: that particular MTU "ladder" was arithmetically wrong. Rung one asked you to set a value Gluetun was already using, so it did nothing at all.
Rather not hand-tune VPN packet sizes? SparkBox ships Gluetun with sane, tested defaults and skips the copy-pasted MTU folklore entirely. See the walkthrough →
The 10-second version: WIREGUARD_MTU=1320 is Gluetun v3.41.1's own default, so setting it does nothing. Read the startup log to confirm the MTU actually in effect, then, only if large packets are stalling, lower it to a value you've measured — not a round number you copied.
What "gluetun refused" usually means
Gluetun is a container that runs a VPN client (WireGuard or OpenVPN) and forces everything you route through it to go out over that tunnel. MTU ("maximum transmission unit") is the largest packet size, in bytes, that a link will carry in one piece. When a tunnel's MTU is set too high for the underlying network, big packets get dropped instead of delivered — connections open, then hang or time out. That looks like "refused" even though the handshake succeeded.
This is the class of problem MTU tuning is meant to fix. It is not the fix for a tunnel that never authenticates — if Gluetun never reaches your provider at all, MTU is a red herring (jump to the FAQ for that).
The real cause: a broken MTU ladder
An earlier build (v1.6.434) told users to try WIREGUARD_MTU=1320 first, then 1280 if that failed. Both rungs were wrong for arithmetic reasons.
Rung 1 (1320) is a no-op
1320 is Gluetun v3.41.1's own default MTU. Verified directly against the pinned image: on startup Gluetun prints its settings, and that dump reads MTU: 1320. Setting an environment variable to the value it already holds changes nothing. If your tunnel was refusing traffic before, it refuses it exactly the same way afterward — because the tunnel is byte-for-byte identical.
Gotcha: Because nothing visibly changes, people assume MTU "isn't the problem" and move on. In reality they never actually tested a different MTU — they re-set the default twice.
Rung 2 (1280) is a guess, not a measurement
1280 is a popular round number (it's the minimum MTU IPv6 is required to support), which is exactly why it gets copy-pasted into guides. But it does not correspond to your network path. The correct tunnel MTU is your path's usable size minus WireGuard's per-packet overhead. If 1280 happens to still be above what your path can carry, or needlessly far below it, the "ladder" either fails to fix the stall or quietly wrecks throughput. Either way you're guessing instead of solving.
The fix: confirm the real MTU, then measure before you lower it
Step 1 — Read what Gluetun is actually using
Don't trust the value you think you set. Read it back from the container's own startup summary:
docker logs <your-gluetun-container>Near the top you'll see a settings block. Find the WireGuard MTU line. If it says 1320 and you never changed it, you are on the stock default — setting WIREGUARD_MTU=1320 yourself was pointless. Now you know your real starting point.
Step 2 — Decide whether MTU is even your problem
MTU is worth tuning only if the tunnel connects but behaves like this:
- Small stuff works (a quick
ping, tiny web requests) but large downloads or page loads stall or time out. - Things work over one network and fail over another (for example a mobile hotspot vs. home fibre).
If Gluetun never establishes the tunnel at all, close this section — MTU can't be the cause. See the FAQ.
Step 3 — Measure your usable path size
From the host running Gluetun, probe how large a packet can travel to a public server without being fragmented. This is standard networking, not Gluetun-specific:
ping -M do -s 1400 1.1.1.1Here -M do means "don't fragment" and -s is the payload size in bytes. If you get "message too long" or 100% loss, the packet is too big — lower -s and try again (1372, 1352, and so on) until the pings succeed. The largest -s that gets replies, plus 28 bytes (the 20-byte IP header plus 8-byte ICMP header), is your usable path MTU.
Note: Some networks block ping entirely, which produces loss for reasons unrelated to size. If every size fails including tiny ones, ICMP is filtered and this method won't help you — skip to Step 4 and test by feel instead.
Step 4 — Set an MTU that reflects the measurement
WireGuard wraps each packet with its own overhead — roughly 60 bytes for IPv4 (20-byte outer IP header + 8-byte UDP header + 32 bytes of WireGuard framing). So a reasonable tunnel MTU is:
WIREGUARD_MTU = (usable path MTU from Step 3) - 60Put that number in your Gluetun environment, for example in a compose file:
environment:
- WIREGUARD_MTU=1360(1360 is only an illustration — use your figure.) Recreate the container so it re-reads the variable, then check docker logs again to confirm the new value appears in the settings dump. This time the number should differ from 1320, which means your change actually took.
Step 5 — If you can't measure, step down deliberately
When ICMP is blocked, lower the MTU in real steps below the 1320 default and test large transfers after each change: try 1280, then 1240, then 1200. The key difference from the old ladder is that you're now moving away from the default and watching for behaviour to change, instead of re-applying 1320 and expecting magic. Stop at the highest value where big downloads complete cleanly.
Don't go lower than you need. A too-small MTU works but fragments everything and drags throughput down. Once large transfers succeed reliably, nudge the value back up a step to reclaim speed and re-test.
Frequently asked
Why did setting WIREGUARD_MTU=1320 change nothing in Gluetun?
Because 1320 is already Gluetun's built-in default. On the pinned v3.41.1 image the startup settings dump literally prints MTU: 1320, so setting the same value is a no-op. Nothing about your tunnel changes, which is why the refusal persists.
How do I see what MTU Gluetun is actually using?
Read the container's startup log with docker logs <your-gluetun-container>. Near the top Gluetun prints a settings summary that includes the active WireGuard MTU line. Compare that number to whatever you thought you set.
Is 1280 the correct MTU to fix Gluetun refusing connections?
Not automatically. 1280 is a commonly copied round number but it doesn't correspond to any particular link. The right MTU is your path's usable size minus WireGuard's overhead, which you should measure rather than guess.
Is a refused Gluetun connection always an MTU problem?
No. MTU only explains cases where the tunnel connects but large packets stall or time out. If Gluetun never authenticates at all, check your provider keys, endpoint, and port before touching MTU — no MTU value will fix a handshake that never happens.
Skip the packet-size guesswork
SparkBox runs Gluetun with tested defaults so you don't inherit copy-pasted MTU ladders that set the value already in effect.
Questions, or did this not match your box?
Every guide here came from a real problem someone hit. If yours behaves differently, say so — that is how these get corrected, and how the fix gets prioritised.
We answer there rather than in a comment box, because that is where the people who have already solved it are.