Classify the mismatch before interpreting it

Common IPv4/IPv6 exit mismatch scenarios
ScenarioPossible observationEnough to call it abnormal?
Same ASN and country; different cityDataset granularity or carrier address schedulingNo; preserve country or subdivision precision
Same carrier; different ASNsSeparate IPv4 and IPv6 upstreams or architectureNo; combine with routing and the actual failure
Different country or subdivisionProxy coverage, tunnel, regional gateway, or data differenceReview it, but do not infer account risk
IPv4 is proxied; IPv6 is directDifferent regions and network profiles by familyA configuration difference; test whether failure follows IPv6
One family works; the other failsA blocked, degraded, or incomplete pathReproduce with one variable before concluding
WebRTC and site exits differAnother browser-observable candidate or pathSupporting evidence only

Why a browser can choose different address families

  1. DNS provides A and AAAA candidates

    A dual-stack hostname can publish IPv4 and IPv6 addresses. The page, sign-in redirect, and static resources may also use different hostnames with different candidate sets.

  2. The system sorts candidate addresses

    RFC 6724 describes default address-selection rules. System policy, interface availability, and routing influence order, but the standard cannot prove the final address used by one browser request.

  3. The client attempts usable paths

    RFC 8305 Happy Eyeballs v2 schedules attempts across addresses to reduce delay when one family is blocked, broken, or suboptimal. Implementation and current path quality affect the winning connection.

  4. Separate requests can resolve differently

    The document, authentication flow, and resources may connect to different hosts at different times. The family used for this site does not represent every request in a ChatGPT session.

Record both exits separately

  • IPv4 and IPv6 addresses and whether each check completed
  • Country, subdivision, and Needs review state; treat city as lower-priority evidence
  • ASN, AS name, and carrier or network organization
  • Network type, routing attributes, and proxy, VPN, or Tor signals
  • ChatGPT connection result and exact failure time
  • Whether the proxy covers both families or leaves one family direct

Use WebRTC and single-variable tests

The WebRTC exit check reports public candidates observed through STUN and compares them with this site's exit for the same family. A difference is worth recording, but it does not prove a privacy leak or show which address ChatGPT used.

Change one condition at a time, such as checking whether the proxy covers IPv6 or testing one other known stable network, then record both exits again. Simultaneously changing DNS, proxy routing, and address-family settings destroys attribution.

Handle a confirmed configuration difference

If the failure consistently follows one family, inspect the router, carrier, enterprise network, or proxy for separate IPv4 and IPv6 policy. IPv4-only proxying with direct IPv6, or families exiting in different regions, are common configuration differences.

Without network administration access, provide both exit records and reproduction steps to the administrator or provider. Rapid node rotation is not a substitute for correcting the configuration.

If aligned exits still fail

When IPv4, IPv6, region, and ASN are stable and aligned but ChatGPT still fails, move to browser-session, account-message, and official service-status checks. Dual-stack consistency removes one network variable; it does not guarantee complete service or account access.

Sources and evidence limits

Sources below support the stated technical or policy boundary. Diagnostic comparisons in this guide remain observations, not account verdicts.