A useful rotation strategy starts with the collection task, not with the fastest possible IP change. Define which public pages you are authorized to collect, what makes a response valid and which requests belong to the same session before choosing rotation, pacing and retries.

Choose a session model

Per-request rotation

Per-request rotation can suit independent requests that do not need the same exit. Independence is a property of the task, not a rule inferred from whether a request currently includes a cookie.

Sticky sessions

Use a sticky session when a connected sequence needs the same exit. KiloProxy Dynamic Residential supports a configurable 1–120-minute sticky session. Choose a duration that covers the expected sequence without treating the configured duration as an uptime guarantee.

Cookies are managed by the client according to the application’s state rules. Proxy rotation does not itself delete, preserve or store cookies; changing the exit and changing the cookie jar are separate actions. For HTTP cookie behavior, see RFC 6265.

Fixed task identity

If a permitted workflow needs one stable exit across days or repeated work sessions, a Static ISP proxy is a better fit than repeatedly extending a rotating session.

Retry deliberately

Classify a failure before retrying. A retry policy should have a limit, use a delay appropriate to the target and stop when the result indicates a permission or parsing problem. Respect target-provided rate-limit or waiting information.

Situation Check first Do not automatically do this
429 Target rate-limit message, request frequency and waiting time Retry without limit or immediately add more IPs
403 or verification page Authorization, request method and target rules Declare the IP defective or promise that changing IP will solve it
200 without expected fields Returned page type, selector and parser Count the response as a successful record because HTTP was 200
Connection timeout Local connection, proxy configuration and target reachability Attribute every timeout to blocking

This table is a diagnostic method, not a KiloProxy performance-test result.

Adapt concurrency to evidence

Start conservatively and measure useful records, error categories, response time and traffic. Increase concurrency only while the permitted target remains stable and useful-result quality does not fall. There is no universal “two requests” or “two seconds” setting that is correct for every source.

Use geography only when needed

Regional selection can help compare public pages whose permitted content varies by location. Dynamic Residential supports country, state and city selection subject to available resources. Record the requested region and observed result, and avoid treating a location label as proof of business eligibility or user identity.

Control traffic cost

Dynamic Residential is billed by traffic in GB. Block unnecessary media in your own client where appropriate, avoid downloading the same unchanged resource repeatedly and track traffic per useful record rather than only per HTTP response.

To use rotation and sticky sessions in this workflow, review Dynamic Residential Proxy.

FAQ

Should every request use a new IP?
No. Independent requests may use rotation, while related steps may need the same exit. Match the session model to the workflow.
How long can a KiloProxy sticky session be set?
From 1 to 120 minutes. This is a configuration range, not a promise that a connection cannot be interrupted.
Does rotating an IP clear cookies?
No. Cookie storage is controlled by the client. Treat exit-IP choice and application state as separate parts of the workflow.
Should I change IP immediately after a 429 or 403?
Not automatically. For 429, reduce request pressure and follow target guidance. For 403 or a verification page, confirm authorization, configuration and target rules before deciding what to change.

Build the collection around useful records, controlled retries and an appropriate session. Review Dynamic Residential plans.