Use the proxy checker with a specific question
A proxy checker helps explain why an IP address appears in a network list. It does not look inside your device, read your VPN settings or prove how every application connects. Start with the address that matters to your question, then compare the separate observations instead of treating one label as a final verdict.
Enter one public IPv4 or IPv6 address in the proxy checker. Do not add a URL, port number, subnet prefix or domain name. Private, loopback and documentation addresses cannot identify a public exit and are rejected. If you have a hostname, resolve it with hostname lookup first and inspect the relevant returned address.
Choose Use my IP to fill the address this site observes. That action does not run the proxy checker automatically. Read the disclosure, then choose Check sources. An address observed by this site can differ from the address used by another destination, another browser, an application or a separate IPv6 connection.
The proxy checker sends the chosen address to this site's lookup service. Source providers receive downloads of their public catalogs, without your entered address in those requests. This tool does not connect to the target, test its proxy ports or send traffic through a listed server. Looking up an address is distinct from probing it.
The proxy checker returns four source cards: a VPN network list, a broader hosting/VPN list, public proxy observations and Tor exit observations. Each card keeps its status, source date and evidence separate. Several cards may match because the categories overlap; their agreement does not turn a network association into proof of present use.
If a lookup takes too long, use Stop. The proxy checker discards the pending report; a later response cannot restore it. Shared source refreshes may finish independently because other lookups can use that public data. Clear removes the address and report, and editing the input invalidates evidence for the previous address.
Read each proxy checker result on its own
Listed evidence found means the proxy checker found the address, or a containing network, in that named snapshot. The matched value explains which of those happened. A CIDR range identifies a block of addresses; an exact address identifies a published endpoint or observed exit. Neither establishes which person used that address.
No listing in this snapshot means the proxy checker searched usable data for a supported address family and did not find a match. It is a limited negative result. New services, private tunnels, residential relays and recently reassigned addresses may be absent. Avoid translating this status into “definitely residential,” “not a VPN” or “safe.”
Address family not covered means the proxy checker has no corresponding IPv4 or IPv6 evidence in that source snapshot. It is not a failed IPv6 connectivity test. Your IPv6 connection can work normally even when a particular list contains only IPv4 observations. Use the separate IPv6 test to check browser connectivity.
Source evidence unavailable means the proxy checker could not obtain usable evidence. A source may be unreachable, rate limited or malformed. This state cannot support either a positive or a negative classification. Other cards can still provide useful observations, so read the completed cards without assuming that the missing source would agree.
Snapshot too old to classify means the proxy checker has retained an earlier source version for context but will not use it for a current membership verdict. Source dates remain visible. This is different from a freshly downloaded file that contains old observations: downloading a snapshot again does not make its publication date newer.
If a refresh fails while the previous snapshot remains within its allowed age, the proxy checker can display that snapshot with a refresh notice. Its original publication and download times stay attached. Once the age limit is exceeded, classification stops. A refresh failure never changes old evidence into a newly verified observation.
What the four sources actually describe
The VPN card in this proxy checker uses X4B's VPN network list. The publisher combines known VPN netblocks and network ownership information. These are ranges, not an inventory of every active tunnel endpoint. Shared infrastructure and address reassignment can make a matching range less specific than its name suggests.
The broader card in the proxy checker uses X4B's datacenter list, which includes both VPN and datacenter networks. It does not provide an independent hosting-only verdict. A server in such a range might host a website, mail system, business application or VPN endpoint. The card therefore retains both categories in its title.
The public-proxy card uses monosans' published observations. The proxy checker distinguishes the connection endpoint from the exit address that a destination saw. Those values can differ. A listed endpoint is where a client connects; an observed exit is where forwarded traffic emerges. The tool reports the applicable role instead of silently substituting one for the other.
The Tor card in the proxy checker uses Onionoo exit observations. The selected feed describes IPv4 addresses observed exiting from running exit relays within the previous 24 hours. Relay listening addresses are not substituted for exit observations. This source does not provide a corresponding IPv6 exit-membership verdict here.
These public datasets serve different purposes. The proxy checker keeps them independent because a network range, a checked proxy endpoint and a Tor exit observation are different forms of evidence. Combining their labels into one unexplained risk number would hide those differences. A Tor or VPN association is not itself evidence of abusive behavior.
Source dates and update behavior
The proxy checker displays two dates for a usable snapshot. Published identifies the source version's time; for GitHub lists this is the last commit time for that data file. Downloaded records when this site retrieved the corresponding file. These dates describe the snapshot, not the moment every address was individually tested.
For GitHub sources, the proxy checker selects the last commit changing the data file and downloads that exact revision. The source link allows you to inspect the same version. This avoids combining a timestamp from one update with a list from another. The displayed revision is a reproducibility reference, not a quality score or guarantee of accuracy.
The proxy checker refreshes VPN and broader network snapshots on demand at most once per hour per source coordinator. Proxy and Tor snapshots refresh at most once per fifteen minutes. These are refresh intervals, not promises about how often a publisher updates its own data. An unused tool does not require continuous polling.
Age limits are separate from refresh intervals. This proxy checker stops classifying network snapshots older than seven days, public-proxy snapshots older than four hours and Tor snapshots older than six hours. These are this site's operating choices for different kinds of data. They do not imply that every record within a younger snapshot remains active.
Concurrent proxy checker requests share source refresh work. A temporary upstream failure activates a retry interval instead of immediately downloading the same file for every visitor. Source files have time, size and structure limits. Partial downloads, unexpected redirects and invalid records cannot quietly become an empty “nothing found” list.
Proxy checker limitations that affect interpretation
A proxy checker cannot prove the absence of a VPN. A privately operated tunnel may use an ordinary cloud server or residential connection without appearing on a public list. Even a commercial provider can add addresses before a catalog updates. The absence of a listing should narrow your investigation, not end it.
A proxy checker also cannot establish that your current browser used a matching service. You might paste a remote server address, a colleague's network or a previous VPN exit. Even Use my IP represents one site's observation at a particular time. The tool does not correlate your traffic across the internet or inspect other applications.
Shared exits complicate a proxy checker result. Carrier-grade NAT, company gateways, public Wi-Fi and commercial VPNs can put many users behind one address. A listing describes the address or its network, not the intent or identity of every user. Do not use a single match as evidence that someone committed misconduct.
Geography is a separate question. This proxy checker does not infer a person's country, precise location or residential status from the four membership cards. Registration country, routing information and geolocation estimates have different meanings. IP lookup explains registration evidence; the homepage labels its own location information as approximate.
An email blocklist is another separate question. The proxy checker does not consult mail DNSBLs or calculate mail deliverability. An address can appear in a VPN range without a mail listing, or appear on a mail list without being a VPN. Use blacklist check for the two specifically supported mail sources and their controls.
The proxy checker does not scan ports or establish whether a listed proxy is reachable now. Public proxies are volatile, and published observations can outlive a service. The existence of a list entry is not a recommendation to connect through that server. This page supplies classification evidence, not a directory of trusted proxy services.
Practical troubleshooting examples
Suppose a website challenges you after connecting to a VPN. Run the proxy checker with the current observed exit and inspect the VPN and broader network cards. A match may help explain the site's classification, but it does not prove that the website uses these same lists or that this was the reason for the challenge.
Suppose only one destination sees an unexpected address. The proxy checker can describe each public address separately, while IP comparison examines destination-specific HTTP observations. Keep the two questions separate: address classification describes a source list, while differing HTTP observations describe the tested requests. Neither alone establishes a complete routing policy.
Suppose the proxy checker lists a proxy endpoint while its observed exit is different. Read the evidence role carefully. The address receiving a connection is not necessarily the address a website observes after forwarding. This is especially relevant when comparing a proxy configuration screen with a browser's public-IP result.
Suppose a service rejects your IPv6 address but every proxy checker card says coverage is unavailable. That does not establish a clean classification. Preserve the address family and observation time, then seek a source that covers that family. Replacing IPv6 with an unrelated IPv4 address would answer a different question.
Suppose the proxy checker shows an old positive match after a refresh problem. Compare the source publication time with the current observation. If the snapshot is still within its age limit, treat it as dated evidence; if it is too old, the tool withholds classification. Repeat later instead of treating an error as an updated verdict.
Questions about the proxy checker
Does a matched result mean my connection is unsafe?
No. The proxy checker reports list membership and observation roles. VPNs, Tor and hosted infrastructure have legitimate uses. The result does not inspect encryption quality, endpoint ownership, software integrity or account security. Investigating a security incident requires evidence about actual behavior and the relevant system, not only a network-category label.
Can I check someone else's public IP?
The proxy checker accepts a public address and compares it with downloaded catalogs. It does not connect to that address or access a device. Still, a result is not a person's identity or location. Avoid publishing an address alongside unsupported accusations, and handle any copied report according to the context in which you obtained it.
Does this tool detect VPN leaks?
The proxy checker classifies one supplied address against specific sources. A leak investigation compares observations that should or should not use a protected path. WebRTC testing, browser IP-family observations and a properly configured DNS observation test answer different parts of that investigation. One listed or unlisted address cannot replace them.
What information is retained or shared?
The proxy checker sends your input to this site, keeps the visible report in the current page and does not maintain a query history. The shared catalog stores public source records rather than visitor lookup addresses. Normal hosting safeguards and access processing still apply, as explained in the privacy policy.
What does copying the report include?
The proxy checker report includes the checked IP, statuses, matched values, source links and timestamps. Review it before sharing because the address may identify your current public connection. A copied report is a dated snapshot; it does not update automatically when a provider removes a record or your connection changes.
Why are there no percentage scores or provider guarantees?
The proxy checker has no representative validation study establishing universal detection accuracy. It therefore does not invent a confidence percentage, promise complete provider coverage or combine different sources into a safety rating. The useful output is the actual evidence: what matched, which source supplied it, when that snapshot was published and what remains unknown.