Locate the failed part of the flow first
| Symptom | Check first | Keep a record of |
|---|---|---|
| Public site and sign-in page both fail | Anthropic status, DNS, and basic connectivity | Exact URL, time, and browser message |
| Public site opens; sign-in stalls | Sign-in method, required cookies, redirects, and extensions | Failed step and complete page message |
| Signed in; chat keeps loading | Site data, script blocking, static resources, or network path | Whether another browser or device reproduces it |
| Only the current network fails | Public exit, proxy routing, DNS, and IPv4/IPv6 | Both families, ASN, region, and check time |
| Only one account sees a message on several networks | The page message, account or organization state, and official support | Full message and reproduction steps |
Use a controlled troubleshooting order
Review official status
When the same failure occurs across devices and networks, check Claude Status first. A normal page cannot rule out every local issue, but it avoids unrelated local changes during a known incident.
Record the page and message
Separate the claude.ai public page, sign-in flow, redirect, and authenticated session. Use the original sign-in method and preserve the exact message shown by Claude.
Compare a clean browser
Test with an up-to-date browser in a private window or clean profile. Check site data, cookie settings, script blocking, and extensions one condition at a time.
Test one known-stable network
If another network works, compare the original network's exit, DNS, proxy policy, and address family instead of changing several nodes and browser settings together.
Follow the reproduction scope
A browser-only failure calls for browser work; a network-only failure calls for an exit comparison; an account-specific message should follow the page guidance and Anthropic support.
How to compare the current network exit
The Claude check records the current IPv4, IPv6, region, ASN, network type, and connectivity result. AI Routing Exit Check can add the public exit returned through Claude's network endpoint. These comparisons examine network variables; they do not read Claude account, subscription, or organization state.
Recovery after a network change makes the original DNS, exit, proxy path, or route worth reviewing. It does not by itself prove that Claude rejected one IP. Data-center, proxy, and other risk signals are diagnostic clues, not account verdicts.
Treat IPv4, IPv6, and WebRTC as separate observations
- Record IPv4 and IPv6 region, ASN, network type, and check result separately
- Confirm whether proxy or policy routing covers both address families
- Use WebRTC only to add browser-observable public candidates, not as the sole proof of a Claude session exit
- Retest after one change and preserve same-window comparisons
A dual-stack device can use distinct paths for different hosts. This site's address-family result and a WebRTC candidate can expose a configuration difference, but neither proves that every Claude resource used that same address.
Prepare a useful support record
- Date, time zone, exact URL, and complete error text
- Whether another device, private window, and network reproduce the problem
- IPv4, IPv6, region, ASN, and whether a proxy or managed network is involved
- Steps already tried and their result
- A redacted screenshot or browser network error only when needed
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
- Claude Help CenterAnthropic · Official guidance
- How to get supportAnthropic · Official guidance