Data sources
- ipapi.is: who operates the IP and network (ISP, hosting, business, education…), plus proxy, VPN, Tor, abuse and crawler flags.
- DB-IP Lite: country, city and ASN, used under CC BY 4.0.
- MaxMind GeoLite2: country and ASN, counted as an independent voice in the location-agreement comparison.
- Shodan InternetDB: open ports and CVE associations observed on the public internet (refreshed weekly, not a live scan), shown as exposure evidence only — it does not affect the score.
- IPLocate: privacy flags (VPN / proxy / Tor / iCloud Private Relay / abuse reports) and the hosting provider name, shown as evidence only — they do not affect the score.
- X4BNet public lists: known datacenter and VPN ranges.
- Tor Project: Tor exit node list.
- FireHOL level1: public abuse ranges.
- DNS blocklists: SpamCop, PSBL, UCEPROTECT L1, DroneBL and s5h, queried live.
- RDAP registry data: network name, registrant, abuse contact and remarks, via rdap.org to the regional registries.
- Reverse DNS (PTR): the IP itself, plus one in every 8 addresses of the same /24 (32 in total).
- proxycheck.io: used in two places — (1) it can provide the second source that confirms a proxy flag; (2) it is the fallback for typing an IP when the main source is unavailable. On its own it does not drive region conclusions (in our tests it labels some home-broadband pools as business and cloud servers as VPN).
- PeeringDB: the network’s self-declared type. Reference only — large home-broadband ISPs often register as backbone networks, and cloud providers sometimes as “enterprise”.
Results for the same IP are kept for 24 hours. The online source has a daily quota; once it runs out we judge from public lists only and label the result “reduced”.
How the IP type is decided
Step 1: database verdict
The first matching row decides the initial verdict:
| Order | Condition | Verdict |
|---|---|---|
| 1 | Flagged as a VPN or Tor exit by ipapi.is or a local list (stands on its own) | Proxy / VPN |
| 1b | Flagged as a proxy and a second scoring source agrees | Proxy / VPN |
| 2 | Flagged as datacenter, or operated by a hosting / cloud company | Datacenter IP |
| 3 | Flagged as mobile network | Mobile network |
| 4 | Operated by an ISP | Residential IP (then checked in step 2) |
| 5 | Operated by a business, school, government or bank | Business line |
| 6 | None of the above | Undetermined |
Step 2: double-check with registry data and reverse DNS
IPs judged residential, business or undetermined are checked against two kinds of public evidence, in this order:
| Evidence | New verdict |
|---|---|
| Reverse DNS looks like servers or cloud (ec2-…, vps…), or registry data points to an IDC / datacenter | Datacenter IP |
| Reverse DNS belongs to a business ISP (e.g. MegaPath) | Business line |
| Databases say residential, but neither the IP nor its /24 shows home-broadband pool naming (adsl-…, pool-…, cm…) | ISP IP |
| Undetermined, but reverse DNS shows home-broadband pool naming | Residential IP |
Why a proxy flag needs a second source
One data source calling an IP a proxy is not enough on its own — we have measured home connections being mislabelled by one provider. So:
- Two or more scoring sources agree on proxy / VPN: judged as a proxy and scored as one. (“Scoring source” means a source used for the proxy verdict and the score; display-only sources such as IPLocate are not counted.)
- Only one scoring source flags it: still listed under Evidence, but costs only 10 points; the type follows the line's own attributes.
- Datacenter is not proxy evidence: a hosted IP tells you it is hosted, not that it is used as a proxy.
- Exception: when proxycheck returns
type=VPNit is not treated as a proxy — in our tests it labels ordinary cloud servers as VPN, so that case only feeds the type fallback (datacenter) and plays no part in the proxy verdict.
Anonymity signals take the highest, not the sum
Proxy, VPN and Tor are the same family of signal. When one IP matches several, only the highest deduction applies. Every individual flag still appears under Risk checks so you can weigh them yourself.
When the type cannot be determined
If none of the type-judging sources provides enough type evidence, the IP is marked type not confirmed: the score is still computed, but no grade is issued and no “Clean IP” seal is shown — “nothing to deduct” does not mean “clean”. A proxy flag from only one scoring source with no type evidence is stated explicitly rather than folded into that bucket.
When the IP itself has no reverse DNS we use the naming type shared by more than half of the 32 sampled neighbours. Missing reverse DNS is never counted against an IP. The “Evidence” section of each result lists every item and says whether the verdict changed.
“ISP IP” means the address belongs to an ISP network, but we found no public evidence that it is home broadband. It may be, or it may be sold to a business or a datacenter. Different checkers use different sources, so verdicts for the same IP can differ.
Native IP vs broadcast IP
We compare the country in the whois address of the IP’s range with the country the IP is located in. The same country means a native IP; different countries mean a broadcast IP — typically a range registered in one country and announced for use in another.
Purity score
Start at 100 and subtract, down to 0:
| Finding | Points |
|---|---|
| Datacenter IP | −25 |
| Proxy flag (confirmed by two or more scoring sources) | −30 |
| Proxy flag (only one scoring source, not cross-confirmed) | −10 |
| VPN flag | −30 |
| Tor exit | −50 |
| Abuse record | −25 |
| Crawler flag | −10 |
| Each DNS blocklist hit | −10 (max −30) |
Broadcast IPs and line-location mismatches do not reduce purity. They show that the range’s registration and its actual location disagree, which does not prove the IP is abused and does not prove it is a static residential / ISP proxy. They appear separately under “line and geolocation consistency” and affect region checks only.
Grades: 95+ A+, 85+ A, 70+ B, 50+ C, 25+ D, otherwise F. When a core source is missing or stale, the grade is capped by evidence completeness and the reason is printed next to the score.
Why nothing scores 100
An IP with no risk deductions still does not get a perfect score: 1–5 points are held back according to how strong the evidence is. These are headroom, not deductions. Public data can show that nothing was found, not that nothing is wrong.
| Reason | Points |
|---|---|
| Blind spot of public data (how a platform labels the IP internally, who used it before; no checker can see these) | −1, every IP |
| ISP IP: belongs to a carrier, but no home-broadband evidence | −2 |
| Business line | −2 |
| Mobile network: many users usually share one exit | −1 |
| 5 or more devices used this IP on this site in the last 7 days | −2 |
So a risk-free IP lands between 95 and 99 and is still graded A+; a residential IP with home-broadband evidence and no sharing tops out at 99. As soon as any risk deduction applies, no headroom is added and the score follows the deduction table above. Headroom does not apply to IPs whose type is unconfirmed; they get no grade anyway.
How use-case fit is scored
TikTok and gaming need very different things from an IP, so each use case has its own deductions from 100: 80+ is “Suitable”, 55–79 “Usable, may be challenged”, below 55 “Not recommended”. This is a fit score, not a success rate — platforms also weigh your account, device and behaviour.
| Deduction | TikTok | E-commerce stores | Social accounts | Streaming | Payments | Gaming |
|---|---|---|---|---|---|---|
| Datacenter IP | −50 | −30 | −30 | −50 | −30 | −10 |
| Flagged as proxy / VPN | −40 | −40 | −35 | −40 | −45 | −15 |
| Tor exit | −60 | −60 | −50 | −60 | −70 | −60 |
| Abuse history | −25 | −30 | −30 | −5 | −35 | −20 |
| Per blocklist (max 3) | −5 | −5 | −5 | — | −10 | — |
| Type unclear | −10 | −10 | −10 | −10 | −10 | — |
| Business line | −5 | — | — | — | — | — |
| Shared by many | −20 | −25 | −15 | −10 | −15 | — |
What each use case weighs most: TikTok — IP type, proxy flags, sharing on datacenter lines; E-commerce stores — sharing on datacenter / business lines (account linking), proxy flags, abuse; Social accounts — proxy flags, abuse; Streaming — datacenter / proxy (blocked as proxies), region limits; Payments — proxy / Tor, abuse, blocklists; Gaming — mostly latency (not measured here); IP type matters less.
Regional hard limits are not scored — they are “Not recommended” outright: TikTok does not serve mainland China (Douyin instead), Hong Kong (left in 2020) or India (banned since 2020); Netflix and Disney+ are not offered in mainland China, and Netflix suspended service in Russia in 2022.
Shared by many only applies to datacenter, proxy and business lines: many customers may sit behind one exit, so the account-linking risk is real. Homes and mobile networks with 2–4 devices are normal and are not scored. The home-page check stores “exit IP, date, device hash” (derived from UA and language plus a site secret, not reversible, deleted after 8 days). 5+ different devices on the same exit within 7 days counts as shared. The count only covers IP Judge visitors, so it errs low.
Corrections
If you think a verdict is wrong, submit a correction at the bottom of the IP page. Each one is reviewed by hand; confirmed corrections change the verdict, and the IP’s evidence cites the correction number. All corrections and outcomes are public under Corrections.
ChatGPT, Claude and Gemini suitability
Each company publishes its own list of available regions, and the lists differ. We judge each platform against its own list (checked item by item on 30 September 2026):
- ChatGPT: OpenAI’s list, 208 regions.
- Claude: Anthropic’s list (Claude.ai section), 185 regions.
- Gemini: Google’s list, 240 regions. Mainland China is Workspace-only and not counted for personal accounts.
- Gemini API / AI Studio: Google keeps a separate API list (229 regions, checked 1 October 2026) that leaves out Hong Kong, Macau, Myanmar and a few French and Dutch territories. Judged on its own, by region only — calling the API from a server is normal, so the IP type doesn’t count.
Common examples: mainland China is supported by none of the three; Hong Kong and Macau only by the Gemini web app, not the Gemini API; Russia, Iran, North Korea, Cuba, Syria and Belarus by none.
Once the region is on the list, the network type decides: proxy / VPN is not suitable; a datacenter IP works but gets challenged more; residential, mobile, ISP IPs and business lines are suitable.
The home page also asks claude.ai and chatgpt.com directly which IP they see — proxy apps often route by domain, so these can differ from the IP that opened this site. Gemini offers no public way to read the IP it sees, so the home page only checks whether it is reachable.
How Muse sign-up is judged
Muse is Meta’s AI agent. Meta hasn’t published a full list of markets, so we only use the two with first-hand sources: the US (launched 8 September 2026) and Canada (Canadian App Store listing on 18 September; the terms’ arbitration clause names “US or Canada”). Everywhere else is treated as not open.
- Exit in the US / Canada on a residential, ISP or mobile network: can use.
- Business line: depends (varies with the ISP’s reputation).
- Datacenter IP or flagged proxy / VPN: not usable. This follows user reports (VPN nodes and datacenter IPs often land on the waitlist), not an official Meta statement.
Muse offers no public way to read the IP it sees, so the home page judges the exit that opened this site. Only on the /en/muse/ page does a Muse “not usable” count as an issue.
Claude / Muse readiness checklist
The /en/claude/ and /en/muse/ pages no longer show a second 0–100 score. They list the network conditions this visit can verify. Each item is marked “Pass / Check / Fail / Not verified”; anything not measured is “Not verified”, never a default pass.
| Item | Claude (/en/claude/) | Muse (/en/muse/) |
|---|---|---|
| Exit region (hard rule) | On Anthropic’s list ⇒ Pass; off the list, Hong Kong, Macau or mainland China ⇒ Fail | US / Canada ⇒ Pass; anywhere else ⇒ Fail (the sign-up goes to the waitlist) |
| IP type | Home / ISP / mobile / business ⇒ Pass; datacenter ⇒ Check; proxy / VPN / Tor ⇒ Fail; undetermined ⇒ Not verified | Same; home / mobile has the best sign-up record |
| Risk flags | No hits in the sources checked ⇒ Pass; 1–2 hits ⇒ Check; 3+ ⇒ Fail | Same |
| claude.ai exit | Same as the exit that opened this site ⇒ Pass; different ⇒ Check; not measured ⇒ Not verified | — (Muse has no public exit-reading endpoint) |
| Anthropic domains | claude.ai, api.anthropic.com and platform.claude.com share one exit ⇒ Pass; different ⇒ Check; not measured ⇒ Not verified | — |
| DNS / WebRTC | No leak ⇒ Pass; China STUN only, DNS to China, or unlisted domains direct ⇒ Check / Fail | Same |
| Time zone and language | Time zone matches the exit region and TLS matches the UA ⇒ Pass; China time zone or TLS mismatch ⇒ Check | Same; a time zone in the Americas is better |
| Automation | No webdriver, headless or UA tampering ⇒ Pass; detected ⇒ Fail | Same |
The checklist only assesses the network and browser this visit exposes, not the account itself (phone number, payment method and history can’t be seen from outside). Platforms don’t publish their rules; passing every network item still does not guarantee an account can sign in or chat — platforms also weigh the account, device and behaviour.
Claude’s exit is the IP claude.ai reports directly; Muse has no such interface, so it uses the exit that opened this site.
Terminal exits (Claude Code / Codex)
curl -sL ipjudge.org/en/cc | bash reads the IP from the diagnostic addresses of api.anthropic.com, claude.ai, api.openai.com and chatgpt.com, honouring HTTPS_PROXY-style variables just like Claude Code and Codex, and works out the proxy each one actually uses (Claude Code ignores ALL_PROXY and SOCKS; Codex also reads ~/.codex/.env); it then takes a --noproxy reading for comparison and checks whether the macOS system proxy is on but unused by the terminal. It is read-only; see the source at /en/cc.
Separate IPv4 and IPv6 checks
The home page contacts one IPv4-only and one IPv6-only address (Cloudflare’s diagnostic page) and reads both exits. If the IPv6 exit is in a different region from IPv4, IPv6 traffic is taking another route — and many sites prefer IPv6, so that is the exit they see.
DNS leaks, exit for unknown domains, TLS / TCP fingerprints
These checks run on a separate probe server that sits outside the CDN, so your connection reaches it directly:
- DNS resolvers: the page loads a few random subdomains nobody has looked up before (
random.t.ipjudge.org). Your resolver has to ask our authoritative DNS, so we see its IP — and sometimes the subnet it forwards on your behalf (ECS). An exit abroad with a resolver in mainland China is a DNS leak: your ISP sees the domains you visit, and answers may be polluted. - Exit for unknown domains:
t.ipjudge.orgis in nobody’s proxy rules. In rule mode, unlisted domains often fall through to DIRECT, and this row then shows your real IP. - TLS fingerprint: the browser’s ClientHello is hashed per the JA4 spec. Each browser engine has a stable fingerprint; one that doesn’t match the User-Agent usually means a spoofed UA or a tool re-doing TLS for the browser.
- TCP fingerprint: the SYN packet’s TTL and TCP option order tell whether the connection comes from Windows, macOS / iOS or Linux / Android; the MSS gives the MTU, and a small MTU is typical of tunnels and VPNs. Behind a proxy, this shows the proxy server’s system — one of the signals sites use to spot proxies.
The probe keeps the “random name → resolver” mapping for 10 minutes, in memory only, never on disk.
What we cannot promise
Platforms also weigh your account, device, payment method and usage. IP Judge only checks the network side; a result is not any platform’s final decision.