Claude

Claude Access Environment Checker

Use this page when Claude won't open, login keeps failing, a session drops, or Claude Code behaves differently from the web app. EnvTrace checks the access region, browser session, WebRTC, IPv6, clock and storage signals your environment presents, then separates the result into clear layers: region, session, network and developer self-checks.

What this Claude check helps you separate

A "Claude not available" message, a failed login and a dropped session can look similar, but they usually come from different layers. The report separates them so you know where to look first.

01

Access region

The first layer is the region Claude appears to see from your network. We show the detected country and compare it with the current supported-region reference so you can tell whether the issue starts before the browser session even matters.

02

Session readiness

Claude login depends on boring browser basics: an accurate clock, writable storage and cookies that survive redirects. If any of those are blocked, you can sign in and still get sent back to login.

03

Network consistency

WebRTC, IPv4 and IPv6 can expose different routes from the same browser. If those routes point to different regions, a long Claude session can look less stable than it actually is.

04

Developer path

Claude Code and API calls may leave from your terminal or server, not from the browser we scanned. We keep those items separate as self-checks: CLI egress, DNS resolver region and billing/subscription region.

Use the report from top to bottom

Start with the layer that appears first in the report. That keeps the check practical: don't tune browser settings if the access region is the real blocker, and don't blame the region when the session cannot persist.

  • Check the detected access region first. If it is the only flagged layer, you have an eligibility question, not a browser fingerprint question.
  • If the region looks fine, review session readiness: clock, cookies, localStorage and third-party-cookie behavior.
  • Then inspect network consistency: WebRTC, IPv4 and IPv6 should not point to conflicting regions.
  • For Claude Code or API, compare the browser result with the terminal or server environment you actually use.
  • After each change, run the check again and confirm the exact signal moved.

Frequently asked questions

Is Claude available in China, Hong Kong or Macau?
Start with the Claude access eligibility result on this page. If your detected region isn't in the supported list, we'll show that as the first access layer to understand. If the region is supported, move on to timezone, cookies, WebRTC and IPv6 consistency. The value here is to show which layer is causing friction, not to provide a workaround.
Why does Claude say my region isn't supported?
In most cases, the region message is driven by the access region Claude sees from your network. Check the detected IP country first. If it looks unexpected, your network route or IP geolocation may be the source. If the region looks fine, the next things to inspect are session storage, cookies and network consistency.
I'm in a supported country — why did I still get logged out or asked to verify again?
Then the issue is usually session quality, not country availability. A system clock that's off can break login tokens. Blocked local storage, blocked cookies or third-party-cookie restrictions can prevent the session from sticking. WebRTC or IPv6 can also introduce a second region signal mid-session. This page separates those signals so you can see what to adjust first.
Can this tool tell me if my Claude account will be suspended or restricted?
No tool outside Claude can know your account status. What we can do is remove guesswork from the environment side: whether your region, timezone, language, browser storage, WebRTC and IPv6 signals look consistent enough for a stable login session.
Does this tool give me a specific access setup?
No. It gives a diagnosis, not a setup recipe. The report shows which layer is most relevant to your current problem: access region, session readiness, network consistency, or developer-side self-checks outside the browser.
Why does this page check different things for Claude Code / API than for the Claude web app?
Because they use different entry points. The web app depends on the browser session: cookies, local storage, WebRTC, timezone and language. Claude Code and API calls leave from your terminal or server, which may use a different network, DNS resolver or billing region. The browser can't measure those directly, so we list them as self-checks instead of pretending to know.