A high IP score is a claim. Ask what evidence produced it.

Which findings explain the score I was shown?

IPJury explains its own versioned policy index through the visible evidence axes and exclusions. Use those facts to question an outside score, without assuming that another vendor uses the same inputs or rules.

Source availability depends on the current deployment and each returned record. These review dates do not establish when a particular IP was observed. Method axis-scope-2026-09-15 · Score ipjury-score-v3.

Some site told you an address is "high risk" and gave you a number instead of a reason. Before acting on it, work out which claim produced it — "risk" is not one measurement but several compressed into a word.

Five questions, in order

1. Check the network role first. A network-role prior can explain part of a score; check the displayed method before assuming it is the cause. If the address belongs to a hosting provider, many classifiers raise their output on that basis alone, before looking at anything the address has done. That is a defensible choice for a platform blocking bulk automation, and a poor diagnosis for someone running a personal server. Establish the role, then ask whether the figure survives once you set it aside. Do not assume that no other issue remains: an outside system may use evidence this record does not contain.
2. Look for a record against the exact address. There is a large difference between a source holding a report about 203.0.113.45 and one holding reports about other addresses in 203.0.113.0/24. The first is evidence about your address; the second about your neighbours, inherited because you share a prefix that may hold thousands of unrelated customers. A tool that cannot tell you which you have is not showing you evidence.
3. Separate anonymity from abuse. A proxy, VPN, or Tor finding describes how traffic is transported. An abuse record states that something was observed and reported. Many scoring systems fold both into one figure, so an address whose entire "risk" is "this is a VPN endpoint" reads identically to one with a spam history. Those call for different responses, and the number hides which you have.
4. Check freshness and dataset vintage. Every finding has an age, and addresses change hands constantly. A block reassigned last quarter carries the previous tenant's labels until each dataset refreshes on its own schedule, and mobile addresses may serve a different subscriber within hours. A record with no timestamp, or older than the address's likely tenancy, is a historical note rather than a description of it now.
5. Account for causes that are not the address. If the symptom is a CAPTCHA loop, a declined sign-up, or a verification prompt, platforms weigh signals no IP tool can see: account age, payment history, device fingerprint, browser configuration, behaviour. An address-level explanation covers address-level friction; assuming it covers everything sends people chasing a problem they do not have.

What to do with the answer

Once decomposed, the useful outcomes are narrow but real.

• If the finding is a role prior only. The observed role is not itself an abuse event. Ask the service about its network policy without asserting that all other causes have been excluded.
• If the finding is prefix-inherited. The record belongs to the range. Ask the operator who controls the range and follow the named source’s process; quote the exact scope rather than substituting a score.
• If there is a direct exact-IP record. Now you have something specific: a named source, a date, a claim. Go to that source's own dispute or delisting process — using the procedure that operator actually publishes.
• If a record looks wrong. Bring the disputed claim and a public source that contradicts it. Evidence changes an evidence record; screenshots of unexplained numbers do not.

One caution: no IP evidence record, including this one, can promise a platform will change its decision. Platforms do not publish their inputs. The evidence documents possible IP-side contributors. It cannot establish or exclude the address as the cause of that platform’s decision.

If two tools gave you different answers about the same address, see why IP scores disagree.