IPv4 Works. Why Are Some Users Still Unable to Reach Your Server?

Your dedicated server passes its availability check, but some customers still cannot connect. IPv6 troubleshooting should start by separating the two advertised network paths: a working IPv4 request does not establish that the same hostname works over IPv6.

The failure can be easy to miss. A browser may recover through another address family, while a different client fails or stalls. A CDN may serve the public hostname successfully even though the dedicated server’s own IPv6 path is broken.

The diagnostic goal is to locate the failing layer and identify who controls it. Check DNS, the external path, the server’s configuration, and the application in that order before making production changes.

Why one successful page load can hide a broken path

RFC 8305, Happy Eyeballs v2, describes connection behavior designed to improve connectivity across address families. It also explicitly warns that this behavior can conceal operational problems and recommends monitoring each family separately.

Do not use an ordinary browser visit as your only acceptance test. Record which destination address actually handled the request. Also distinguish the public edge from the origin: a successful IPv6 connection to a proxy proves something about that proxy, not every connection behind it.

For the addressing commitments behind the rental, check the dedicated server IP address review. This procedure addresses diagnosis after the service has been configured.

Prepare a comparison you can trust

1. Choose the endpoint. Record the hostname, port, safe request path, expected response, and whether a proxy or CDN terminates the connection.
2. Validate the probe. Use an external test system with working IPv6 connectivity to an independent authorized endpoint. A probe without IPv6 cannot establish that the destination is broken.
3. Control the request. Use the same hostname and application path for each family. Avoid requests that create purchases, send messages, or modify production data.
4. Keep context. Record timestamps with a timezone, source network, destination address, error, and result.

The commands below assume a Unix-like diagnostic host with curl and the relevant DNS tools installed. Host-side inspection assumes Linux with iproute2. They query configuration or send individual test requests; they do not change routes, firewall policy, or DNS.

Start IPv6 troubleshooting with the published DNS answers

Inspect the A and AAAA answers for the exact hostname users visit. The following commands use example.com as an illustrative domain; use the hostname under investigation:

dig example.com A
dig example.com AAAA

The BIND dig documentation describes these record queries. Keep the answers and relevant CNAME chain. Compare the authoritative configuration with answers from the resolver used by an affected client.

Check every advertised destination against the intended service layout. An obsolete AAAA record can direct clients to an old server while the A record correctly reaches the replacement. Multiple AAAA answers require testing each intended destination; one successful connection does not validate all of them.

If no AAAA answer exists, establish whether IPv6 is actually part of the public service design before diagnosing an IPv6 origin failure. The presence of an assigned IPv6 address in the provider portal does not itself publish that address to users.

Force each address family from outside the server

Use an approved direct-connect probe without an HTTP proxy configured. These examples request the same resource and discard its body:

curl -4 --connect-timeout 5 --max-time 20 \
  --silent --show-error --output /dev/null \
  --write-out 'ip=%{remote_ip} code=%{http_code} total=%{time_total}\n' \
  https://example.com/

curl -6 --connect-timeout 5 --max-time 20 \
  --silent --show-error --output /dev/null \
  --write-out 'ip=%{remote_ip} code=%{http_code} total=%{time_total}\n' \
  https://example.com/

The curl manual documents address-family selection and these output fields. The timeout values are diagnostic examples, not acceptable response-time targets. Preserve curl’s error and exit status as well as the printed values.

Check the HTTP response against the intended result. An HTTP error or redirect is different from a connection failure; a successful curl exit alone does not establish application health. These commands do not follow redirects, so test a redirect’s destination separately.

Classify where the request stops: name resolution, connection establishment, TLS, HTTP response, or response-body transfer. Keep certificate verification enabled. A certificate or virtual-host mismatch on the IPv6 endpoint needs repair, not a test that ignores the mismatch.

Repeat from another independent IPv6-capable network when possible. A failure isolated to one source network requires a different investigation from a failure observed across several unrelated paths.

Inspect the rented server without changing its network

On the Linux server, collect the configured IPv6 addresses, main IPv6 routing table, and listening TCP sockets:

ip -6 address show
ip -6 route show
ss -6 -lnt

The iproute2 manuals for addresses, routes, and sockets document these read-only views. Policy routing, containers, and separate network namespaces may require additional inspection in the relevant context.

Compare the assigned address, prefix, gateway arrangement, and active listener with the provider’s instructions and application configuration. Link-local addressing alone does not establish public reachability. A service listening only on IPv4 needs attention even if the host has a public IPv6 address.

Review host and provider firewall policy for the intended IPv6 service. Do not infer coverage from a working IPv4 rule. Where a reverse proxy or container runtime owns the listener, trace the whole request path instead of treating the host socket listing as the complete application topology.

Send the provider a reproducible IPv6 failure

Escalate when the evidence points toward provider-controlled routing, filtering, address delivery, or another infrastructure component. Supply the server identifier and exact source and destination IPv6 addresses, with sensitive account details kept in the authenticated ticket.

Include timestamps, the failing hostname and port, the IPv4 comparison, IPv6 results from independent networks, relevant host configuration, and the stage at which the request fails. State whether the affected address is the origin or an external proxy.

Ask for a specific investigation: confirmation that the assigned prefix is routed to the correct server, review of relevant provider filtering, or analysis of the observed source-to-destination path. A successful test from inside the provider’s network does not resolve contradictory external results.

Choose a controlled restoration path

Temporarily withdrawing an AAAA record may be an option when the intended users retain a viable alternative path, but it is not an instant traffic switch. DNS caching, described in RFC 1034, means previously returned data can remain in use. Existing connections also require consideration. Do not assume every client can use IPv4.

Illustrative scenario. A migration updates the A record but leaves an AAAA record pointing to the former server. Some clients reach the new service while others fail against the retired endpoint. The operator confirms the mismatched answers, validates the replacement’s IPv6 endpoint, and corrects the AAAA record. Recovery is verified through refreshed DNS answers and forced-family requests rather than a single browser visit.

Close the incident with separate IPv4 and IPv6 evidence

Retain the IPv6 troubleshooting record with the server’s operational documentation so the next operator can repeat the same checks.

Verify expected DNS answers, TLS identity, application responses, and representative transfers from the networks that exposed the problem. Where the public edge and origin differ, validate the relevant legs separately.

Configure distinct monitoring for each advertised address family and retain the chosen destination in diagnostic records. Add the checks to the deployment procedure and the server handover tests. Restore temporarily withdrawn IPv6 advertising only after the intended path passes its acceptance checks.