The Proxy Trial Acceptance Checklist: 7 Tests to Finish Before the Refund Window Closes

The most common proxy regret goes like this: a few days in, it's clearly not the right fit, and the refund window closed yesterday. Proxy refund windows are short, and many come with conditions like "unused" or "low usage". This guide gives you a time-ordered acceptance checklist: what to test first, what to test later, and how to finish without blowing through a usage cap.

Refund terms come from official provider pages, as listed on 2026-10-05. They change, so reread them before you order.

Know the windows first

Two of these deserve special attention:

• Novada refunds only unused purchases, so for Novada, testing at all means giving up the refund. The sensible move is to treat the new-user offer, 10 GB of residential for $10, as the cost of testing.
• Proxy-Seller refunds non-working proxies only. "Didn't perform as hoped" usually isn't covered. Your priority there is test 1: does it work at all?

The seven tests

1. Connectivity and authentication (first hour)

• Connect using the provider's format. If both HTTP and SOCKS5 are offered, test both; SOCKS5 vs HTTP Proxy explains the differences.
• Try username/password and IP allowlist authentication, and confirm the one you plan to use works.
• Log every failed IP with the error message.

2. IP type (first two hours)

Look up the ASN on ipinfo.io. Residential and ISP products should show a consumer ISP, not a hosting company. Sample five to ten IPs; one tells you nothing about a pool.

3. Geolocation accuracy (first two hours)

When you target a country or city, is the exit actually there? Check two IP databases and go with the majority, since databases disagree at the city level.

4. Blocklists and risk scores (first four hours)

Run the IPs through a DNSBL checker such as MXToolbox, then look at risk scores. Widespread hits on major lists are strong evidence for a refund claim.

5. Your real target (first twelve hours)

Run your actual workflow on the site you'll actually use, but keep the volume small: dozens of pages, not thousands. On per-GB products, this is the test most likely to push you over a usage cap.

6. Stability and sessions (first 24 hours)

• Static IPs: check every few hours. The exit IP should never change.
• Sticky sessions: hold one session ID and keep requesting. Note when the IP first changes and compare it to the provider's stated session length.

7. Billing reconciliation (last)

Compare the usage in the dashboard against your own estimate, and confirm you're being billed the way you expected.

Fit the tests to the window

A quick sizing note for per-GB plans

Most of these tests use very little traffic. A lookup on ipinfo.io is a few kilobytes, so a few hundred of them barely register. Test 5 is the exception: real pages with images and scripts can run to several megabytes each. If you're near a cap like Thordata's 2 GB, block images in your test client or fetch HTML only, and check the dashboard after each batch.

Before you click Buy

A little preparation makes the whole window usable:

• Write down your pass criteria in advance. For example: "residential ASNs on at least most of a ten-IP sample, US exits only, my login flow completes." Deciding after the fact invites wishful thinking.
• Have your test scripts ready. Don't spend the first six hours of a 24-hour window writing code.
• Buy the smallest plan that's representative. A starter pack tests the same infrastructure as a large plan at a fraction of the risk.
• Note the purchase time. Windows are counted from payment, not from when you got around to testing.

Keep evidence as you go

• Timestamps, IPs and screenshots for every test.
• A screenshot of dashboard usage.
• When you file a refund request, attach them and quote the provider's own refund terms.

What a passing trial looks like

You won't get a perfect score, and you shouldn't expect one. A reasonable pass is: everything connects, the IP type and geography match what was sold, most sampled IPs are clean, your real workflow succeeds at small scale, and billing matches your estimate. If any of the first three fail broadly, that's a refund case. If only test 5 is marginal, it may be your workflow rather than the proxy, and it's worth a conversation with support before you decide.

For the full lookup routine, see How to Check if a Proxy IP Is Clean. For pre-purchase steps, see How to Buy Proxies, and for how residential providers compare on refunds and expiry, the residential proxy comparison.

Bottom line

Read the refund terms first, then set your order of tests: does it work, does it work well, is it worth it. Where usage is capped, save large-scale testing for after the window. And test only on sites you're permitted to access, within their rules.