DEV Community

98IP Proxy
98IP Proxy

Posted on

Test IPv6 Proxy Paths Without Mistaking Fallback for Support

#testing

A request that succeeds on a dual-stack machine does not prove that the proxy path supports IPv6.

There are at least two independent network legs:

  1. client to proxy;
  2. proxy to destination.

The client may reach the proxy over IPv6 while the proxy exits over IPv4. The reverse can also happen. DNS may run locally or at the proxy, and a client may silently fall back after a slow failed attempt.

Build a four-case matrix

Keep credentials, destination, method, headers, and timeouts constant. Change only the address-family condition.

Case A: force IPv4 to an IPv4-capable target
Case B: force IPv6 to an IPv6-capable target
Case C: allow dual stack and record the winning family
Case D: impair the preferred family and measure fallback
Enter fullscreen mode Exit fullscreen mode

Do not use a single success as evidence for all four cases.

Observe every layer

Capture separate timestamps for proxy DNS, TCP connection, proxy authentication, CONNECT establishment, TLS handshake, first byte, and completion. Record the actual proxy address used and the public exit family observed by the destination.

This separation prevents common misdiagnoses:

  • AAAA lookup succeeds, but IPv6 routing is broken;
  • TCP reaches the proxy, but TLS hostname verification fails;
  • the client uses IPv6, but the proxy exits over IPv4;
  • the final request succeeds only after a long fallback delay.

Treat SOCKS DNS as a separate variable

With SOCKS, local and remote DNS can produce different routes. A locally resolved IPv6 destination may not match the route selected when the proxy resolves the hostname. Keep the DNS mode explicit in test results.

Literal address diagnostics

An IPv6 literal in a URL or proxy endpoint needs square brackets, with the port after the closing bracket.

http://[IPv6_ADDRESS]:PORT
Enter fullscreen mode Exit fullscreen mode

Use literals only to isolate DNS from transport. Production should normally return to the real hostname so certificate names and DNS failover are exercised.

Measure fallback latency

Dual-stack clients may race or sequence connection attempts. Record both the winning family and connection time. Simulate:

  • IPv6 unavailable;
  • IPv6 high latency or loss;
  • IPv4 unavailable;
  • one family blocked at the proxy;
  • a destination with only one family.

The total DNS, connection, authentication, TLS, fallback, and response time must remain inside the job deadline. A success after an excessive delay is not a healthy result.

Check session behavior

If the workflow uses sticky sessions, verify that fallback does not change exit identity, location, or risk classification unexpectedly. Track address-family selection separately from deliberate proxy rotation.

IPv4 and IPv6 exits should initially have separate baselines for success rate, p95 latency, geolocation accuracy, reputation, and session continuity.

Minimal acceptance checklist

  • A and AAAA records are confirmed for the proxy hostname.
  • Forced IPv4 and forced IPv6 both pass independently.
  • DNS placement is documented.
  • TCP, tunnel, TLS, and first-byte timing are separated.
  • Public exit family and location are verified.
  • One-family failure produces bounded fallback.
  • Credentials are absent from logs and traces.
  • Session behavior remains acceptable across family changes.

Disclosure: I work with 98IP. This guide is for authorized network and automation testing. Additional proxy engineering resources: https://en.98ip.com/?k=dev

Top comments (0)