Classify the difference before interpreting it
| Scenario | Possible observation | Next step |
|---|---|---|
| Same country and ASN; different city | Carrier allocation or geolocation granularity | Prioritize country or regional results before calling it abnormal |
| Same carrier; different ASNs | Different IPv4 and IPv6 upstreams or architecture | Combine it with the actual failure and routing policy |
| Different country or network type | Different proxy coverage, tunnel, or regional gateway | Check whether the proxy covers both families |
| IPv4 proxied; IPv6 direct | Clearly different region and network profiles | Test whether the failure consistently follows IPv6 |
| One family works and the other fails | A blocked, degraded, or incomplete path | Use a single-variable comparison before concluding |
| WebRTC differs from the site exit | Another browser-observable public candidate | Supporting evidence only, not the one Claude session proof |
Why a browser can choose different address families
DNS can return A and AAAA records
A dual-stack host can offer IPv4 and IPv6 candidates. The public page, sign-in redirect, and resources may use different hosts with different candidate sets.
The system sorts and attempts candidates
System policy, interface availability, and routing influence address selection. The mechanism explains multiple candidates, not the final public exit of one Claude request.
Separate requests need not share one path
Page, authentication, and resource requests can connect to different hosts over time. The address family seen on this page cannot represent every request in a Claude session.
Proxy rules can cover only one family
An IPv4-only proxy, missing IPv6 rule, or separate gateways can make the two families behave differently; check actual rule coverage.
Record both exits and the Claude routing result
- IPv4 and IPv6 addresses and whether each check completed
- Country or region, ASN, network type, and proxy-related signals; treat city as lower-priority evidence
- Claude connectivity, its routing exit, and the failure time
- Whether the proxy covers both IPv4 and IPv6 or has direct and split-routing exceptions
- Whether a WebRTC public candidate differs from the site exit, without calling that difference a leak or access proof
Locate the configuration difference with one variable
Change one condition per run: for example, confirm IPv6 proxy coverage, or repeat the same browser and Claude page on one stable network. Record both families and the routing exit again, then see whether the failure consistently follows one path.
Temporarily disabling one address family can be diagnostic, not a permanent fix. Restore normal configuration after the test and correct the proxy coverage, routing, DNS, or upstream issue.
If aligned exits still cannot access Claude
When IPv4, IPv6, region, and ASN are stable and aligned but Claude still does not load, move to browser session, sign-in message, and Anthropic Status checks. Dual-stack alignment removes one class of network variable; it does not guarantee full service, regional eligibility, or account state.
Sources and evidence limits
Sources below support the stated technical or policy boundary. Diagnostic comparisons in this guide remain observations, not account verdicts.
- Claude StatusAnthropic · Official guidance
- RFC 6724: Default Address Selection for IPv6IETF · Technical standard
- RFC 8305: Happy Eyeballs Version 2IETF · Technical standard