How long does a rotating proxy keep the same IP address?
How long do rotating proxies keep the same IP? It depends on the rotation mode and the sticky-session ceiling. Test exit changes and handle expiry safely.
A rotating proxy keeps the same IP until its rotation rule changes the exit: that rule can apply to each request, a connection, or a sticky session. There is no universal retention time, and a sticky-session limit is a maximum assignment window, not a guarantee that an unavailable exit will remain reachable.
TL;DR
- How long do rotating proxies keep the same IP? The answer depends on the rotation rule and session settings.
- Sticky sessions preserve an exit assignment; they do not make an IP permanent.
- curl can verify observed exit changes when requests use the same proxy configuration.
- Measure session age from first assignment, not from the latest request.
How long does a rotating proxy keep the same IP address?
A rotating proxy has no standard IP lifetime. Read the provider's rotation policy and identify what triggers a new assignment before you design retries or browser sessions around it.
The important distinction is between a gateway address and an exit address. Your application can keep connecting to the same gateway while the destination sees different exit IPs. An unchanged proxy hostname does not prove that your public-facing address stayed unchanged.
Start with the rotating proxies for web scraping guide if you need the broader request-routing workflow. For retention time, compare the assignment behavior directly:
| Assignment mode | When the exit assignment changes | Best for | Main limitation |
|---|---|---|---|
| Per-request rotation | According to the provider's request-level rotation policy | Independent requests that do not need IP continuity | A later request can use a different exit |
| Sticky session | When the session expires, changes, or loses its assigned exit | Related requests that need a consistent source address | The assignment has a time limit and depends on exit availability |
| Static assignment | Not on a rotating session schedule | Workflows that require a persistent assigned address | A fixed address alone does not prevent blocking |
These are assignment models, not universal protocol guarantees. Confirm how your provider implements the model, particularly when your client reuses connections.
Why this matters
IP continuity matters when requests belong to the same application session. A login, a pagination cursor, and a follow-up form submission can share cookies while depending on other server-side checks. Changing the source IP introduces another variable into that workflow.
The opposite problem occurs when independent jobs accidentally share a sticky-session identifier. They inherit the same exit assignment even though the application intended to distribute requests. More workers do not automatically mean more distinct exits.
When wiring up an integration, record the rotation mode alongside your proxy credentials and concurrency settings. Treat IP lifetime as an application dependency, not an assumption hidden inside a connection string.
Sticky sessions: a maximum assignment window
Node4 rotating proxies are best for developers who need timed IP continuity: a session ID holds one exit for up to 30 minutes from first assignment. The limitation is explicit: another request does not restart that window.
A session first assigned at time T keeps that exit until T plus 30 minutes, even when a request arrives partway through the window. Track the actual assignment event in your own code rather than substitute the time you created a local client object.
A sticky session also differs from a reservation of permanent infrastructure. The session associates your requests with an exit under the service's session rules. It does not turn that exit into a static proxy.
Use the session window to organize work that fits inside it. If a transaction cannot tolerate an address change, design a safe restart path rather than assume the address will persist beyond the limit.
Per-request rotation: no fixed time window
Per-request rotation describes a trigger, not a duration in minutes. A fast application and a slow application can generate the same number of assignment decisions over very different elapsed times.
Do not interpret rotation as a promise of a previously unused IP. A provider can select an address that appeared earlier. A rotation event and a unique exit address are different measurements.
Connection reuse also needs a test. Some gateways associate routing with a connection, while others implement request-aware routing. Read the documented behavior instead of assuming that every HTTP request creates an independent assignment.
Per-request rotation fits independent collection tasks better than workflows that require source-IP continuity. Its disadvantage is that related requests need explicit session handling if they must retain an exit.
Why rotating proxy IP retention varies
The retention time follows the assignment policy and the way your application invokes it. These factors determine what you should inspect:
- Rotation mode: Request-level, connection-level, and sticky-session routing use different assignment boundaries.
- Session identifier: Keeping the same identifier requests continuity; changing it requests a different session under the provider's rules.
- Session age: A first-assignment deadline is different from an inactivity timeout. Traffic does not reset a fixed deadline.
- Connection reuse: A persistent connection can affect when the gateway makes another routing decision.
- Exit availability: A session cannot keep sending traffic through an exit that is no longer reachable.
- Explicit reassignment: A rotation control or changed proxy configuration can end the continuity your application expected.
Protocol names alone do not answer the timing question. HTTP and SOCKS5 describe proxy communication, not a universal sticky-session duration.
Keep these distinctions in your runbook. When an address changes unexpectedly, check the session boundary before changing the entire scraping architecture.
How do you check how long your proxy keeps its IP?
Measure the exit address while holding the session configuration constant. Changing the session identifier during the test measures reassignment behavior instead of retention.
1. Record the settings before sending traffic
Write down the gateway, protocol, rotation mode, session identifier, and configured session limit. Keep credentials out of logs. Record whether the client opens a fresh connection or reuses an existing one.
Choose an IP-check endpoint you control or trust that returns the caller's address as plain text. Use that same endpoint throughout the test. A response from your normal application target is useful only if it actually exposes the observed source IP.
2. Send a request through the proxy explicitly
The following Bash example uses curl. Set PROXY_URL to your documented proxy URL, including the required authentication format, and set IP_CHECK_URL to your chosen IP-check endpoint.
: "${PROXY_URL:?Set PROXY_URL using your provider's documented format}"
: "${IP_CHECK_URL:?Set IP_CHECK_URL to a plain-text IP-check endpoint}"
printf 'observed_at=%s exit=' "$(date -u +%FT%TZ)"
curl --silent --show-error --fail \
--noproxy "" \
--proxy "$PROXY_URL" \
--url "$IP_CHECK_URL"
printf '\n'The empty --noproxy value prevents a bypass rule from excluding the check endpoint. Do not disable TLS verification to make a failed test pass. A certificate error is a separate problem from IP rotation.
For authentication troubleshooting, use the curl authenticated proxy requests workflow. Keep the provider's actual credential syntax rather than inventing a session suffix.
3. Repeat without changing the session configuration
Run the same command again during the expected session window. Save the timestamp and returned address together. Separate command invocations create separate curl processes, which helps test continuity across fresh client connections.
That test does not establish how a pooled client behaves. Repeat the observation inside your actual browser, crawler, or HTTP client before treating the result as production evidence.
Keep failed requests in the record. An error is not proof that the exit changed, and silently discarding errors can hide the point where continuity failed.
4. Test the assignment boundary
For the first-assignment window (30 minutes on Node4's rotating gateway), compare observations before and after that boundary. Do not reset your local timer after each successful response.
An unchanged address after expiry does not prove the session was extended. A new assignment can select the same address. Conversely, an earlier change needs investigation into session settings, connectivity, and the provider's documented behavior.
5. Report what happened, not a promise
A useful test report states the configuration, observation times, returned addresses, and failures. It does not turn one successful run into a general claim about how every account or exit behaves.
Date the report. An integration test describes the configuration tested at that time, not every account, exit, or future deployment.
How should your application handle session expiry?
Track the deadline from first assignment and stop starting work that cannot finish safely inside it. Use a monotonic clock for elapsed time so a system-clock adjustment does not distort your local session-age calculation.
This Python example calculates a local deadline after your application observes the first successful assignment. It does not implement provider authentication or reset the provider's session timer.
import time
STICKY_LIMIT_SECONDS = 30 * 60
# Call immediately after observing the first successful assignment.
first_assignment_observed_at = time.monotonic()
deadline = first_assignment_observed_at + STICKY_LIMIT_SECONDS
def remaining_session_seconds():
return max(0.0, deadline - time.monotonic())
def session_window_elapsed():
return time.monotonic() >= deadlineYour observation happens after the remote assignment, so this local deadline is an estimate rather than an exact server-side expiry timestamp. Use a provider-reported assignment time when available. Otherwise, leave a buffer based on your measured request duration and workflow requirements.
Keep the session identifier, cookies, and task checkpoint together. If you replace the exit while retaining everything else, the target still sees the existing application session coming from a changed address.
Make expiry a handled state in your deployment. Drain the current work unit, checkpoint safely, and start a new session where the workflow permits it.
Does every request reset a sticky session?
A first-assignment session does not reset with every request. For the sticky-session behavior described here (30 minutes on Node4's rotating gateway), the clock starts when the exit is first assigned, not when the latest response arrives.
An inactivity-based policy would be a different rule. Do not substitute that model unless the provider explicitly documents it.
Does rotating an IP remove cookies or log you out?
Rotating an IP does not itself clear your client's cookies. Cookies and proxy routing are separate client settings, although the destination can evaluate the changed source address when deciding whether to keep a session valid.
Keep browser-state management separate from proxy-session management. Reset either one deliberately rather than assume that changing the other resets both.
Can a rotating proxy give you the same IP again?
A rotating proxy can assign an address you have already used. Rotation changes the assignment process; it does not inherently guarantee a unique address on every request.
If uniqueness matters, log observed exits and check whether the service documents that property. Do not infer uniqueness from a rotating endpoint's name.
FAQ
How long do rotating proxies keep the same IP?
Rotating proxies keep the same IP until their assignment policy changes the exit. Per-request rotation, connection-level routing, and sticky sessions use different boundaries, so there is no universal duration.
Can I keep a rotating proxy IP for the length of a sticky session?
A sticky-session policy that supports up to 30 minutes on Node4's rotating gateway provides a maximum assignment window, not a permanent address. Confirm when the timer starts and what happens if the assigned exit becomes unavailable.
Does making another request extend my sticky session?
Another request does not extend a session measured from first assignment. On Node4's rotating gateway the window still ends 30 minutes after the original assignment.
Why did my proxy IP change before the sticky session ended?
Check whether the session identifier, routing settings, or assigned exit availability changed. Compare timestamped exit observations with the provider's documented session behavior before assigning a cause.
Does the same proxy hostname mean I have the same IP?
The same proxy hostname does not prove that your exit IP stayed the same. A gateway can route successive requests through different public-facing addresses.
Is a sticky proxy the same as a static proxy?
A sticky proxy is not the same as a static proxy. Sticky sessions retain an exit assignment within session rules; static assignment is not governed by a rotating session schedule.
How can I test whether my proxy IP is rotating?
Send repeated requests through the proxy to an endpoint that returns the caller's IP. Keep the session configuration constant and record timestamps, addresses, and failures.
One last thing
The same IP is not proof of the same assignment. That distinction matters at expiry: an address can remain visible even when the gateway has made a new routing decision.
Record both what your application requested and what the destination observed. Session identifiers explain intent; exit checks provide evidence. Neither replaces the other.