Best practices

The fastest way to know if Shifter fits your project is to run your real workload, the same requests you will run in production, and read the results honestly. These practices help you get a clean, representative test instead of a misleading one.

Match rotation to the job

How you rotate IPs should follow what your task needs.

• Per-request rotation (default): a fresh residential IP on every request through the gateway p.shifter.io:443. Best for scraping, crawling, price collection, SERP work, and anything where each request stands on its own.
• Sticky sessions: hold the same IP for a set window using a session id (sid) and a time-to-live (ttl). Best for logins, carts, checkouts, and any multi-step flow that has to stay on one IP. For example, customer-USERNAME-sid-9f3a2b7c-ttl-600 keeps one IP for about 600 seconds.

Rule of thumb: if the steps depend on each other, use a session. If they do not, rotate. Full detail in Sessions.

Target the right location

Many sites change content, pricing, or availability by location.

• If your target is geo-sensitive, target by country, region, city, or ASN so your test reflects what real users in that market see. For example, customer-USERNAME-country-us-state-newyork-city-newyork.
• If location does not matter for your use case, keep targeting broad. Narrowing too far shrinks the available IP pool and can lower success rates for no benefit.

See Geo-targeting for every parameter.

Pace your requests

Spreading load is usually the difference between a strong test and a weak one.

• Spread requests over time and across IPs rather than hammering one target. With per-request rotation the IP already varies, so your main levers are concurrency and timing.
• Start with modest concurrency, watch your success rate, then scale up. If success drops as you push harder, you are moving too fast for that target, not hitting a proxy limit.
• Add small, varied delays, and retry failures on a new IP. With rotation, the retry naturally lands on a different exit, so treat a block as a soft signal: back off, retry, and continue.

Pick the product that matches the workload

Choosing the wrong product is the most common reason a trial underperforms.

• Residential Proxies: rotating residential IPs, so traffic looks like many real users. Scraping, monitoring, ad verification, market research, and SERP collection.
• ISP Proxies: the same dedicated IP for days or weeks. Account management, long checkout or login sessions, and whitelisted-IP integrations.

If you are unsure, work through Choosing a product.

Read your results

Judge on your real numbers, not a couple of test calls.

• Look at your success rate and data quality at production-like volume. A handful of failures is normal; the rate at scale is what matters.
• Confirm the exit is what you asked for by sending a request through the proxy to an IP echo endpoint such as ipinfo.io, and checking the IP and country.
• If results look off, check three things before blaming the network: rotation versus session matches the task, the target location is set correctly, and concurrency is not too high.

Need a hand during your trial?

Reply to any onboarding email and it comes straight to the team, or open the chat in your dashboard. A quick question early usually saves a wasted test.

The more your test mirrors production in traffic, targets, and timing, the more the trial actually tells you. Set it up to look like the real thing, and the decision makes itself.