What peoplebuy proxies for

Most scraping blocks have one of three causes, and they need different answers. Per-address rate limits: the target counts requests per IP and refuses above a threshold, which spreading the traffic across many addresses fixes. Range rejection: the target refuses hosting ranges on sight, which no quantity of datacenter addresses fixes, because the range is what is being rejected. Behavioral scoring: the target scores your headers, TLS fingerprint and request timing, and keeps scoring them whatever address they arrive from.

Rotation solves the first, residential solves the second, and neither solves the third. A spread of addresses also does not raise your request rate by itself: Scrapy keys its download slots on the target domain, so `DOWNLOAD_DELAY` and `CONCURRENT_REQUESTS_PER_DOMAIN` cap the whole crawl however many exits carry it, while `CONCURRENT_REQUESTS_PER_IP` moves the limit onto the address and disables the per-domain cap. On a per-gigabyte product every byte lands on the invoice, so fetch only what you parse.

What a retail page shows depends on where it thinks you are. Currency, tax treatment, delivery promise, stock status and the running promotion are commonly set by location, and a storefront that redirects a foreign visitor to its local site can show a different assortment. The listed price itself varies less often than the terms around it, but a price collected from the wrong country is a wrong answer, and nothing in the response says so.

So the requirement is location fidelity and repeatability. A residential exit in the market you measure gets the page the site serves to visitors from there; cookies, account, language and delivery settings still need to match a local shopper. Country targeting covers most work; city targeting matters where the thing you measure varies inside the country, such as delivery coverage, store-level stock or regional promotions. Pin the location, keep the request cadence steady, and record the exit country with every price. A location with no exits is refused rather than served from somewhere nearby, so a gap in the series is visible instead of silent.

Marketplace work is higher volume than price monitoring, and what usually breaks a run is pagination rather than a block. Result sets on a busy marketplace reshuffle as listings arrive and re-rank, so a crawl can duplicate or miss items between page two and page three of one query. Changing exit mid-query makes it worse: it can break the session carrying your pagination token, and on a marketplace that varies its catalog by country it can swap the catalog underneath you.

Use a sticky session for anything paginated, filtered or logged in, and per-connection rotation for discovery, where each request stands alone. Record the marketplace country, the query, the page number and the exit used with every listing, so a duplicate or a gap can be traced to a reshuffle rather than blamed on the proxy. A product page's HTML is a small fraction of its images, fonts and scripts, so fetch only the document, or the data endpoint behind it, and measure one listing end to end before choosing a size.

The thing being verified is a targeting decision made about the viewer. An ad server that recognizes a hosting range can serve a different creative, the default, or nothing at all, and each of those looks like a success to a script that only counts HTTP 200. Observing from a household connection in the target market is what makes the observation mean what you think it means. The same applies to counterfeit and gray-market monitoring: infringing listings are often shown only to shoppers in one country and hidden everywhere else.

Rotation buys you a location and a network that has not already been scored as a repeat observer. It does not reset frequency caps, which are keyed on cookies and device identity rather than the address; use a clean profile for that. Check placements on a schedule that matches the campaign flight, capture the creative and the landing page together, and keep the exit country and the timestamp with each capture, so a missing placement can be told apart from a capture that failed.

Search results are localized below country level: local packs, map results, shopping units and the order of organic results all shift between metros inside one country, so a rank measured from one location is a fact about that location. Rank tracking is also many small requests to one host, which per-address rate limits exist to stop, and search engines challenge hosting ranges harder than most targets. Validate that a response is a results page before parsing it, count a challenge as a failed observation rather than a zero, and refetch later from a different exit.

Residential targets down to the city and is billed per gigabyte; a results page fetched as plain HTML is a small document, so an allowance goes a long way. Our datacenter blocks sit in the United States, Italy and Spain and target no finer than the country, so they suit a small national keyword list in one of those countries where the engine tolerates the range. If you split the work, record which exit type produced each observation so the two series are never compared as one.

Social platforms rate-limit mainly on the account, token or app rather than on the address, and treat hosting ranges as automation readily. An address change alone rarely buys much here; request pacing matters as much as the exit, because a pool that hides your volume from a rate limiter does not hide a cadence no human produces. Spread the schedule and slow it down before you widen it.

Anything carrying a persistent identity should stay on one exit for the life of that identity: an address that jumps between countries between requests is a pattern these platforms look for. Pin a session and treat a forced address change as an event your code handles. Keep identity-bearing sessions and public collection on separate session IDs, so a block on one does not take the other with it, and keep the cadence per identity close to what a person would produce. For public collection with no identity attached, per-connection rotation is the simpler and cheaper default.

The target is yours, so nothing is trying to block you and the exit does not need to look like a household connection. What you need is a stable, known address in a chosen location, which is what a shared or dedicated datacenter proxy is: confirm that a geo restriction restricts, check that a CDN serves the right edge and cached variant, verify currency, language and consent flows for each market, and confirm that a partner's whitelist admits the address you gave them. Static addresses matter for that last one, because a rotating address cannot be whitelisted by anybody.

For CI, IP whitelist authentication works on every product and keeps credentials out of the pipeline: register the runner's address and there is nothing to rotate when a contractor leaves. Our proxy endpoints are IPv4, so whitelist the address the runner uses for IPv4 traffic, which on a dual-stack network is not always the address it prefers for ordinary web requests.

Airlines and online travel agencies quote in the point-of-sale currency, apply fare rules by market, and run promotions visible in one country and absent in the next; hotel rates behave the same way. Collecting everything from one country gives you one country's view of a global market, so breadth of country coverage matters more than depth in any one place.

A booking engine's search, select and price steps share server-side state, so a quote sequence has to hold one exit or the engine loses the itinerary and returns an error that looks like a block. Pin a session for the sequence and rotate between sequences. Fares move, so compress the collection window with concurrency across many exits: the sizing question is how long the window may be, not how many routes there are. Record the point-of-sale country, the currency and the timestamp with every quote, and check that the currency returned matches the market you asked for before storing the row, because a fare table without those fields cannot be compared later.