Proxy field notes Response codes Pool sizing Choosing an address

Buy a proxy server for the job you actually have: what each task needs and what to check first

Five kinds of work run from my desk every week: catalogue collection for a price monitor, a shelf of 14 accounts, two advertising cabinets, four API integrations on a schedule, and rank capture across 3200 keywords. Each one connects through an address, and each one asks something different from that address. The collector wants width and threads. The accounts want one address that never moves. The cabinets want a region that matches the card and the profile behind it.

For a long stretch I bought one type of access and pushed all five jobs through it. That worked for two of them and produced constant small trouble in the other three, which I read as bad luck for months. The trouble stopped when I started writing down what each job needs before I open a seller's page.

Below is that set of notes, job by job. Every section holds the same three parts: what the work does, what the address has to give it, and the check that tells me whether an offer answers the requirement. My numbers come from my own logs, and I include the runs where my check said no.

The six properties I read before I read anything else

Sellers describe access in their own vocabulary, so I translate every page into the same six properties. It takes two minutes and removes most of the guesswork.

Sole use. One buyer holds the address for the whole rental, and nobody else routes traffic through it. This property decides more outcomes than any other in my work, because everything a site remembers about an address arrives from whoever used it.

Persistence. The address either stays with me for the whole rental or changes on a timer or on a signal from me. Accounts want the first behaviour. Wide collection wants the second.

Region. The country and the city the address belongs to, as detection pages read it, which sometimes differs from what a registry says.

Protocol. HTTP for browser work and most parsers, SOCKS5 for anything that carries its own client or needs a raw TCP path.

Thread ceiling. How many parallel connections one address holds without the far side tightening. My collector runs 20 threads per address as standard and 40 on undefended sources.

Traffic. Whether the rental meters volume, and how a heavy month lands. My price monitor pulls 340 to 470 GB a month, so this line matters to me every single time.

Those six lines answer most questions about fit. The rest of this piece walks through the jobs that turn them into requirements.

Catalogue collection at volume

The price monitor visits 1200 to 1800 URLs an hour across 11 shops. Pages are heavy, HTML sits around 240 KB before I strip it, and the same shop gets visited many times a day.

What the address has to give here is width and headroom. Width means many addresses spread across several subnets, because a shop that starts counting will count by network block long before it counts by single address. My working spread is 24 addresses across 6 different /24 blocks, and that split alone lifted my success rate on one stubborn shop from 71 to 96 percent.

Headroom means the address tolerates parallel work. I run 20 threads per address, so a pool of 24 gives me 480 parallel connections when a night run needs them. For this class of work I take addresses set up for catalogue collection and keep the split written down in the collector config, one line per block.

Traffic is the third requirement, and it is the one that surprised me most. A month of price monitoring pulled 412 GB, and a metered rental turns every debugging run into arithmetic. Work carried by a rental with no traffic meter on it lets me re-run a broken job at four in the afternoon without thinking about volume at all.

How I confirm an offer answers this: I ask for the subnet spread in writing, and I ask for the per-address thread ceiling as a number. Then I test both.

cut -d: -f1 pool.txt | awk -F. '{print $1"."$2"."$3}' | sort -u | wc -l   # distinct /24 blocks
xargs -a urls-60.txt -P 60 -I{} curl -s -o /dev/null -w '%{http_code}\n' \
  -x "http://user:pass@$ADDR:$PORT" {} | sort | uniq -c   # 60 parallel, count failures

A seller who answers both questions with numbers has told me something useful about the pool. A seller who answers with adjectives has told me to run a longer test.

What I asked	Pool A answered	Pool B answered	What my test found
Subnet spread on 24 addresses	6 blocks	2 blocks	6 and 2, confirmed
Threads held per address	20 to 30	no figure given	97 percent at 20, 94 at 30
Traffic terms for a heavy month	no meter	200 GB included	pulled 412 GB with no trouble on A
Replacement if an address stops working	same day	on request	A swapped 2 addresses in 40 minutes

Accounts that have to stay alive for months

The 14 accounts I keep are the opposite job. Volume is tiny, maybe 30 requests a day per profile. Longevity is everything.

An account builds a history at a place, and the platform reads that history every time the profile appears. So the requirement here is sole use plus a long pin: one address, one profile, no sharing, no changes for the life of the account. My oldest profile has sat behind the same address for 19 months and has never once seen a verification screen.

