A server responds to ping, but the browser keeps loading. SSH login works, yet a file download stalls. After connecting through a VPN, only certain websites stop opening. These symptoms make path MTU worth investigating, but “ping works and the website does not” is not enough to identify the cause.
An ordinary ping checks ICMP Echo reachability. It does not verify TCP port 443, a TLS handshake, or the HTTP service. First determine where the request stops. Then compare packet sizes, IPv4 and IPv6 behavior, and connection information to assess whether a path MTU black hole is involved. Setting every interface to an arbitrary lower MTU can hide the underlying fault and may disrupt existing connections.
1. When should you suspect an MTU problem?
Move MTU checks higher on the list when several of these clues appear together:
Small requests usually work, while larger responses or file transfers repeatedly stall.
TCP connects, but the TLS handshake or subsequent transfer stops progressing.
The problem occurs only through a VPN, tunnel, or particular outbound path, and disappears on another network.
The same service works over IPv4 but fails over IPv6, or vice versa.
None of these clues is conclusive by itself. Port filtering, TLS configuration, an overloaded origin, proxy restrictions, and ordinary packet loss can cause similar symptoms. If a request receives an HTTP 403, 404, or 500 response, it has at least reached a service capable of returning HTTP. Investigate that response first instead of immediately attributing it to MTU.
RFC 2923 describes a characteristic PMTUD black hole: small packets and interactive connections work, while bulk transfers fail when larger packets are sent.[1]
2. MTU, path MTU, and TCP MSS are different limits
MTU is the IP packet size limit associated with an interface or link. On Linux, ip link is a useful starting point for checking interface configuration. A local interface MTU of 1500 does not establish that the entire path supports 1500-byte packets.
Path MTU, or PMTU, is constrained by smaller link MTUs along the route. Tunnel encapsulation adds outer-packet overhead. Unless the underlying network can carry a correspondingly larger packet, less space remains for the inner packet.
TCP MSS describes the amount of TCP data a segment can carry, excluding the IP and TCP headers. With basic headers alone, common estimates are MTU minus 40 for IPv4 and MTU minus 60 for IPv6. Actual transmission must also account for options, extension headers, and encapsulation overhead. These differences are not universal configuration formulas.
The MSS advertised during a TCP handshake is not a measurement of the complete path. The endpoints' advertised capabilities may not reflect a smaller intermediate tunnel or link.[1][2][3]
3. How does a path MTU black hole stall a website?
For IPv4, when a packet has the Don't Fragment (DF) flag set and is too large for the next-hop link, the router should return an ICMP “fragmentation needed and DF set” message. This is ICMP Type 3, Code 4, and provides feedback the sender can use to adjust packet size.[2]
IPv6 routers do not fragment packets they forward. If a packet exceeds the forwarding link's MTU, an ICMPv6 Packet Too Big message is needed to inform the sender.[3]
If oversized packets are dropped and the relevant feedback is also blocked by a firewall or intermediate device, the sender may keep retransmitting packets that cannot pass. Small handshake packets get through, but larger data packets make no progress. The connection appears established, yet the transfer hangs.
Feedback can be lost on the return path as well. Checking only the application server's inbound rules is not sufficient: examine the relevant outbound, firewall, tunnel-boundary, and cloud-network policies too.[1][2][3]
4. Find out where HTTPS stops
The following commands are intended for Linux. Replace example.com and the example IP address with a destination you are authorized to test. These addresses and commands are illustrative, not measurements from a CloudFlew test environment.
curl -4 -v --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/ curl -6 -v --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/
Check whether the output stops during name resolution, TCP connection establishment, the TLS handshake, or response transfer. An IPv4/IPv6 comparison is meaningful only when the destination has the corresponding address records and the testing host has usable connectivity for that address family.
To isolate DNS address selection, specify a destination address while retaining the hostname and normal TLS certificate verification:
curl -v --resolve example.com:443:203.0.113.10 --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/
203.0.113.10 is a documentation address and must be replaced. Disabling certificate verification does not demonstrate that TLS is working correctly. For a CDN or proxy service, also confirm which endpoint the fixed-address request reaches. A test that bypasses the CDN does not validate the original path.[7]
5. Compare packet sizes for MTU clues
Start by examining local interfaces and the route to the destination:
ip link show ip route get 203.0.113.10
With Linux iputils ping, use a small, bounded set of IPv4 probes:
ping -4 -c 4 -W 2 -M do -s 1472 203.0.113.10 ping -4 -c 4 -W 2 -M do -s 1400 203.0.113.10 ping -4 -c 4 -W 2 -M do -s 1200 203.0.113.10
-s specifies the ICMP data length, not the complete IP packet length.
A 1472-byte payload corresponds to a 1500-byte IP packet only with a 20-byte IPv4 header and an 8-byte ICMP header.
-M do selects the Don't Fragment strategy but remains subject to the kernel's PMTU checks. An oversized packet may be rejected locally rather than sent to an intermediate router.[4]
Repeated failure of larger probes, stable success with smaller ones, and a matching HTTPS failure on the same path provide additional evidence for the MTU hypothesis. A local “message too long” error should be interpreted alongside interface and route information. A timeout alone can also reflect Echo filtering or rate limiting.
One successful probe does not precisely characterize every business connection. ICMP and TCP may follow different load-balanced paths, and the forward and return routes may differ. IPv6 also has a different basic header size: do not reuse 1472 as the payload for a 1500-byte IPv6 test packet.
6. Cross-check with tracepath and TCP connection information
tracepath can provide route and PMTU clues. It uses UDP probes and generally does not require superuser privileges:
tracepath -4 example.com tracepath -6 example.com ss -tin dst 203.0.113.10
Missing tracepath replies do not prove that the corresponding hop has failed. Filtering and insufficient information in returned messages can limit what the result tells you.[5]
Use ss output to help inspect retransmissions and connection progress. Depending on the kernel, tool version, and connection state, fields such as pmtu and mss may be available. Observe the connection while the transfer is stalled rather than relying on a single screenshot taken when traffic is healthy.
If the evidence remains unclear, use short, narrowly scoped packet captures at authorized observation points on both sides of the path. Check whether larger packets are repeatedly retransmitted and whether the sender receives the relevant ICMP or Packet Too Big feedback. Because that feedback may come from an intermediate router, capture filters must not be limited to TCP data exchanged directly between the client and server.
Local captures can also be affected by segmentation or aggregation offload. A large packet visible in a host capture does not, by itself, prove that an equally large IP packet was transmitted on the wire. Captures may contain addresses and application data; limit collection and handle the files according to your organization's rules.
7. Choose a fix that matches the evidence
Align interface and tunnel MTUs
Determine the inner MTU from the actual encapsulation protocol, outer address family, and underlying link limit. Do not apply 1500, 1450, or 1400 indiscriminately. Before changing the interface used for remote access, arrange a console or another out-of-band access method, test during a maintenance window, and retain a rollback configuration.
Check the necessary ICMP feedback
Within your security policy, permit the IPv4 “fragmentation needed” and ICMPv6 Packet Too Big feedback required by PMTUD. Check direction and how related traffic is handled. There is no need to flush the firewall for this diagnosis, and allowing ping is not equivalent to allowing every necessary ICMP error message.[2][3]
Evaluate MSS adjustment at a defined TCP boundary
MSS clamping may be appropriate at a clearly identified TCP tunnel or forwarding boundary. Base its value and direction on the actual path, and validate with newly established connections. It changes TCP negotiation information; it does not fix UDP or QUIC packet-size problems or replace end-to-end diagnosis.
Understand the scope of tcp_mtu_probing
Read the current setting first:
sysctl net.ipv4.tcp_mtu_probing
The Linux kernel documentation defines the values as follows:[6]
0: Disable TCP packetization-layer MTU probing.
1: Leave it disabled normally, but enable it when an ICMP black hole is detected.
2: Keep it enabled, using tcp_base_mss as the initial MSS.
After reviewing the evidence, you can evaluate value 1 in a controlled environment. It is not a universal optimization switch. It applies to the TCP stack in the relevant network namespace, does not directly repair all traffic merely forwarded through that host, and does not resolve UDP or QUIC failures.
Before changing it, record the previous value and scope. Test new connections before deciding whether to make the change persistent, and restore the recorded value if rollback is needed. Avoid changing many kernel parameters at once, which makes the effect of each change difficult to establish.
8. Validate the original failure path
Retest the same hostname, outbound path, and access method that exhibited the problem. Cover small responses, larger downloads, and uploads where applicable. If the service supports both IPv4 and IPv6, test them separately. If it uses HTTP/3, validate the UDP-based path independently as well.
For a CDN-backed website, record client-to-edge and edge-to-origin results separately. A successful curl command on the origin host validates only the path taken by that request; it does not prove that the path from a real visitor to the CDN is healthy.
Keep a record of interface and tunnel MTUs, destinations, timestamps, probe sizes, connection symptoms, and the before-and-after configuration. Confirm that transfers continue making progress without repeated stalls, and observe a representative business period. A single successful ping is not enough to close the investigation.
Frequently asked questions
Can a loss-free ping rule out a network problem?
No. Small ICMP Echo probes can differ from HTTPS traffic in protocol, packet size, and path handling. Validate the actual application request as well.
Will setting the MTU to 1400 fix it?
Not necessarily. It may temporarily restore one path, reduce efficiency, or introduce another problem. Identify the encapsulation overhead and failure location before choosing a value.
Could an MTU problem affect only the TLS handshake?
It could, but certificate chains, TLS policy, intermediate proxies, and packet loss also need investigation. Combine handshake progress, packet-size comparisons, and retransmission evidence rather than relying only on the browser's error message.
Will adjusting MSS also restore HTTP/3?
Not automatically. MSS is a TCP mechanism. HTTP/3 uses QUIC over UDP and requires separate checks of the path and packet-size handling.
What to do next
When ping works but a website will not load, first identify whether the request stops during resolution, connection establishment, the handshake, or data transfer. Focus on PMTU and its feedback mechanisms when small packets work, larger packets repeatedly stall, and interface, tunnel, or address-family comparisons point to the same path.
Make changes that can be verified: align MTUs, check required ICMP/PTB feedback, and evaluate MSS adjustment or TCP probing where appropriate. Record the original settings, keep changes narrowly scoped, and retest the real application path to establish whether the fault is resolved.
References
Sources checked on September 8, 2026. Commands assume a Linux environment with the corresponding tools installed; behavior and output may vary by distribution and kernel version. The example commands and conceptual illustration are not presented as CloudFlew benchmark or test results.
