How to evaluate a residential proxy trial

Short answers

Define the result before testing

Choose a task you will actually run: capture a product price, check a regional page on your staging site, or read an authorised API response. Define the expected fields, currency, page state and deadline. An HTTP 200 containing an error message is not a completed task.

Select representative pages or endpoints, including the expensive and multi-step cases. Keep the same client version, browser settings, cache policy and request limits when comparing pools. Record the sample size and testing window; a small trial is evidence about that sample, not a service-wide success rate.

Confirm the connection and the route

Choose a currently available country and pool in the connection builder. Run the curl connection check, then repeat the intended task in the application you will use. A working curl command does not establish that your browser or script uses the same proxy settings.

An echo response identifies the address used for that echo request. It cannot establish the exit address of another request, especially with rotation or separate browser connections. For a site you control, correlate a test identifier with its server log and record the address there. Keep country lookup results separate from the country requested in your configuration.

For geographic QA, also record language, cookies and account region. Those can change what a website displays without changing its network route. The country troubleshooting guide explains how to distinguish these signals.

Keep one row per task

Use this checklist in your own notes. Keep credentials, authentication headers and personal data out of the record. Link repeat attempts to their original task so retries do not inflate the number of completed results.

Report accepted tasks divided by attempted tasks. Keep request attempts as a separate count: one completed browser journey may make many requests. Label interrupted and unfinished tasks explicitly; excluding them makes both completion time and traffic look better than they were.

Test timing and session continuity

Separate connection setup from waiting for content and finishing the task. For curl, time_connect measures reaching the remote host or proxy; time_starttransfer includes preparation and the server’s response time; time_total covers the operation. These are elapsed milestones, not independent durations to add. See the curl timing definitions.

Keep slow and failed observations with the sample. Report the median and range for completed tasks, plus separate failure and timeout counts. Include the number of observations. Avoid ranking pools from one fast echo response: your target, payload, client and network path all affect the measurement.

For a multi-step task, retain its session name and application state together. Sticky mode keeps the same device while available; its IP can change. Connection reuse can also keep a tunnel open across several requests. Follow the rotation and sessions guide, and test how your job records an interrupted step before retrying an operation that changes data.

Measure traffic per completed task

Pause unrelated workers using the same balance. Note account usage before the sample, allow the meter to settle after it, and compare the readings. Usage refreshes every five minutes; a reading taken immediately after a run may be incomplete. Preserve the measurement window with your notes.

Divide the isolated run’s usage increase by its accepted tasks. Include traffic spent on incorrect results, partial responses and retries in that numerator. With no accepted tasks, there is no usable per-result estimate. Client counters help explain the total but are not the billing meter; see what counts as proxy traffic.

For product checks, the price monitoring traffic planner scales total sample traffic by accepted observations and your schedule. The bandwidth calculator uses per-attempt bytes instead; choose the calculation that matches your measurement. Repeat the sample after changing page resources, concurrency or session policy, rather than treating the first measurement as permanent.

Choose the next order from the evidence

Portproof’s paid trial is once per customer, subject to eligibility. The current amount and price are shown below and at checkout. Both pools are shared: mobile traffic uses carrier modems and residential traffic uses opt-in peer devices in the partner network.

Keep the configuration that met your acceptance conditions, investigate unresolved failures, and use measured usage to choose the next amount on the pricing page. If a required workflow did not work, preserve a redacted example for support before increasing the order.

What is not allowed

Test only sites and workflows you own or are authorised to access, respect destination limits, and follow the acceptable-use policy.

Read next