Has this address been reported for abuse?
Check any address against reports filed by operators running real infrastructure. See what it was reported for, how often, and how much weight those reports actually carry.
Result
185.220.101.34
Brandenburg, Germany · TORSERVERS-NET · Data Center
Pre-filled with a known Tor exit node. Type any address to check its abuse history.
Behind every check
19.8 million
IP addresses profiled
2.4 million
malicious domains tracked
208,000
disposable email domains
1.9 million
networks scored
Counts read live from the engine, not written into the page. The full dataset is published on GitHub under the MIT license and rebuilt every 30 minutes.
What an abuse report actually tells you
A report is somebody saying an address attacked them. That is evidence, not proof, and the gap between the two is the central problem with community abuse databases: filing a report costs the reporter nothing, which is exactly why unweighted report counts get gamed.
The category
What the address was reported for: brute force, credential stuffing, web attacks, port scanning, spam, phishing, scraping, or command-and-control traffic. Categories matter more than counts, because a research scanner and a phishing host call for entirely different responses.
How many independent reporters
One reporter filing forty times is one opinion repeated forty times. Forty reporters filing once each is a pattern. We count reporters, not reports.
Reporter trust
Reports are weighted by a trust tier the reporter earns through a track record, not one handed out at signup. A new account cannot arrive and outvote operators who have been filing accurate reports for a year.
Recency
Abuse from two years ago and abuse from this morning are different facts. Both are shown, and they are never merged into one number.
Why we need two sources before listing anything
An address only enters our abusive list once it has been independently confirmed at least twice, from genuinely separate origins: our own honeypot sensors and community reports, or multiple threat feeds that are not republishing one another. That last clause catches a trap most aggregated lists fall into, where a single upstream source reappears under six different names and one opinion is presented as a consensus. Confirmation that is not independent is not confirmation.
Reporting an address yourself
If something is attacking you, reporting it is the part that makes a shared database worth having. Reports feed the same engine that answers this page, the free API, and the published dataset, so a report you file today protects people you will never meet.
What makes a good report
The category, and evidence. Log lines with timestamps beat a description every time, because they let someone else verify what you saw.
What happens next
Reports are weighted by your trust tier and cross-checked against what our own sensors observed. Corroborated reports move the score; isolated ones sit as evidence without moving it on their own.
Corrections count too
If an address on the list should not be, say so. Addresses get reassigned constantly, and a list that only ever grows is a list slowly becoming wrong.
What an abuse history looks like.
Live results, fetched as this page loaded. Clean answers are included on purpose: they are the majority.
185.220.101.34
100/100 · critical
tor-exit-34.for-privacy.net · Tor, VPN, proxy, datacenter
Confirmed from multiple independent directions. This is what agreement across separate evidence looks like.
45.148.10.121
100/100 · critical
no PTR record · Tor, datacenter
Confirmed abusive with nothing in its naming to give it away, which is the normal case rather than the exception.
8.8.8.8
5/100 · none
dns.google · datacenter
No abuse history. Worth checking a known-good address occasionally to see what a clean answer looks like.
1.1.1.1
5/100 · none
one.one.one.one · VPN, datacenter
Anonymising infrastructure with effectively no abuse behind it. Being shared is not the same as being abusive.
52.95.110.1
10/100 · none
no PTR record · datacenter
Nothing reported and nothing observed. An empty result is a real answer.
Every verdict above was fetched from the engine when this page loaded. Nothing here is a screenshot or a stored example, so if a number looks surprising, that is what our data actually says right now.
How this differs from AbuseIPDB
AbuseIPDB defined this category and remains the reference point, so the honest comparison is about how the evidence is weighted rather than about who has more of it.
| ffraud | AbuseIPDB | |
|---|---|---|
| How reports are counted | Weighted by a reporter trust tier earned through a track record | Confidence score driven largely by report volume and reporter age |
| Bar for listing | Two genuinely independent confirmations before an address is listed | Reports are published as they arrive |
| First-party evidence | Our own honeypot sensors contribute directly | Community reports are the primary source |
| Bulk access | Entire database on GitHub under MIT, rebuilt every 30 minutes | Available through the API, with plan limits |
| Cost of the basic check | Free, no key, no account | Free tier with a daily check allowance |
If you already have an AbuseIPDB integration that works, there is no reason to tear it out. We also expose an AbuseIPDB-compatible endpoint so you can point an existing client here without rewriting it.
Questions people ask
How do I check if an IP has been reported for abuse?
Paste it into the box at the top of this page. You get whatever abuse history we hold: what the address was reported or observed doing, how recent that activity is, how much of its surrounding network is flagged, and the score those signals produce. No account is needed to look anything up.
How is this different from AbuseIPDB?
The core idea is the same and we make no secret of that. The differences are that reports here are weighted by an earned reporter trust tier rather than counted flat, an address needs two genuinely independent confirmations before it is listed at all, and the resulting database is published in full on GitHub under the MIT license rather than being reachable only through a metered API. We also run our own honeypot sensors, so part of the evidence is first-party rather than reported to us.
Someone reported my IP unfairly. What now?
Tell us, and we will look at the evidence behind it. Every entry records what put it there, so this is a conversation about specifics rather than an argument about opinions. Bear in mind that reports about shared infrastructure such as VPN endpoints and carrier-grade NAT are often accurate about the address and completely unfair to you personally, which is exactly why we publish infrastructure type alongside the verdict.
Does reporting an IP block it?
No. We publish intelligence; we do not sit in anyone's traffic path and we cannot block anything. What a report does is contribute evidence that other operators can weigh in their own systems, against their own thresholds.
Can I download the abuse data instead of calling an API?
Yes. Every address that has passed the confirmation bar is published in one CSV on GitHub under the MIT license, rebuilt every 30 minutes, carrying the score, the confirmation count, the threat category, and the infrastructure type on each row.
Other free tools
IP blacklist check
Check any IPv4 or IPv6 address against our abuse database. See if it is listed, why, and how recently.
Free IP lookup
Owner, network, autonomous system, reverse DNS, and approximate location for any address.
IP reputation
A 0 to 100 fraud score for any IP address, with every signal that produced it shown in the open.
Do it in code.
The same answer from a free API endpoint, or download the whole database and never call an API at all. No card, no quota, no expiry.