How to verify a proxy provider's IP sourcing

To verify a proxy provider's IP sourcing, stop evaluating claims and start requesting evidence: the written supply-chain policy, the independent attestation including its exceptions, and the consent disclosure a peer actually sees. Then pick a sample of the vendor's addresses yourself, ask for the acquisition record behind each one, and check any datacenter or ISP ranges independently in the public registries. A vendor with clean supply can answer all of this within a week. A vendor that cannot is giving you an answer too.

Why a sourcing claim is not evidence

Every provider in the market describes its network as ethically sourced. The phrase costs nothing to write, and until recently few buyers asked what stood behind it. That changed when a top-tier residential provider was seized by federal authorities in July 2026 after its network was found to be built on compromised devices. Its customers had contracts, invoices, and marketing copy that said the right things. None of it was evidence.

Checking a proxy provider's IP sourcing splits into two different problems depending on the proxy type:

• Residential and mobile addresses are assigned by consumer ISPs and mobile carriers. The registry will always show the ISP or carrier, whether the device joined through a consented app or through malware. Provenance for these addresses lives in the vendor's own records, so your job is to test whether those records exist and are consistent.
• Datacenter and ISP addresses have provenance that is partly public. Who holds a range, which network announces it, and whether that announcement is authorized can all be checked without the vendor's cooperation.

If you want the underlying concept first, what IP provenance means and why it matters covers it. How residential proxy networks end up built on botnets explains the failure mode this method is designed to catch.

Which documents should you request?

Ask for three documents before you run any test. Their quality, and how quickly they arrive, tells you a great deal on its own.

The supply-chain policy

