Three Things to Watch in Claude Account Suspensions: Region, IP Type, Request Fingerprints, and How to Self-Check

Updated 2026-10-22. The Claude Code date watermark from the previous version was pulled by Anthropic in July, and I couldn't find it in 2.1.303 on my machine, so that section is now history. New sections cover IPv6 and split routing, bans that have nothing to do with your network, and what to do after a ban. The description of the detection page matches what it does today.

I first wrote this in early July. There have been several rounds of bans since, the biggest around China's National Day holiday: between September 30 and October 2, VPN users in Hong Kong and Russia got a batch of "suspicious signals" suspension emails. SCMP and Novaya Gazeta both covered it; Anthropic didn't comment. On the Chinese forums linux.do and V2EX, ban threads piled up over the same weeks.

I went back through everything I could find from the last three months: Anthropic's policy pages and transparency report, English cases on Reddit and in GitHub issues, Chinese cases on linux.do and V2EX, and my own look at the client. The basic picture holds. A ban still comes down to three things:

• Region: which country your exit is in. This is the only ban reason Anthropic spells out.
• IP type: residential, datacenter, VPN, proxy. Anthropic never mentions it, but reputation databases measure it well.
• What your requests carry on their own: it used to be the date watermark; now it's client telemetry and your relay's domain.

What changed is the third item. And this time I have to admit the three don't explain every ban. In the October wave, some people did everything on the list and still lost the account within two hours. More on that below.

Region is the only red line Anthropic writes down

The help article Safeguards warnings and appeals gives three reasons for a ban: repeated Usage Policy violations, account creation from an unsupported location, and Terms of Service violations. Nothing about VPNs, proxies or IP addresses.

The Supported Regions Policy now shows a new version effective November 12, 2026, and it is more explicit. The first unsupported case it lists is:

Use by persons while physically located in an unsupported region

Where you physically are is what counts, not where the account or your company is registered. Mainland China, Hong Kong and Macau are not on the list; Taiwan is. The other two clauses cover companies: entities headquartered in an unsupported region, and entities majority-owned or controlled from one, wherever their staff happen to be.

So a residential IP in Beijing can have a spotless reputation and still be over the line. People use proxies to get around exactly this, and then trip on IP type or one of the things further down.

