✏️ IP purity · login/multi-account risk check 中文 · EN
datacenter IP: fine for the API / Claude Code from a server; but avoid logging into claude.ai web or signing up a new account from it (looks like automation).
- a datacenter IP is fine for API / Claude Code, but do not use it to log into the web app or sign up.
- prefer the official endpoint (api.anthropic.com / claude.ai) over third-party relays.
- keep one account on one clean network; avoid rapid network hopping.
| IP risk score | 48/100 · hosting |
| ASN | AS13335 CLOUDFLARENET - Cloudflare, Inc., US |
| Location | South Brisbane, AU |
| Edge colo | — |
| Datacenter | ✓ yes |
| China cloud | ✗ no |
| VPN | ✗ no |
| Proxy | ✗ no |
| Residential proxy | ✗ no |
| Tor | ✗ no |
| Mobile network | ✗ no |
| Anycast/broadcast | ✓ yes |
| Abuse reputation | none (0.00%) |
| Signals used |
|
Accept: application/jsonHigh-volume API? Get a free key (100 req/day) at account.leeguoo.com · How bans work: the three things Claude checks — region, IP, request fingerprint
Privacy · Contact
🔎 Browser-side checks (run locally, never uploaded)
What is IP purity
IP purity measures how much an IP looks like a real residential user to anti-fraud and multi-account risk systems. The stronger the datacenter/hosting ASN or public VPN/proxy signature, the lower the purity — and the more likely a login from it triggers verification or a ban.
Reading the four bands
- Clean: mostly residential/mobile networks; risk systems rarely pay extra attention.
- Light / medium: some datacenter or proxy signature; some platforms add verification.
- High risk: typical datacenter / public VPN / proxy exits; multi-account logins get restricted or banned easily.
How the score works
The score combines whether the ASN belongs to a datacenter/hosting provider, whether the org name matches VPN/proxy keywords, anycast status and more — without calling third-party risk APIs that rate-limit or fingerprint back. To understand how detectors spot automation and proxies, read why a real browser isn't flagged as a bot.
Local self-check: signals a website can't read but risk systems do
The checks above cover the IP and browser layers a website can measure for you. But account-risk systems also read things off your machine — the system proxy, shell env, tool config — that no website can physically see. Run these in a terminal; clear anything that isn't empty / 0 / null:
# 1. System proxy (should be all 0 — otherwise you're on "system proxy", not TUN mode)
scutil --proxy | grep -E "HTTPEnable|HTTPSEnable"
# 2. Leftover env vars (should print nothing)
env | grep -i proxy
# 3. Egress IP and country (country should be US)
curl -s ipinfo.io | grep -E '"ip"|"country"|"org"'
# 4. System timezone (should be Asia/Taipei, not Asia/Shanghai)
node -e "console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)"
# 5. Relay residue: ANTHROPIC_BASE_URL (easiest to miss, should be empty)
echo "$ANTHROPIC_BASE_URL"
env | grep -iE "anthropic|claude" # broad — catch CLAUDE_* / API_KEY targets
grep -RiE "ANTHROPIC_BASE_URL|HTTPS?_PROXY" ~/.zshrc ~/.bashrc ~/.zshenv ~/.profile ~/.npmrc ~/.gitconfig 2>/dev/null
# 6. Claude Code's own config (env.ANTHROPIC_BASE_URL often hides here)
grep -iE "base_url|proxy|anthropic_" ~/.claude/settings.json 2>/dev/null
# 7. npm / git config (command-level — a proxy can be set outside the dotfiles)
npm config get proxy; npm config get https-proxy
git config --global --get http.proxy; git config --global --get https.proxy
The mechanism is explained in the three things Claude checks — region, IP, request fingerprint.