Plan residential proxy traffic before buying
Residential proxies are billed by traffic. A country, payment coin and session mode are separate choices; changing the coin does not change the network you receive.
Measure a complete real-world task
The HTML document alone is a poor measure of proxy traffic. A browser may also fetch images, fonts, scripts and API responses, and failed attempts may trigger additional requests. A script using an HTTP client will behave differently. Run the actual workflow on 20–30 representative items and record the bytes transferred by the client or request log.
For each run, write down the number of items processed, requests made and bytes used. Divide the total by successfully completed items to find a useful MB-per-result figure. Record failed attempts separately: redirects, login pages and retries can consume traffic even when no result is produced.
Keep the test configuration close to production. If images are blocked in the test but loaded in production, the estimate will be too low. Record cache, compression and resource-blocking settings so that later runs can be compared fairly.
- In a browser, use the Network panel to measure the full workflow, not just the document response.
- For a script, include both directions of transfer, redirects, failures and retries.
- Repeat the measurement across several runs; one unusually smooth run is not a reliable budget.
Estimate the package with a sensible margin
Start with the number of operations multiplied by the measured traffic per successful operation, then account for retries. At 0.6 MB per item, 800 pages use roughly 480 MB. If one request in four is repeated on average, the estimate rises to about 600 MB before browser assets, authentication and workflow changes.
Use the range observed in your tests rather than an unsupported promise of certainty. If a thousand items use between 500 and 650 MB, calculate both ends and leave room above the higher estimate. Where demand is uncertain, begin with a smaller package, inspect the actual deduction in your account and add traffic after measuring production runs.
Pricing tiers change the rate per GB. Compare the total price of the amount you expect to use, rather than choosing by the lowest advertised rate alone. Extra gigabytes only help if your workload will consume them.
- Base estimate: 800 × 0.6 MB = 480 MB.
- With retries: 480 MB × 1.25 ≈ 600 MB before other resources.
- Recalculate from the first production runs before buying the next package.
Match the session mode to the workflow
Rotation is suitable for independent requests that do not need a shared identity. A sticky session is useful when several steps—opening a page, signing in and retrieving a result—must keep the same exit IP. The wrong mode can raise failure and retry rates, increasing traffic even when the price per GB is unchanged.
Define the boundary of one task before configuring the proxy. Reuse one session identifier for steps that must stay together; start a new one for the next independent task. Set the duration to cover a normal run with a margin, and check how your application handles cookies and pauses.
Country selection narrows the exit pool. Check availability and the actual exit after connection. Choosing a country does not automatically guarantee a particular city, provider or ASN; verify those settings separately if they are offered.
Verify the order and the first production runs
Compare the current tier price against your estimate in the account. For a wallet top-up, use the currency, transfer network, amount and address shown in your own payment request. An administrator confirms payment manually. After the balance is credited, purchase traffic and get the connection format from the account configurator rather than an example on a public page.
Before a full run, test the proxy against an IP-checking service and then your intended destination. Record the test time, exit country, response code, success rate and change in traffic balance. This evidence helps separate authentication problems from destination errors or an overly narrow location choice.
After a few hundred operations, recalculate MB per successful result. If it rises, inspect redirects, retries and loaded resources. Change one setting at a time when investigating; otherwise it is hard to identify the cause. Give support a small reproducible example when the behavior does not match the selected configuration.
- Before paying: network, amount, rate per GB, country and session mode.
- After activation: authentication, exit location and destination response.
- During work: traffic per successful result, retry rate and remaining balance.
Worked example
Suppose a job opens 800 pages of about 0.6 MB each and repeats one in four requests. Responses alone approach 600 MB; images, scripts and browser reloads add more. Measure 20–30 representative runs, then allow for errors before selecting a traffic tier.
Common questions
How should retries be included?
Record the retry rate in a short test and apply it to the full workload. A browser visit can load many resources beyond the page URL.
Does a sticky session change billing?
The billing unit remains GB. Session mode changes exit IP behavior and may indirectly change how often your workflow must retry.