IP checker

How this check works

Paste an IPv4 or IPv6 address, or a hostname, and press check. Leave the box empty to check your own connection. The address goes through the same profile as the IP lookup, which gives us its location, its autonomous system and its network classification, and then through a round of checks that the lookup does not run by default:

1. Tor exit list. We download the list of current Tor exit addresses from the Tor Project every day and match the address against it.
2. Spamhaus DROP. The Don't Route Or Peer list names address ranges that Spamhaus considers hijacked or operated by criminal networks. It is small, updated daily on our side, and a match is decisive.
3. Datacenter and VPN classification. The address is matched against a published list of datacenter ranges, and its network's name is compared with hosting and VPN provider keywords. This is the same classification you see on every page, and the result page shows which rule fired.
4. 8 DNS blocklists. We send one query per list, reversing the address octets as the lists require, and read the answer code. Each list that returns a listing is shown with the reason it gives, for example an exploited host or a spam source. Results are cached for 1 hour.

The verdict is computed from those checks with fixed rules, printed below, so two people checking the same address at the same time get the same answer, and you can tell exactly which fact produced it.

How to read your result

Private and reserved addresses, such as 192.168.1.1, are reported as clean with a note, because they are never routed on the internet and no list contains them.

Under the verdict you get the reasons as plain labels, the full blocklist table with one row per list, and the usual profile: location, network, prefix, hostname and classification. Read them together. A hosting address with no listings is a server that nobody has complained about, which is fine for a website and poor for a social login. A residential address with one listing is usually a home connection whose previous holder ran malware; it will pass most sites but may bounce at mail servers.

Two listings on a residential address deserve a closer look at the reasons. A listing from a policy list that marks whole dynamic ranges as "end-user, should not send mail directly" is not an accusation against you; it is the ISP's own statement that the range is for consumers. A listing from a list that records exploited hosts or active spam sources is an accusation, and strict sites treat it as one.

The 8 blocklists we query

All 8 are queried over DNS, which is the way mail servers and signup forms consult them too. The Spamhaus lists refuse queries relayed through public resolvers, so they are asked from our own resolver; if that resolver is unavailable the row says so rather than reporting a false negative.

How to fix it

If the address is your own home or mobile connection:

1. Read the reasons. A policy listing for a dynamic range needs no action. An exploited-host listing means a device on your network sent spam or scanned the internet; run a malware scan on every device, including phones, smart TVs and anything with a web interface.
2. If your address is dynamic, restarting the router after a few minutes often gives you a different one, which sidesteps a listing left by a previous subscriber.
3. For a listing you need removed, open the list's own page from the result table. Most lists remove an address automatically once the abuse stops, within a day to a few weeks; some offer a removal form.

If the address is a proxy or VPN exit you plan to use for logins:

1. A caution verdict for hosting or VPN provider cannot be fixed on your side. Ask the provider for a residential or mobile pool, or choose a different exit, and check again.
2. A caution verdict for a single blocklist on a residential address is often tolerable for web logins and not for email. Check what the listing says before discarding the address.
3. A risky verdict means discard the address for anything that matters. Tor exits and DROP ranges are blocked at the edge by many services before any login page loads.
4. When the verdict is clean, continue with the anonymity score from the browser profile you will use. The IP is only the first of the signals a strict site looks at.

If the address is a server you operate:

1. Find the source of the listing: a compromised web application, a mail form without rate limits, a customer on a shared host, or an outbound scanner. Fix it first; delisting without a fix leads to a quick relisting.
2. Set up a PTR record and valid SPF, DKIM and DMARC if the server sends mail, then request removal from each list through its own process.
3. Re-check after an hour, when our cache expires, to confirm the removal propagated.

Limits of this check

• 8 lists are not every list. There are hundreds of DNS blocklists and many private reputation feeds. We query the 8 that are most widely consulted and free to query; a site using a commercial fraud database may know things we do not.
• Blocklists are IPv4 only here. Most DNSBLs do not publish IPv6 data, so IPv6 addresses are checked only against the Tor list, the DROP list and the classification rules.
• Classification is a heuristic. Hosting and VPN detection rely on a datacenter range list and keywords in the network name. Some hosting providers use neutral names and slip through; some consumer ISPs have a hosting arm under the same name and get flagged. The reasons are printed so you can judge.
• Lists change constantly and we cache for 1 hour. A listing or removal in the last hour may not show yet.
• A verdict is about the address, not the browser. Time zone mismatches, WebRTC leaks, DNS leaks and automation signals are scored separately by the proxy checker and the anonymity score.
• No reputation history of our own. We do not keep a record of what an address did last month; each check reads the public lists as they stand today.

Why is a clean IP still blocked by some sites?

Because the address is only one input. A site that challenges you after a clean verdict here is usually reacting to something else: a browser time zone that disagrees with the IP's country, a datacenter IP that our classifier missed but theirs caught, a commercial reputation score built from the address's behavior across many sites, cookies or device data left over from an earlier session, or the account's own history. Large platforms also rate addresses by how many distinct accounts have used them; a residential proxy address shared by many customers can be clean on every public list and still be rated poorly. The sequence that catches most of these before a login is: IP checker, then the anonymity score with the browser signals loaded, then the DNS leak test and WebRTC leak test, all from the same browser profile.

Checking an IP before you log in

The IP checker answers the first question in that sequence: is the address itself acceptable? Do it before you spend time on anything else, because no browser setting repairs a bad address. Aim for a clean verdict on a residential or mobile network in the country the account expects. Then look at the hostname on the result page; a PTR name that spells out a VPN or hosting brand is read by the same filters that read the lists. Finally, note the prefix size: a very small block announced by a non-ISP network is typical of leased ranges that get flagged as hosting even when the registry record says residential.

Checking a list of proxies

The form takes one address at a time, by design, since each check triggers 8 live DNS queries. For a batch, use the JSON API: request the lookup endpoint with the blacklists parameter and you receive the same classification, flags and blocklist summary as this page, 60 requests per minute without a key. The verdict rules above are deterministic, so you can reproduce them in your own script from the returned fields.