The property doing the work is exclusivity. When an address is issued to one buyer and nobody else, the history behind it belongs to my profile alone, so the platform judges my behaviour and nothing else. That is a very different starting position from a shared pool, where the counter that matters was already moving before I arrived.

Persistence comes from the rental term. I take a monthly rental pinned to one profile and keep renewing the same address, which is why the field in my antidetect profile has stayed untouched since the profile was created.

How I confirm it before buying: I ask two questions in plain words. Is this address issued to me alone for the whole term, and can I keep the same address across renewals. Both answers should be yes with no conditions attached. Then I check the address myself on the day it arrives, before any profile touches it.

curl -s -x "http://user:pass@$ADDR:$PORT" https://ifconfig.me/all \
  | grep -Ei 'ip_addr|forwarded|via|x-real-ip'

The grep catches two things at once: the exit as the far side sees it, and any forwarded header carrying my own address. I have taken delivery of an address that passed a forwarded header, and my profile would have connected from my office through a brand new rental, which is the sort of quiet failure that costs weeks of confusion.

Advertising cabinets and profiles that hold billing

Two cabinets, both tied to a company card, both watched closely by the platform. The daily load is nothing, a few logins and some editing. The requirements are strict all the same.

Region comes first here. The cabinet, the card and the profile should agree, and agreement is judged by what detection pages report about the address. A registry entry saying one country while three detection pages say another produces exactly the kind of mismatch that ends in a document request.

Stability comes second. An advertising profile that appears from a different place every session collects checks, so the address stays pinned for the life of the cabinet, the same way it does for accounts.

For this pair I run a private IPv4 address of my own per cabinet, taken in the country where the company sits. The address goes into the browser profile before the first login and stays there.

How I confirm the region: three detection pages, three answers, compared. Different providers hold different data, and a disagreement among them tells me the address will read inconsistently to a platform too.

Source	Country	City	My verdict
Detection page 1	matched	matched	fits the cabinet
Detection page 2	matched	city 60 km away	acceptable, same region
Detection page 3	matched	city 900 km away	I asked for a swap
Registry record	matched	no city data	neutral, no weight

The third row is a real answer from a real candidate address, and it is the reason I run three pages every time. One page had reported the address as sitting in the right city, and I would have accepted it on that single reading.

API integrations running on a schedule

Four integrations pull from partner endpoints on cron, between 90 and 400 calls per run, six runs a day. Nobody watches these jobs, which is why they need the most predictable address of the five.

The requirement is steady latency and an exit that passes nothing extra. A collector can retry a slow page. A scheduled job with a 10 second timeout writes an empty table and reports success, and I find out two days later when a report looks thin.

Protocol matters here more than anywhere else. Several of my clients speak SOCKS5 natively, and a raw TCP path keeps the request shape exactly as the library built it. I take SOCKS5 access on the same address list so a job can use either protocol against the same exit, which makes comparing two runs straightforward.

How I confirm it: 200 calls against the real endpoint before the job goes on cron, then read the tail of the distribution.

import time, statistics, requests
P = {"https": "socks5h://user:pass@ADDR:PORT"}
t = []
for _ in range(200):
    s = time.perf_counter()
    r = requests.get("https://api.partner.example/v2/items?limit=50",
                     proxies=P, timeout=10)
    t.append((time.perf_counter() - s) * 1000)
t.sort()
print(int(statistics.median(t)), int(t[int(len(t)*0.95)]), int(t[-1]))

Three numbers come out: median, 95th percentile, worst case. On the pool I kept, those were 210, 480 and 890 milliseconds. On a candidate I turned down they were 260, 2300 and 11400, and that last figure is a job writing an empty table twice a week. The median looked fine on both, which is why I read the tail and never the average.

Rank capture across a large keyword list

Weekly rank capture covers 3200 keywords across two search engines, from 4 cities. The job runs for about five hours and produces one number per keyword.

This work asks for width again, and it asks for something the other four jobs do not want: change. A search engine tightens quickly against a repeated visitor, so the address that asks for position 1 to 10 should differ from the one that asks for 11 to 20. My capture runs behind rotation across a wide pool of exits, with a change every 25 requests, and that rhythm holds a 96 percent completion rate across the full list.

Region enters here as a working parameter. City-level results differ, so the capture for a shop in one region gets addresses from that region, and my four city groups map onto four address groups.

