Pages Load but Uploads Stall on a VPN: Which Cause Wins
A size-dependent stall fits a path MTU fault, and also fits DNS, an application limit or a flapping tunnel. Four observations decide which one.
Pages load, the VPN reports connected, and a file upload freezes at the same point every time. Four explanations fit that description: a packet-size problem, a name-resolution problem, an application limit, and a tunnel that keeps resetting. Each of them can be ruled in or out by a different observation, so the decision is a matter of choosing the test rather than guessing the cause.
Four candidates and one shape
Start with the shape of the failure, because it eliminates most of the list before any tool is opened. A stall that happens at a consistent size is a size problem until proven otherwise. A stall that happens at random points is a loss or stability problem. A failure before the connection opens is a naming problem.
The fourth candidate is the application. Upload limits, request timeouts and proxy body-size caps produce failures that look like network faults from the browser, and they usually arrive as a rejection rather than a hang.
Write the observed shape down before testing anything. "Stops at roughly the same byte count, every time, with the tunnel up" is a much stronger starting point than "uploads do not work".
Then keep the path fixed while you test. Changing the exit, the protocol and the server at the same time produces a result you cannot attribute to any of them. One variable per run, and write it down.
Bisect the size before you touch policy
The cheapest discriminator is a probe that varies one number. Send do-not-fragment pings of increasing size to the destination, and upload a file you control to the same service, then compare where each one stops.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadThe first command reports whether a full-size packet survives the path at all. On a 1500-byte MTU the largest ICMP payload that does not fragment is 1472 bytes, and a tunnel takes more out of that budget before the inner packet begins. The second gives you a size and a duration for an application-level transfer, which is the number that actually matters.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Read the pair together. Probes that fail above a threshold and an upload that stops near the same threshold is a coherent story. Probes that all succeed while the upload stalls at a byte count the path clearly carries points at the application or the server, and no amount of MTU work will change it. That negative result is worth as much as a positive one. It removes the most expensive branch of the investigation.
Then check stability during the transfer, because a tunnel that rekeys in the middle of a large upload produces a failure that looks size-dependent without being one. The uptime reading is the cheapest way to rule that in.
Decide between a repair and a workaround
If the evidence points at size, there are two honest responses and one dishonest one. The honest ones are to restore path-MTU discovery by permitting the necessary ICMP feedback, or to clamp the advertised segment size so peers send smaller segments. The dishonest one is to lower an interface MTU to a value copied from a forum and never verify what it changed.
The choice depends on what you control. On a network you operate, allowing the ICMP messages is the cleaner fix because it keeps the mechanism working for every protocol. On a path you do not control, clamping is the practical option, and it should be applied narrowly rather than server-wide.
If the evidence points at the application, fix the application or its proxy configuration. A 413 response and a hung connection are different failures, and the second is usually a timeout somewhere in a chain that includes a proxy with its own limits.
Either way, keep the original values and retest after rolling back. A change that coincides with a working transfer is not evidence that the change caused it, and the ability to undo is what separates a diagnosis from a coincidence.
Record the decision so it survives the next incident
Four facts are enough: the observed failure shape, the probe results, the change you made, and the retest result. With those, the next person can tell whether the problem is the same one or a new one wearing the same symptom.
Note the path context as well, because an MTU finding is specific to a link. A laptop that works at home and fails at a hotel has two paths, and a fix applied to one of them says nothing about the other.
Finally, resist the summary that "the VPN broke uploads". The tunnel was present in both the working and the failing case; what changed was the size of the packet the path had to carry, or where the transfer was stopped. Naming the actual mechanism is what makes the note useful.