Many people still have not figured out how they got caught in this recent wave of Claude account bans. Some people switched networks and kept using it without issue, while others logged in the next day only to find their accounts gone. They were both using relay services and both were in mainland China, yet the outcomes were completely different.
I went through every mechanism I could find: Anthropic’s official policies, methodology documents from several IP reputation vendors, real account-ban cases from the community, and the watermarking code in the Claude Code client that was reverse-engineered. After reading through all of it, I realized that account bans are not some kind of black box. They are the result of several dimensions that can each be detected separately. This article breaks those dimensions down one by one: what exactly can get you banned, how to check it yourself, and how to avoid it.
At the end, there are two small tools I wrote myself: one for checking your network and one for monitoring usage. Both are free, and I will cover them later.
First, the conclusion: bans depend on three things, not one
People generally assume that “using a VPN/relay will get you banned.” That is only half true. What really determines the risk is three independent dimensions, and any one of them can get you kicked out on its own.
The first is region: which country your network exits from. This is the only ban trigger Anthropic has explicitly stated officially. The second is IP type: residential, data center, VPN, proxy, or Tor. This dimension is measured most accurately by vendor reputation databases, though it has not been officially stated. The third is request fingerprinting: if you use a third-party relay, Claude Code embeds a steganographic watermark in the request that can be traced back to you. This dimension is completely independent of the first two.
Let’s go through them one by one.
Dimension 1: Region, the Only Red Line Officially Spelled Out
First, let’s look at what Anthropic says. In its support document “I received a warning for violating the Usage Policy. What should I do?”, the listed account-ban triggers fall into only three categories: violating usage rules with your content, violating the Terms of Service, and creating an account from an unsupported region.
Pay attention to the last one. Across the entire official document, there is not a single word mentioning VPNs, proxies, IP addresses, or shared connections. The only network-related concept is “region.” Anthropic also has another notice stating that its Terms of Service prohibit use of its services in certain regions due to legal, regulatory, and safety risks.
In plain English: mainland China is not on Anthropic’s supported regions list. Accessing Claude directly with a mainland China IP is itself a violation of the Terms of Service, and this has nothing to do with whether your IP is “clean.”
This also explains a phenomenon many people find confusing. “My home broadband is clearly a clean residential IP with no proxy at all, so why is there still risk?” Because the problem is not that it is “dirty”; the problem is that it is in the wrong place. A China Unicom residential IP in Beijing can have a perfect reputation score of 0, but it is still an egress point from mainland China, which is a red line for Claude. People use VPNs or relays precisely to get around this regional red line; as a result, they bypass the region dimension, only to fail on IP type and request fingerprinting.
Dimension Two: IP Type, the Dimension Vendors Measure Most Accurately
Although the official docs do not say it outright, most cases in the community where “switching networks fixes it” point to the same thing: whether your egress IP is a data center, proxy, or VPN. As for how this dimension is judged, professional risk-control vendors have already documented the methodology in great detail, so I will explain it based on their public docs.
Start with type. proxycheck.io assigns base scores to IPs by type: data center/data center IPs get 33 points, VPNs 50 points, crawlers/Tor 75 points, and public proxies and compromised hosts go straight to 100 points. The higher the score, the riskier the IP. This ordering is important: a VPN is riskier than an ordinary data center IP, and a proxy is riskier than a VPN. Because a data center IP at least means “this server is connected to the internet normally,” while proxies and VPNs clearly indicate that someone is trying to hide.
Residential proxies are the most insidious category. In IP2Location’s classification, there is a dedicated class called RES, residential proxy, meaning someone is selling a residential broadband connection as a proxy. Geographically and by ASN, this kind of IP looks exactly like normal residential broadband, but it has been used by countless strangers to run all kinds of automation, so its reputation is already ruined. If you bought a cheap “residential IP” service, odds are it is this kind, and the risk is even higher than a data center IP.
Reputation guilt spreads by association. ipapi.is has an abuser_score that measures not a single IP, but the proportion of abusive IPs in the entire ASN/organization network, divided into five tiers: above 20% is very high, 3% to 20% is high, 0.85% to 3% is elevated, 0.05% to 0.85% is low, and below 0.05% is very low. This means that even if your specific IP is completely clean and has no direct bad history, as long as the broader network segment it belongs to is dirty, you take the blame with it. Its original wording is that although this IP itself has not been flagged, given how many abusive IPs exist in its network, it is likely to be used for abuse in the near future. That is how risk control calculates it: it does not look at who you are, but who you are grouped with.
Abuse history accumulates. AbuseIPDB gives each IP an abuseConfidenceScore from 0 to 100, entirely based on community reports, where 100 means the IP is almost certainly malicious. Its score uses the natural logarithm of the number of reports: the more reports an IP receives, the higher the score, but growth slows over time, so one or two reports will not make it explode.
Put these together, and an IP’s risk profile looks roughly like this: type is the base layer, with data centers, VPNs, and proxies each having their own baseline; abuse history and network-segment reputation are stacked on top, making the profile redder and redder. This is also the scoring logic behind my detection tool, which I will discuss later.
An Important Correction: Data Center IP Does Not Mean Guaranteed Ban
Here I need to correct something I misunderstood at first. Many people see “data center IPs are risky” and assume that running Claude on a cloud server will get them banned. That is not true.
Running Claude Code or calling the API from an AWS/GCP server is a completely normal and supported use case. The truly dangerous scenario for a data center IP is only one thing: using it to log in to the claude.ai web version or register a new account. Web login and registration are flows designed for real humans using browsers. When a data center IP appears there, it looks like an automation script batch-farming accounts.
So do not judge data center IPs with a blanket rule. For API and command-line usage, data center IPs are fine; for logging into the web version or registering, data center IPs are dangerous. Many detection tools get this distinction wrong, including the first version of my own.
Dimension Three: the Watermark Hidden in the Date
The first two dimensions are “what your network looks like”; this one is “how Anthropic marks you inside the request.” The material comes from @chenchengpro’s reverse engineering of Claude Code version 191. I checked it against the client on my own machine, and the mechanism is real.
The trigger condition is that you set a third-party relay ANTHROPIC_BASE_URL, and it is not the official api.anthropic.com. Users connecting directly to the official endpoint are completely unaffected. This is also why Chencheng said the recent wave of bans is not directly related to this watermark: the watermark is a tracing mechanism prepared for relay and distillation scenarios, not the ban itself.
Claude Code has this line, spliced into the date in the system prompt:
return `Today${n}s date is ${r}.`;
It looks harmless, but that n apostrophe and the date separator are steganographically altered, quietly encoding two dimensions of identity information.
One is the time zone. When the system time zone is Asia/Shanghai or Asia/Urumqi, the date separator silently changes from 2026-06-30 to 2026/06/30. Note that it reads the system time zone (Intl…resolvedOptions().timeZone), not the IP geolocation.
The other is that apostrophe. It has four forms that are almost indistinguishable to the naked eye:
'(U+0027 standard apostrophe), ordinary third-party endpoint’(U+2019), domain whitelist hitʼ(U+02BC), domestic large-model keyword hitʹ(U+02B9), both domain and keyword hit
The three dimensions are encoded independently. Even if your relay domain is not on the whitelist and contains no keyword, as long as your system time zone is Shanghai or Urumqi, the separator still turns into slashes. In other words, users with “China time zone + any third-party endpoint” are all tagged on the time-zone dimension.
The matching logic was also dug out. Domains are matched by suffix; the whitelist starts with cn, so any domain ending in .cn is swept in, with no need to enumerate them one by one. Keywords are matched by substring: as long as "deepseek" appears in the domain, it hits, with no exact match required. The two lists are also obfuscated with XOR (key=91) plus base64 to evade string scanning.
Why choose the phrase “today’s date” as the carrier? This is the nastiest part. The marker is hidden in the body of the system prompt, not in HTTP headers or metadata. Relays usually rewrite and filter request headers, but almost nobody touches natural language like the “date,” so this is a watermark that cannot be washed away by washing headers. And currentDate is a user-context field carried with every request, so the watermark appears with 100% stability. The apostrophe and separator changes are semantically lossless; the model reads them exactly the same, and you probably would not notice them in a diff either.
How does the evidence loop close? The marker travels with the request. When a relay or distillation pipeline eventually routes back to Anthropic’s official API to resell Claude, this marked request flows back to Anthropic’s own servers. Anthropic can then read in its own logs: this request “directly connected to me” has the date 2026/06/30 (slashes mean China time zone), and the apostrophe is ʹ (both the domain and the DeepSeek keyword hit). Hard proof: the source is a client in a China time zone with a domestic large-model relay configured. It does not need active probing; the traffic confesses by itself.
The implication for ordinary users is straightforward. As long as you use a third-party relay, your requests can be fingerprinted and traced. If your time zone is mainland China, you are definitely tagged; if your time zone is not, but the relay domain is .cn or contains the name of a domestic model, you are tagged too. If you want to avoid being tagged completely, there is only one path: connect directly to the official endpoint.
So, How Exactly Do You Check for Yourself?
After covering the three dimensions, the question is: how do you know where your current network setup stands? IP type, region, reputation—none of these can be judged by eye.
I built a free checking page specifically to answer: “Can I safely use Claude on this network?”
Open it and you can immediately see the assessment of your current exit IP. No registration, no need to enter anything. It does a few things.
The assessment is divided into four categories, not a vague score: Safe (residential plus supported region), Caution (data center; depends what you use it for), High Risk (VPN, proxy, Tor, or combined with abuse signals), and Region Not Supported (mainland China, etc.). Each category tells you directly what to do, instead of throwing you a number and making you guess.
Region takes priority over IP. A clean residential IP in Beijing will not lie to you and say “Safe”; it will tell you “Region not supported, direct access is risky.” This is the key to turning IP detection into real Claude detection. For Claude, which country you are in matters more than how clean your IP is.
All signals are laid out for you. Data center, VPN, proxy, residential proxy, Tor, mobile network, and the abuse reputation tier of the network segment are all listed. Even signals that do not affect the score are shown. The more complete the information, the easier it is for you to judge.
There is also a Claude safety score plus a global ranking, from 0 to 100—the higher, the safer—and you can see how many checks worldwide you beat. It is purely for fun, but some people really do like comparing this number.
The scoring logic is exactly the system described in this article: proxycheck’s type baseline, plus ipapi.is network-segment reputation tiers, plus region assessment. The data sources are Cloudflare edge ASN intelligence and free threat intelligence databases. It does not call any paid third-party APIs or anti-scraping-protected services, so it will not break and has no quota limit.
If you want to check another IP, that works too: ip-check.leeguoo.com/?ip=1.2.3.4. Or add an Accept: application/json header to get structured results.
How to Avoid It: Action Checklist Ranked by Impact
After self-checking, you know where the risks are. The rest is how to avoid them, ranked by importance.
Region comes first. If your exit point is in mainland China or another unsupported region, this is the only red line officially stated, so fix it first. Use a clean residential network from a supported region.
Do not log in to or re-authenticate Claude on data center, VPN, or proxy IPs. This is especially true for first-time login, registration, and going through OAuth authentication again. These are the moments when risk controls are most sensitive. Running the API and CLI on a cloud server for daily use is fine, but authentication should be done on a clean residential network whenever possible.
Connect directly to official endpoints whenever you can. Use api.anthropic.com and claude.ai, and avoid third-party relays as much as possible. Besides IP risk, relays also carry the fingerprint watermark mentioned above, which cannot be washed out. If account-ban risk is what you are truly worried about, direct connection is the only way to solve both the IP and fingerprint problems at the same time.
Keep one account fixed to one clean network. Do not frequently switch across networks, and do not rapidly rotate multiple accounts on the same machine. These behavior patterns are themselves risk-control signals.
Check again regularly. VPNs change exit points, residential IPs can be reclaimed and reassigned by ISPs, and a relay you trust may get blacklisted one day. Clean today does not mean clean tomorrow.
By the way: a usage-watching status bar
The one above is for checking the network. If you use Claude Code, there is also a small tool I have been maintaining that keeps your quota, context, and burn rate in the status bar:
It does a few things. Real-time progress bars for the 5-hour and 7-day limits, plus a prediction of roughly what percentage you will burn through in the current window. When you switch models (Sonnet to Fable) or run multiple agents in parallel, the prediction immediately follows the new burn rate without lagging. Context window, prompt-cache countdown, and how much this session has cost: all visible in one line.
The ban-risk detection mentioned above is wired in too. When the exit IP is risky, the status bar directly shows a red warning not to log in to Claude from that IP; when you use a relay with the China timezone, it reminds you that your requests carry a fingerprint. You do not need to open a separate page to check the network; it watches for you.
Install with one command:
uv tool install claude-statusbar
Or pipx install claude-statusbar, or pip install -U claude-statusbar. After installing, just point Claude Code’s status bar settings to it.
Finally
When you break account bans down, they are not that mysterious. Region is the official red line, IP type is the reputation signal vendors can measure accurately, and request fingerprints are the traces you cannot avoid when routing through a relay. The three are independent; any one of them can get you caught, but each also has its own countermeasure.
The easiest solution is always to connect directly to the official service with a clean residential network, solving all three dimensions at once. If you cannot do that, at least spend ten seconds checking where you currently appear to be at ip-check.leeguoo.com.
The tools are all free, the source code is open, and issues are welcome.
微信
支付宝
Comments
Replies are public immediately and may be moderated for policy violations.