How I confirm the pool is wide enough: I run 400 sample queries and log the exit each one left through. If the log shows 12 distinct exits, the pool is 12 wide for my purposes, whatever the product page says. My kept pool showed 47 distinct exits across 400 queries with the change interval set to 25, which is the arithmetic working out exactly as described.

The second check is response codes. A capture pool that returns codes other than 200 on more than 6 percent of queries turns a five hour run into a seven hour run with gaps, so I measure that number during the test and write it in the log next to the pool name.

The questions I put to a seller before any payment

Four questions, sent in one message, answered in one message. I have used the same four for two years and they sort candidates faster than any amount of reading.

Is the address issued to me alone, and for how long does it stay mine. This is the exclusivity question, and it decides whether the account jobs can use the pool at all.

How many distinct /24 blocks cover the addresses I would receive. A pool spread over 6 blocks behaves differently from a pool sitting inside 1, and only the seller knows the answer before delivery.

What thread ceiling holds per address. I want a number I can put in a config. Twenty is my working figure, and a seller who says 30 has given me room I can verify.

What happens when an address stops working. Replacement terms, timing, and how many swaps a rental allows. Mine has covered 2 swaps in the last four months, both inside an hour.

Two more things I look at on the page itself. Protocol support should cover both HTTP and SOCKS5 on the same address, because jobs move between them as tooling changes. Traffic terms should be stated plainly, since a heavy month is a normal month in collection work.

When the answers come back in numbers, I move to the test window. When they come back in adjectives, I still test, with a shorter list of jobs and lower expectations of the result.

What the test window has to show me

A test is worth having only when it runs my actual work. Sample URLs from a seller's page tell me about the seller's page. So I keep a small suite that mirrors all five jobs and takes about 90 minutes end to end.

Test	How I run it	What I accept
Collection success	1200 real catalogue URLs, 20 threads	95 percent or better returning 200
Header hygiene	ifconfig.me/all through every address	no forwarded or origin header at all
Region reading	3 detection pages per address	country matches, city inside the region
Latency tail	200 API calls, sorted	95th percentile under 700 milliseconds
Account surface	login to a test profile, 6 attempts	all 6 land with no verification screen
Pool width	400 queries with rotation on	distinct exits close to the arithmetic
Sustained load	40 minutes at full threads	success rate steady from start to finish

The last row deserves a note. A pool that opens at 98 percent and settles at 73 after half an hour is telling me about its own limits under load, and that curve only appears when the test runs long enough to produce it. My shortest useful test is 40 minutes at working threads. Anything briefer measures the first minute, and the first minute is always the good one.

I also run the suite again a week into a rental. Addresses get reissued, settings drift, and a Monday morning re-check has caught a changed exit twice for me. The whole repeat takes 20 minutes because the scripts already exist.

Task against address, side by side

Here is the summary I keep open when I compare offers. Reading a product page against this table takes about five minutes and answers the question the page itself never quite addresses.

Task	What the address has to give	The check that settles it
Catalogue collection	width across subnets, 20 threads per address, heavy traffic without a meter	1200 real URLs at working threads, count the 200s
Long-lived accounts	sole use, the same address for the whole rental, no sharing at any point	header check on delivery, then 6 logins from a test profile
Advertising cabinets	region matching the company, an exit pinned for the life of the cabinet	3 detection pages compared against each other
API on a schedule	steady latency tail, SOCKS5 available, no extra headers	200 calls sorted, read the 95th percentile
Rank capture	wide pool, rotation on an interval I set, city groups	400 queries logged by exit, count distinct values
Any job at all	a stated thread ceiling and stated swap terms	ask before paying, verify during the test

Two rows sit at the extremes and explain why one type of access never covers everything comfortably. Account work wants an address that never changes. Rank capture wants an address that changes every 25 requests. Both are served well from the same private pool, with different rental terms and different settings, which is how my desk runs today: 24 addresses for collection, 14 pinned for profiles, 2 pinned for cabinets, and a rotating group for capture.

If you are starting from one job and expect to add more, take the pinned type first. A pinned address covers account work perfectly and handles collection at moderate volume, so it stretches across the widest set of tasks while you learn which of them you actually run. That is the reasoning behind my own first purchase, and I would buy an IPv4 proxy server on those terms again with what I know now.

Two neighbouring pieces go deeper on parts I moved through quickly here: choosing an address for the work ahead covers the property list in more detail, and testing a proxy before you rely on it walks through the measurement suite command by command.