This is the written rule for how an address may enter the network. A useful one is public, versioned, and specific. It names every permitted acquisition channel (consented SDK partners, direct ISP leases, ranges the vendor registers and announces, hardware the vendor operates) and every prohibited one (malware, bundled installers without knowing consent, compromised routers, botnets, brokers who cannot evidence acquisition, supply resold from other networks, minors' devices).

Check three things. First, whether the channel list is closed: "and other trusted sources" is an open door. Second, whether there is a version history, so you can tell which rules applied when a given address was acquired. Third, whether someone accountable owns it.

The audit attestation, with its exceptions

An independent attestation should state who performed it, the period it covers, which product lines and channels were in scope, and the method. The method matters most. An assessor who reads policies and interviews staff has audited the policy. An assessor who samples live addresses and traces each one to its acquisition record has audited the network.

Ask specifically for the exceptions: the sampled addresses that could not be traced, the partners whose disclosures fell short, and what was done about each. A mature program always has some. An attestation with no exceptions section, or a vendor that will share the summary but not the findings, is weaker evidence than one that shows a handful of resolved failures.

Partner disclosure texts and consent-flow screenshots

For residential and mobile supply, ask for the actual screens a peer sees in each partner app category, in the languages the partner ships. Read them as a user would. The disclosure should state plainly that the device's connection will be used by third parties, appear before anything is activated, sit outside the terms of service rather than inside them, describe the compensation, and show how to switch it off.

Ask as well how the vendor enforces this on partners: the contract clause that requires the disclosure, how partner builds are checked after release, and what happened the last time a partner failed a check.

The random-sample trace test

Documents describe the system. This test checks whether it works for addresses the vendor did not choose.

1. Collect exit addresses yourself. During a trial, send requests through the residential or mobile gateway to an endpoint you control that echoes the client IP, and log each exit address with a UTC timestamp. Collect a few hundred, then choose 10 to 20 at random. Do not accept a list the vendor prepares.
2. Send the list, with the timestamps you observed. For each address, ask for the acquisition channel, the partner (an identifier is fine if names are under NDA), the disclosure version shown, the consent timestamp, the compensation terms, and the device's current status.
3. Set a deadline. Five business days is reasonable. A vendor whose records are real retrieves them with a query. A vendor that needs weeks is reconstructing them.
4. Check internal consistency. The consent timestamp should precede the time you observed the address. The disclosure version should have been live on that date. The partner should appear in the vendor's partner list, and the channel should be permitted by the version of the policy in force at the time.
5. Chase every gap. If 17 of 20 come back traced, ask what the other three were. "Rotated out of the pool" is not an answer. The acquisition record should outlive the device's membership.
6. Keep the results. File them with the vendor assessment so the test can be repeated at renewal and compared.

A minimal collector, with the proxy URL read from the environment and pointed at an echo endpoint you run:

import csv
import os
from datetime import datetime, timezone

import requests

proxy_url = os.environ["PROXY_URL"]
echo_url = os.environ["ECHO_URL"]
proxies = {"http": proxy_url, "https": proxy_url}

with open("exit_ips.csv", "w", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(["observed_at_utc", "exit_ip"])
    for _ in range(300):
        response = requests.get(echo_url, proxies=proxies, timeout=30)
        response.raise_for_status()
        writer.writerow([datetime.now(timezone.utc).isoformat(), response.text.strip()])

PROXY_URL takes the form http://USERNAME:[email protected]:PORT for our network, or the equivalent from whichever vendor you are testing. Use a rotating session so each request exits from a different address.

How to check datacenter and ISP ranges yourself

For static addresses, the public routing system tells you most of what you need. Three lookups cover it.

Registration. RDAP, the structured successor to WHOIS defined in RFC 9082, returns the registered holder of an address block, its allocation type, and its parent block. The IANA RDAP bootstrap file maps each block to the regional registry responsible for it, and the registries redirect queries for each other's space, so any one of them is a workable starting point.

Origin. The BGP origin is the autonomous system that announces the prefix to the internet. Route collectors such as RIPEstat show which ASN originates a prefix today and historically. An RDAP query on that ASN shows who holds it.

Authorization. RPKI records (ROAs) state which ASN the holder of a prefix has authorized to originate it. A valid ROA means the holder signed off on the announcement.

Substitute an address from your sample for the documentation address below, and the origin ASN the second query returns for the documentation ASN in the third:

IP=203.0.113.10

curl -sL "https://rdap.db.ripe.net/ip/$IP" | jq '{handle, name, type, country}'

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" \
  | jq '.data | {resource, announced, asns}'

curl -sL "https://rdap.db.ripe.net/autnum/64500" | jq '{handle, name}'

Read the results against what the vendor claimed:

• Datacenter ranges "registered to us and announced from our own ASN" should show the vendor's legal entity (or a named subsidiary) as the registered holder, the vendor's ASN as origin, and a ROA that validates it.
• ISP addresses leased from consumer ISPs should show the ISP as holder and, usually, the ISP's ASN as origin. That is the point of the product. Ask for the lease agreement or a letter of authorization naming the ranges, and check that the ranges you observed are within it.
• Mismatches that need an explanation include a holder unrelated to either the vendor or a named ISP, an origin ASN that changes from week to week, a range first announced days before your trial, and "ISP" addresses originated by a hosting network. Sub-allocation and leasing are legitimate, but every hop should be documented.

Test that consent can be withdrawn

Consent that cannot be withdrawn is not consent, and it is the property most often missing from supply built on bundled installers. Test it directly where you can.

If a partner app is publicly available, install it on a spare device on a network you monitor. Read the disclosure, opt in, and note the traffic the device begins to carry. Then use the control the disclosure described to opt out and confirm the proxy traffic stops. Uninstall and confirm the same. Where you cannot do this yourself, ask the vendor to demonstrate it and to state the maximum time between a peer's withdrawal and the device leaving the pool.

Claim, evidence, acceptable answer

Use this table in the evaluation itself. Every row is something vendors routinely say about a proxy provider's IP sourcing, and every row can be checked.

Red flags, and answers that should end the evaluation

Some answers are worth a follow-up question. Slow responses, generic screenshots, or an attestation older than a year all fall into that category.

Others should end the evaluation, because they mean the verification cannot be done at all:

• The vendor offers to choose the sample addresses, or will only trace addresses from a "compliance pool".
• Sourcing records are withheld "for competitive reasons" even after an NDA is offered.
• "Our partners handle consent" with no disclosure text or screenshots to show for it.
• The attestation is a self-assessment, a letter from a law firm about policy, or cannot be produced in any form.
• Supply is described as coming from "wholesale" or "upstream networks" without acquisition evidence for each source.
• Datacenter or ISP ranges are held by unrelated parties and there is no lease or authorization to explain why.
• There is no way for a peer to withdraw, or nobody can say how long withdrawal takes.

A procurement team that meets any of these has its answer about that proxy provider's IP sourcing. The broader set of questions that belongs in vendor review is in the proxy provider due diligence checklist.

How ProxyForge answers these questions

We publish a versioned supply-chain policy that names our permitted and prohibited channels. Our sourcing is audited independently twice a year by an assessor who samples addresses and traces each one to its acquisition record; the attestation is available under NDA. Our datacenter addresses are in ranges registered to us and announced from our own ASN, so you can run the registry checks above without asking us anything.

Run the full method against us as you would against any vendor. The sourcing page lists every document and who can read it, and the contact page is the fastest way to request the attestation or send a sample list.