Location changes matter too. A US user on GitHub moved from Maryland to Oregon, switched to Xfinity, paid with a Chase card, and was banned on September 30 under the Supported Countries Policy (#99102). Someone on Reddit was banned after travelling within Europe (r/claude). All of them were in supported countries; the location check fired anyway. A Max user whose VPN exit bounced between Finland and Los Angeles went the same way (#99907).

IP type, the way reputation vendors score it

Anthropic doesn't say it looks at IP type, but nearly every "switched networks and it was fine" story comes down to whether the exit was a datacenter, proxy or VPN. Fraud vendors publish their scoring, so here's how they do it.

proxycheck.io gives each type a base score: datacenter 33, VPN 50, crawler and Tor 75, open proxy and compromised host 100. Higher is worse. A VPN scores above a plain datacenter because a server talking to the internet is normal, while a VPN or proxy is someone deliberately hiding.

Residential proxies are the nastiest. IP2Location has a separate RES class for home broadband connections resold as proxies. By location and ASN they look like any household, but strangers have been running automation through them for years. Most cheap "residential IP" offers are this.

Reputation is also shared. ipapi.is computes an abuser_score from the share of abusive IPs across the whole ASN: above 20% is very high, 3–20% high, 0.85–3% elevated, 0.05–0.85% low, under 0.05% very low. Your IP can have no history of its own and still inherit a dirty neighbourhood. AbuseIPDB's abuseConfidenceScore runs 0–100 and grows with the log of community reports.

A datacenter IP is not an automatic ban, which I said last time and still holds. Running Claude Code or calling the API from AWS or GCP is normal. The risky moments are logging into claude.ai on the web, signing up, and redoing OAuth. Those flows are built for a person in a browser, and a datacenter exit there looks like account farming.

One idea that has gained ground in the community since July: a stable exit matters more than a clean one. A V2EX user says rotating residential proxies died fastest while a fixed datacenter IP lasted, and someone on linux.do has run Claude through a VPS over SSH since late August without trouble. These are single cases, but they point the same way: one account, one exit, and don't let it move.

IPv6 and split routing: the exit you didn't plan for

This section is new, and it's where most people get caught out without knowing it.

claude.ai is dual-stack. I just checked: claude.ai, claude.com, anthropic.com, api.anthropic.com and the short-link domain clau.de all resolve to the same pair, IPv4 160.79.104.10 and IPv6 2607:6bc0::10. Running curl https://claude.ai/cdn-cgi/trace on my home connection, the ip= line came back as an IPv6 address. When your system has IPv6, traffic to Claude goes over IPv6 first.

Plenty of proxy setups only handle IPv4. In rule mode, IPv6 goes straight out through your local ISP: a speed test shows a US IPv4, while Claude sees your home IPv6. Domain rules have the same hole. Write only claude.ai and requests to claude.com, anthropic.com and claudeusercontent.com go direct. All those domains sit in Anthropic's own AS399358, so in Clash Meta / mihomo a single IP-ASN,399358,YourProxyGroup rule covers them.

I couldn't find a first-hand report of a ban caused specifically by an IPv6 leak, so all I can say is that the mechanism is real. The closest case: a linux.do user ran Clash without TUN mode, and some Claude Code requests skipped the line he'd set up for Claude and went out through his proxy provider's shared exit. The account was gone an hour after he started using Claude Code, after a week of normal web use (2026-09-28).

Phones are harder. A community telemetry audit of the Claude clients (October 6) reports that the Android app sends every network interface address to the fraud-detection service Sift, including the real public IPv6 with a VPN on, along with the raw ANDROID_ID. I haven't reproduced this on a phone. But if you tune your laptop's network carefully and then log into the same account from the phone app, think about it.

Request fingerprints: the watermark is gone, other things aren't

This was the longest section last time. Claude Code hid a steganographic mark in the system prompt line "Today's date is …". With the system timezone set to Asia/Shanghai or Asia/Urumqi, the date separator changed from - to /. With a third-party ANTHROPIC_BASE_URL, the apostrophe was swapped for one of several look-alike Unicode characters depending on the relay domain. The details came from Chen Cheng's (sorrycc) reverse engineering of version 2.1.191.

That watermark has been withdrawn. According to The Decoder on July 1, it had been there since 2.1.91 (released April 2). After a Reddit user exposed it, Thariq Shihipar from the Claude Code team said on X that it was an experiment launched in March against unauthorized resellers and distillation, that the PR to remove it was merged, and that it would be fully rolled back in the next release. He also said: "The team has landed stronger mitigations since then."

I checked 2.1.303 on my machine. The function that builds the date only outputs YYYY-MM-DD, the apostrophe in that sentence is plain ASCII, and the string Asia/Urumqi doesn't appear anywhere in the binary. I couldn't find the old encoding. What the "stronger mitigations" are, I don't know, and I won't guess.

Here's what the client verifiably still sends:

• Your relay's domain. Every few hours Claude Code fetches experiment config (GrowthBook) from api.anthropic.com. The request has a field called apiBaseUrlHost whose value is the host in your ANTHROPIC_BASE_URL, in plain text, next to your device ID and account ID. I saw this field in 2.1.303 myself, and the audit says the same. Pointing Claude Code at a relay does not mean it stops talking to Anthropic.
• Timezone and language. Per the audit, the desktop app's error reporting (Sentry) fires at launch, before login, and includes the system timezone and language, such as Asia/Shanghai and zh-CN. On the web it's simpler: any page can read your browser timezone and Accept-Language.
• Resold subscription credentials. The Claude Code legal page is clear that Pro and Max OAuth is for Claude Code and Anthropic's own apps; third parties may not offer Claude login or route requests through your subscription for other users. A V2EX user put accounts behind sub2api, a relay that shares subscriptions, and they were banned in about three hours with "This organization is not allowed to use OAuth", while the same accounts used directly on his own machine survived (March 2026).

A browser-visible timezone that differs from the exit region can be recorded as an environment mismatch. It does not prove the cause of a suspension, and there is no evidence here that changing the timezone prevents one. Desktop payloads need verification for the specific platform and version.

Local identifiers and telemetry are outside a web page’s view

IX’s October 21 reverse-engineering report examines Windows Claude Code 2.1.306 and Desktop 3.1623.0. It identifies local installation IDs, Desktop Sentry environment context and feature-gated identity linking as useful inspection leads. It does not recover server-side suspension rules, and its Windows findings cannot establish behavior on macOS or other versions.

Network checks leave a gap: a normal web page cannot automatically inspect Claude’s local files or running-process environment. A user-selected file can be parsed locally, but remains user-supplied evidence with a capture time, not independent verification of the device’s current state.

For more checks on your Mac, download Thermo. Released versions provide AI-tool configuration checks and browser privacy controls. Dedicated read-only Claude diagnostics and redacted report export are in development under Thermo #6. The feature is intended to inspect identifier presence, telemetry configuration sources and readable process environments while preserving unknown results. Check your installed version for availability.

IP Check now provides a companion report importer for reports from a Thermo version that includes this feature. It parses that redacted summary only in page memory, without uploading, storing or folding it into an account-safety score. A network exit, a settings file, a process environment and an actual outbound payload provide different evidence.

The switches themselves differ. The official variable reference documents non-empty-value semantics for DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, including 0; DO_NOT_TRACK uses boolean semantics. Disabling telemetry can affect features that depend on remote flags. Behavior must be checked against the installed version, and a configured switch does not prove that every transmission has stopped.

These checks explain local state. They cannot identify the cause of a suspension, and resetting identifiers or disabling telemetry should not be presented as an appeal, anonymity or anti-ban guarantee.

Bans these three things don't explain

The October wave is why this section exists. On linux.do, one user started a fresh VM, reset the device ID, turned on TUN, switched the OS to English, sorted out DNS and WebRTC, and paid with a US friend's physical AMEX card. Banned 1.5 hours after first login (2026-10-14). On V2EX, a 23-person Business team with a US exit and a US company card ran fine for six months and was banned as a whole on September 26.

It cuts the other way too. A V2EX user on a datacenter IP, no TUN, Shanghai timezone, leaking WebRTC and an all-Chinese interface still has three Pro/Max accounts alive.

The network is only part of it. These other causes come up again and again. Most are single cases, so I've linked them and you can weigh them yourself:

• Payment cards. An author on X who lost five accounts and compared them says a card previously used on a banned account gets a new account banned almost immediately, and that card and conversation content mattered more than IP or timezone (2026-10-15, a handful of accounts).
• Guilt by association. In the July mass ban of people who used a payment loophole to get Max, users reported accounts on the same IP or device going down together. While I was building the detection page, someone in a user group told me that after a ban, signing up a new account from the same IP failed, and a different IP worked.
• Conversation content. A lab's account on linux.do, fine for months, was banned within an hour of training a Transformer on sensor data. On Reddit, someone had Claude write a game design doc with espionage and nuclear themes and was banned under "cybersecurity" (r/Anthropic). Nothing to do with networking, but it exists.
• Multiple accounts. On Hacker News, someone lost 13 Max 20x accounts at once, and new ones made with different cards and a VPN didn't last either. The consumer terms already say you can't let anyone else use your account.
• Passing KYC doesn't protect the account. The official identity verification page asks for a physical government photo ID plus a selfie and excludes no country, and several people on linux.do passed with a Chinese passport. But in the AMEX thread above, someone was banned two hours after passing. KYC checks who you are; the policy is about where you are.
• Activity at 1–6 a.m. local time. I have one report for this, from a user group: accounts on a Singapore exit, active as usual on a Chinese make-up working day, were banned in a batch. I have no other samples. The detection page flags activity between 1 and 6 a.m. at the exit's local time as "caution", and that's all it is.

What the detection page checks now

ip-check.leeguoo.com shows a result as soon as it loads, no sign-up. It's changed a lot in three months to cover the cases above:

• IPv4 and IPv6 exits are checked separately, then compared. IPv4 in the US and IPv6 at home gets flagged, with a note that your proxy probably only handles IPv4.
• Cloudflare's view. claude.ai sits behind Cloudflare, so the page also shows the exit Cloudflare sees.
• Browser timezone vs. exit timezone. A mainland China timezone is red; a gap of more than two hours from the IP's location is yellow.
• Local time at the exit. It works out the current hour in the exit IP's timezone and flags 1–6 a.m.
• WebRTC. It checks whether the browser leaks a public IP other than your exit. An IPv6 address on the same network (normal for direct dual-stack) isn't counted as a leak.
• Optional: paste claude.ai's trace. If your proxy splits traffic by domain, claude.ai may take a different route. Open claude.ai/cdn-cgi/trace in a private window, paste the text back, and the page re-judges using the IP claude.ai actually sees. Don't open it in a window where you're logged into Claude.

Nothing except the trace step touches Anthropic, which is why that step is optional.

Below that is a local checklist: system proxy, leftover proxy variables in your environment, ANTHROPIC_BASE_URL. A web page can't see these, but Claude Code reads all of them at startup. The commands are listed there for you to run in a terminal.

Verdicts are still in four buckets: safe, caution (datacenter, depends on what you're doing), high risk (VPN, proxy, Tor, or stacked abuse signals), and unsupported region. Region comes first, so a clean residential IP in Beijing is never called safe. Chinese clouds like Alibaba Cloud, Tencent Cloud and Volcano Engine are flagged separately even when the IP is in the US.

To check another IP, use ip-check.leeguoo.com/?ip=1.2.3.4; add an Accept: application/json header for structured output.

The page sees IP type and region. It can't tell whether an IP has been used by a banned account, and it can't see your card or your conversations. All green means the network layer is fine, nothing more.

Checklist, most important first

1. Fix the region first. If your exit is in mainland China, Hong Kong or Macau, nothing else matters.
2. One account, one fixed exit. Don't hop between countries, and don't rotate several accounts on one machine. Don't sign up new accounts on a line that has already had a ban.
3. Close the IPv6 and routing gaps. Use TUN mode so the proxy takes all traffic, or turn IPv6 off; make your rules cover AS399358, not just claude.ai. The phone app counts as an exit too.
4. Match timezone and language to the exit. Exit in Japan, use Asia/Tokyo; exit in the US, use a US timezone. Last time I suggested Asia/Taipei to avoid the watermark. The watermark is gone, so that advice is too; now the rule is just to match your IP. On a Mac, also go to Privacy & Security → Location Services → System Services and turn off "Setting time zone", or it will switch back.
5. Authenticate from a clean network. First login, sign-up and re-running OAuth shouldn't happen on a datacenter or VPN exit. Day-to-day Claude Code on a server is fine.
6. Don't resell a subscription through a relay. If you need a relay, use an API key and pay per use; keep subscription accounts in the official clients. If you use a VPS, avoid the overseas regions of Chinese clouds like Alibaba Cloud and Tencent Cloud.
7. Don't reuse cards. A card that was on a banned account shouldn't go on a new one.
8. Re-check now and then. Proxy providers change exits, ISPs reassign residential IPs. Clean today doesn't mean clean next month.

If you've already been banned

• Export your data first. A banned account can still log into claude.ai and export or delete itself from the restricted page, no support ticket needed. Depending on the violation, what you can export may be limited.
• Turn off auto-renewal. People get busy appealing and forget the subscription is still billing.
• Appeal while logged into the banned account, using the form at claude.ai/restricted. Anthropic's transparency report shows 11.4 million banned accounts in the first half of 2026, 398k appeals and 42k overturned, about one in ten. Timing is all over the place: OpenClaw creator Peter Steinberger was back within hours after posting publicly, one linux.do user got an unban email two months later, and a Reddit user waited three months for a rejection.
• Refunds depend on how you paid. People who subscribed through Google Play and didn't complete KYC were refunded automatically a few days later. App Store subscriptions go through Apple's refund process. For direct card payments, one GitHub user's $216 Max plan was banned the same day and support cited the terms and refused a refund; others got unused days back automatically. There's no single answer.
• Reinstated doesn't always mean fixed. One GitHub user still had an account_banned flag on the organization after reinstatement and couldn't resubscribe.

Also: keep an eye on it from the status bar

If you use Claude Code, claude-code-usage-bar, which I maintain, puts your 5-hour and 7-day quota, context, cache countdown and session cost in the status bar. When your exit IP looks risky, it shows a red warning not to log into Claude from it, so you don't have to open the detection page.

uv tool install claude-statusbar

Or pipx install claude-statusbar, then point Claude Code's status line setting at it.