Diagnose IPv6 Proxy MTU Black Holes Before They Reach Production

A proxy can authenticate, complete a TCP handshake, and return a small response while larger requests hang. That pattern is often misclassified as a bad exit IP or an overloaded proxy. On IPv6 paths, it can instead be a Path MTU black hole: packets exceed a bottleneck after proxy or tunnel headers are added, while the feedback needed to reduce packet size never reaches the sender.

This guide builds a repeatable test that distinguishes an MTU problem from DNS, authentication, rate limiting, or general packet loss. It is intended for authorized proxy gateways, application endpoints, and test infrastructure.

Why proxy paths make MTU failures harder to see

The effective route may contain a client network, VPN, proxy tunnel, provider backbone, exit network, and destination. Every encapsulation layer consumes bytes. IPv6 routers do not fragment transit packets; senders depend on Path MTU Discovery and ICMPv6 Packet Too Big feedback. If that feedback is filtered, small packets may work while larger packets disappear.

Do not infer MTU from the client interface alone. The narrowest link can be after the proxy gateway, and the application payload limit is lower than the link MTU after IPv6, TCP or UDP, TLS, and tunnel overhead.

Recognize the signal without overdiagnosing

Suspect a Path MTU issue when all of these appear together:

• authentication and connection setup succeed;
• small headers or responses complete consistently;
• larger uploads, downloads, or TLS records stall near a repeatable size;
• lowering the client or tunnel MTU changes the result;
• the failure follows a route, address family, or tunnel mode rather than an account;
• ordinary retries reproduce the same size boundary.

These signals are not proof. Similar symptoms can come from an application body limit, idle timeout, congestion, or middlebox policy. Use controls.

Build a controlled test matrix

Record the client region, proxy product, gateway, exit region, transport, IPv4 or IPv6, tunnel mode, destination, request ID, start time, and payload size. Use a destination you control so it can report received bytes and correlate the same request ID.

For each route, run four comparisons:

1. direct IPv4 and direct IPv6;
2. proxied IPv4 and proxied IPv6;
3. tunnel enabled and disabled, when authorized;
4. small, medium, and progressively larger payloads.

Change one variable at a time. A direct-path success does not prove the proxy path is healthy, and an IPv4 success does not validate IPv6.

Step 1: establish small-payload health

Confirm DNS resolution, proxy authentication, tunnel establishment, TLS negotiation, status code, and a small complete response. Capture timings for name lookup, connect, TLS, first byte, and total transfer. Stop here if setup is unreliable; MTU testing cannot explain a connection that never becomes healthy.

Step 2: use size-stepped probes

Send authorized payloads in increasing size bands rather than jumping from a tiny request to a production object. Repeat each band several times and record delivered bytes, duration, timeout stage, and retransmission evidence. The goal is to find a stable transition from success to failure, not to flood the route.

For UDP or QUIC-based paths, use application-confirmed probes and a Packetization Layer PMTU method where supported. A test must not rely only on receiving an ICMP message; missing feedback is part of the failure being diagnosed.

Step 3: account for every header

Document IPv6, transport, TLS, proxy, VPN, and encapsulation overhead. If an outer tunnel adds headers, the safe inner packet must be smaller. Compare configured interface MTU with the effective application payload. Avoid copying a single universal MTU value into production: the correct value depends on the actual path and encapsulation stack.

Step 4: test Packet Too Big visibility

On systems you control, inspect whether validated ICMPv6 Packet Too Big messages arrive and whether the sender updates its route information. Correlate packet captures or counters at the client, tunnel gateway, proxy gateway, and destination. Never disable ICMPv6 broadly as a workaround; it performs essential IPv6 control functions.

Step 5: separate MTU from loss and policy

An MTU black hole usually creates a repeatable size-dependent boundary. Congestion loss is less deterministic and changes with load. Application policy often returns an explicit status or closes the request at a body limit. Rate limiting follows request frequency or identity. Compare the same payload across direct and proxied routes, then lower only the relevant tunnel or interface MTU in a temporary test. A clean recovery is strong evidence, but retain end-to-end observations before changing production.

Safe remediation order

1. restore required ICMPv6 feedback and validate it;
2. correct tunnel overhead accounting;
3. enable robust PLPMTUD where the transport supports it;
4. set a conservative path-specific MTU only when discovery cannot be repaired immediately;
5. monitor by route and address family after the change.

Do not solve the symptom by forcing all traffic to IPv4 or shrinking every interface indefinitely. Those choices can hide the defect and waste capacity.

Production pass criteria

A route passes only when small and production-sized transfers complete across every required region, protocol, address family, and tunnel mode; the destination receives the expected byte count; no plaintext credentials appear in evidence; retries do not mask a size boundary; and a controlled path change triggers rediscovery or safe fallback.

Keep the evidence record short: request ID, route, size, outcome, timing, observed MTU signal, software version, and test time. Redact tokens, cookies, customer payloads, and full query strings.

Provider evaluation checklist

• Can the provider state tunnel overhead and supported address families?
• Are IPv4 and IPv6 paths measured separately?
• Can support correlate a customer request ID without receiving credentials?
• Are Packet Too Big handling and PLPMTUD behaviors documented?
• Can a customer select or test alternate gateways safely?
• Are route changes and tunnel upgrades exposed in status data?
• Can logs prove delivered bytes and failure stage?

FAQ

Does a successful ping prove the MTU is correct?

No. A small echo request can succeed below the failing size and may follow different policy. Use size-stepped application probes and destination confirmation.

Should I block ICMPv6 for security?

Do not block it indiscriminately. Validate and rate-limit where appropriate, but preserve the control messages required for healthy IPv6 operation.

Is 1280 always the best fix?

It is the IPv6 minimum link MTU, not a universal performance setting. Use it only as a diagnostic boundary or conservative temporary measure while repairing discovery and overhead accounting.

Compliance note

Run probes only against systems, proxy accounts, and routes you are authorized to test. Respect service terms, rate limits, privacy obligations, retention policies, and regional law. Do not use troubleshooting as a reason to bypass access controls.

Continue with the internal proxy guides and 98IP resources when validating an IPv6 route.