Testing Residential Proxies is a little different from testing Static or Data Center Proxies. Residential IPs come from real devices, so availability, performance, and IP retention can change over time.
Use the guidelines below to get more reliable test results and to help separate a proxy issue from a target-site or configuration issue.
➡️ Start With a Simple Test
What's the best way to test Residential Proxies?
Start with the simplest connection possible before adding targeting, sessions, or other options.
- Test your Residential Proxy without any targeting or session settings.
- Confirm that the proxy connects and returns a Residential exit IP.
- Add any required targeting criteria one at a time.
- Add session settings only after the basic connection is working.
- Test against your actual target website or application.
This makes it much easier to identify whether an issue is related to authentication, targeting, session configuration, availability, or the target website itself.
For technical setup and configuration options, see the Proxy Quickstart guide.
➡️ Request Rate & Scaling
How quickly should I send requests?
There isn't one request rate that works for every website or use case.
We recommend starting with a lower request rate and increasing gradually while monitoring success rates, response times, CAPTCHAs, blocks, and other target-site behavior.
A target that handles one request pattern well may respond very differently to another, so test with the website and workflow you actually plan to use.
Why do my results get worse when I increase traffic?
Higher request volume can increase the likelihood of rate limiting, CAPTCHAs, temporary blocks, timeouts, or other restrictions from the target website.
If performance drops as you scale:
- Reduce the request rate and test again.
- Increase traffic gradually instead of sending sudden bursts.
- Check whether the issue is limited to a particular website or endpoint.
- Review whether your targeting criteria are making the available proxy pool too narrow.
➡️ Rotation & Sessions
Should I use rotating or sticky sessions when testing?
That depends on the behavior you want to test.
Use normal rotation when your workflow benefits from changing exit IPs between requests. Use a sticky session when you need to keep the same exit IP across multiple requests.
Because Residential exits come from real devices, an individual IP can still become unavailable during a session.
For the latest session types and configuration options, see our Residential Proxy Sessions documentation.
➡️ Targeting & Availability
Does targeting affect my test results?
Yes. The more specific your targeting criteria become, the smaller the pool of matching Residential devices may be.
Country-level targeting generally provides broader availability than a specific region, city, ZIP/postal code, ASN, operating system, or a combination of several narrow criteria.
If your proxy works without targeting but fails after targeting is added, see Why is my targeted Residential Proxy not connecting?.
For targeting setup and supported parameters, see our Residential Proxy Targeting documentation.
➡️ Bandwidth & Test Size
Does testing use my Residential bandwidth?
Yes. Residential Proxy traffic is bandwidth-based, so requests and responses made through the proxy contribute to your usage.
When testing a new workflow, start with a smaller sample before running a large batch. This helps you validate the target, request pattern, targeting, and success rate before using more bandwidth.
Should I test large downloads or bandwidth-heavy traffic?
Residential Proxies are generally best tested using the same request and response patterns your production workflow will use.
If your workflow involves unusually large responses or heavy bandwidth usage, start small and monitor consumption before scaling. If you're unsure whether your planned traffic pattern is appropriate for the service, contact our Support team.
➡️ Target-Site Behavior
Why am I seeing CAPTCHAs or blocks?
Using a Residential Proxy doesn't guarantee that every request will be accepted by a target website.
Websites can evaluate many signals beyond the IP address, including request frequency, browser behavior, headers, cookies, account activity, and their own anti-automation rules.
If you're seeing CAPTCHAs or blocks:
- Reduce your request rate.
- Test whether the issue occurs across multiple Residential IPs.
- Confirm that your application is sending valid requests for the target.
- Compare the results with and without highly specific targeting.
- Test directly with the target instead of relying only on an IP checker.
Rayobyte can't guarantee compatibility with every third-party website, since target-site restrictions and detection systems are controlled by the website itself.
➡️ Responsible Testing
Are there any restrictions I should keep in mind?
Yes. All testing and production traffic must comply with Rayobyte's policies and applicable laws.
Some websites, activities, or traffic patterns may also be restricted to protect our network and users. If you're unsure whether your use case is permitted, check the applicable policies or contact Support before running a large test.
➡️ Need Help?
If your test results are inconsistent or you're not sure whether an issue is caused by the proxy, targeting, or the target website, our Support team can help you narrow it down.
When contacting us, please include:
- The website or endpoint you're testing
- Whether the proxy works without targeting
- Any targeting or session options you're using
- The approximate request rate or traffic pattern
- The exact error, HTTP status, CAPTCHA, or block you're seeing
- A recent example and approximate time of the test
Important: Remove proxy passwords, API keys, cookies, and other sensitive information before sending screenshots, logs, or code samples.
Email: support@rayobyte.com
Submit a Ticket: Contact Rayobyte Support