What do residential pool sizes really mean?

As a potential competitor in this space, we recognized a significant transparency issue in the industry. The reporting and measurement methods for residential proxy pool sizes varied widely, making it difficult to make meaningful comparisons. This realization led us to conduct a rigorous, standardized evaluation of different providers.

Even as participants in this industry, we acknowledge that we may have, inadvertently, been part of this transparency issue. It's a reflection we've taken seriously, leading to our initiative to not only adjust our own practices but to also share our findings about other providers.

We believe in fostering a competitive, fair market where decisions are driven by transparent and accurate data. By publishing these results, we're not only contributing to this goal but also demonstrating our commitment to integrity and open communication. Our aim is to create a platform of trust and credibility, where users have access to the most accurate information possible. Please keep in mind, however, that while we strive to maintain objectivity in our research, our findings and analysis are presented from our perspective as a participant in the industry.

We have implemented a systematic approach to test and measure the residential pools of proxy providers. Here's the high-level overview:

• Setting Up Test Parameters: We start with a predefined total number of requests, currently one million, to be sent over consistently over a 24-hour period to each residential proxy provider.
• Connecting to our target: We have setup our own domain to which we connect in order to retrieve the proxy IPs. We did this to minimize data usage.
• Collecting the data: In addition to the basic request and response data, we also keep track of the unique IPs that we successfully connect with during the test, along with other data such as geolocation and latency.

This method ensures that we gather all necessary data on each provider's residential proxies, providing an objective, accurate, and standardized measurement.

Yes, absolutely! We welcome all residential proxy providers to be part of our testing and review process. However, there are a few prerequisites for this collaboration:

1. Bandwidth Provision: You would need to provide the bandwidth necessary for us to carry out the testing. This involves us sending approximately one million requests every 24 hours accurately measure the size of your residential proxy pool.
2. Unmodified Proxy Pool: The pool assigned to us for testing should be identical to what any other user would receive upon purchasing services from you. We request that there be no modifications or special treatments to the pool used for our tests. This ensures that our testing process remains fair, transparent, and provides an accurate representation of your service to potential users.
3. Data Publication Consent: Lastly, you need to agree that we have the right to publish any data we find during our testing, regardless of whether it reflects positively or negatively on your service. Our aim is to provide accurate, transparent, and unbiased information to consumers, and as such, we will share our results openly.

If you're willing to meet these conditions, we would be more than happy to include your residential proxy service on our page. Please feel free to reach out.

We understand that it can be disappointing to see less-than-optimal results published about your service. However, it's important to remember that our aim is to provide the most accurate and unbiased information to our users, based on rigorous and uniform testing.

Our suggestion would be to use this feedback as an opportunity for improvement. Review the areas where your service fell short, make necessary adjustments, and strive to enhance the overall quality of your residential proxy pool. Once improvements have been made, the improvements will be reflected on this page.

In the backend, we use ip-api.com to collect information on whether or not the proxies are considered a proxy, located in a datacenter, or marked as mobile, as well as geo-location data.

All proxy providers are tested by connecting to their global residential proxy pool and sending, on average, 1 million requests every 24 hours. We connect to the http:// version of our target website to minimize data usage. If we for some reason discovered during our initial tests that the proxy provider did not properly support http:// websites, then we have opted to connect to the https:// version of our target instead.

To go into more detail about why we connect to http:// of our target for more proxy providers instead of https://, here are the simple calculations:

• https:// website: (512bytes for the SSL + 32bytes for the request + 107bytes for the response + ) * 1000 000 requests = 0.651 Gigabyte
• http:// website: (32bytes for the request + 107bytes for the response) * 1000 000 requests = 0.139 Gigabyte

It should also be noted that the SSL we use is the absolute minimum most software will support these days, and most websites will use a 2048byte SSL or more instead.
For most people, this might not matter, or their target website might not even support http://, but considering that we do this for multiple providers daily, this adds up quickly.

To ensure that our system does not misrepresent a proxy provider, we make sure that each proxy provider has had at least 900 000 successful connections in the past 24 hours from our system. If not, the proxy provider will not be displayed on this page until we have found the issue. The domain we connect to is also hosted in multiple locations to ensure the least latency. We connect to a domain we host, ensuring full control that the data we receive is as accurate as possible.

That being said, the accuracy of the total unique IPs in their pool is hard to ensure. We test the global pool of each proxy provider, and depending on how the proxy provider operates, it may or may not accurately represent their actual pool size, but rather a representation of how many unique IPs you get to access per million requests. There are a few things a residential provider might be doing that could influence the results of our tests:

• Some proxy providers might put apart IPs to be dedicated to people that request high-value countries specifically through the proxies, like the United States. Meaning that our targeting at the global pool would not accurately represent how many proxies they have in specific locations.
• Some providers might temporarily cache their residential IPs, meaning that they will be limited to a smaller pool until their cache is updated a few minutes later. In this case, you would get way more unique IPs if the million requests were sent over a longer period.
• While we have yet to encounter a provider that does this, some providers may only assign a specific portion of their pool to the user to maintain the quality of their IPs.

The system currently only tests for IPv4.

Some providers might not be in our research for the following reasons:

• They do not have a similar business model.
• We did not consider them yet for our research.
• The provider explicitly refused to be part of our research.

As for the last reason, we had two major providers refuse to be part of this research due to concerns that our research might not be objective enough or because we have been refused from their platform.

While all providers in this research have functioning proxies, I would recommend you proceed with caution with the following providers:

• Pyproxy: While talking to some people about Pyproxy, there seem to be quite a few people that believe this residential network is hosted on a botnet. We do not have any proof of this, but we recommend you review them yourself before using them.
• PacketStream: The usage tracking of PacketStream seems to be very inaccurate, with some people reporting up to 10 times their actual usage. During our own testing, we saw an even worse result of 80-100 times our actual usage. This could be because our testing is very bandwidth-efficient, and the bug on PacketStreams' side could be a fixed size per request, but we could not narrow down the issue yet.