A rotating proxy can keep returning the same public IP even when the endpoint is healthy. The usual causes are an intentionally sticky credential, a reused session parameter, an open pooled connection, or a provider lifetime that has not expired. Test each layer separately before changing several settings at once.
Quick answer
Change the session, close the connection, and retest the same route.
First confirm that the credentials request rotation rather than a sticky session. Then create a new provider session ID, close pooled connections or restart the client, and compare several successful samples through the same endpoint.
Match the symptom to the first check
| What you observe | Likely explanation | First controlled check |
|---|---|---|
| Every successful request shows one IP | Sticky credentials, reused session ID, or one open connection | Use a new session ID and a new connection |
| The IP changes only after restarting the client | Connection pooling or persistent HTTP connection | Disable reuse for one diagnostic run |
| The IP changes when the session value changes | The previous session was intentionally sticky | Choose explicit rotation or create unique session IDs |
| The IP changes before the requested lifetime | Exit device left the pool or became unavailable | Check the provider's lifetime wording and logs |
| Only some attempts succeed | Retries are hiding failed exits or policy blocks | Record each attempt, including errors |
| IPv4 rotates but IPv6 does not | The address families are using different routes | Test IPv4 and IPv6 independently |
1. Confirm which route you are testing
Record the proxy hostname, port, protocol, username format, session parameter, and target used for the test. A browser extension, operating-system proxy, command-line client, and application-specific proxy can follow different routes even on the same device.
Test only a proxy account and target you are authorised to use. Prefer the provider's documented test endpoint or Aerod's Proxy Rotation & Sticky Session Monitor. Do not compare one request through the configured route with another request made directly.
2. Check for sticky credentials and session parameters
Residential and mobile proxy providers often encode session controls in the username. The exact syntax is provider-specific, but the design is similar:
- A rotation mode can ask the provider to select an exit for each new request or connection.
- A session identifier can ask the provider to keep one exit for that named session.
- A lifetime or duration parameter can request how long that session should remain stable.
- Country, region, or city parameters can narrow the eligible pool.
IPRoyal documents separate randomised and sticky formats. Decodo documents a session parameter for distinguishing sticky sessions and notes that a duration value alone may not create the intended session. Do not copy parameter names from one provider into another provider's credentials.
For a clean comparison, keep the endpoint, protocol, target, and geographic filters unchanged. Run one sample set with session ID test-a, then another with test-b. If the exit changes only when the session ID changes, the previous result was behaving like a sticky session.
3. Eliminate connection pooling
HTTP/1.1 supports persistent connections, and common clients maintain pools so they can reuse an existing TCP connection. Python Requests, for example, applies connection pooling within a Session. Reusing that connection can make a per-request proxy plan look sticky if the provider selects an exit when the connection is established.
For one diagnostic run:
- Finish or cancel the existing test.
- Close the browser tab, client session, or connection pool.
- Restart the application if it offers no clear way to close the pool.
- Create a fresh provider session value.
- Repeat the same target request several times.
If rotation appears only after new connections, the original test measured connection reuse as well as provider rotation. That is useful evidence: applications that maintain long-lived connections may not exhibit the same cadence as simple one-shot requests.
4. Separate requested TTL from actual exit lifetime
A provider's time to live, session duration, or lifetime setting normally describes how long the service should try to preserve an exit. It is not necessarily a minimum guarantee. IPRoyal notes that a residential device can leave the pool early. Decodo likewise documents premature rotation when a mobile device goes offline.
Interpret the timing carefully:
- Same IP before expiry: expected for a working sticky session.
- New IP after expiry: consistent with the requested lifetime.
- New IP before expiry: possible exit churn, health removal, or connection loss.
- Same IP after expiry: possible pool reuse, a still-open connection, or the same exit being selected again.
“Rotate every request” also does not mean every consecutive public IP must be unique. The provider can select an address already seen in the sample, especially in a narrowly filtered pool.
5. Make retries visible
Automatic retries can bias a rotation test. If three exits fail and one exit succeeds, an application may show only the successful result. Connection libraries can retry connection, read, redirect, or status failures according to their configuration.
For troubleshooting, record:
- Attempt number and timestamp.
- Whether the request succeeded or failed.
- The error class or status code.
- The public IP only for successful responses.
- Whether a retry occurred before the visible result.
Temporarily reduce automatic retries only if the client supports that safely. Do not treat errors as rotated IPs, and do not omit them when calculating how many samples completed.
6. Test IPv4 and IPv6 independently
IPv4 and IPv6 are separate address families. A proxy endpoint may support only IPv4, may expose different exits for each family, or may allow the client to reach an IPv6 target outside the expected path. Use an address-family-specific test target when available.
Label each result as IPv4 or IPv6. A rotating IPv4 address does not prove IPv6 followed the proxy, and the absence of an IPv6 result does not by itself indicate a leak. Read Public vs Private IP Addresses before comparing local adapter addresses with public test results.
7. Run a bounded test with Aerod's monitor
Proxy Rotation & Sticky Session Monitor offers two test paths:
- Configured route: the recommended default. It tests the route already configured for the browser page.
- Advanced proxy credentials: a direct diagnostic option with a clear credential and transport warning.
Start with configured-route mode. Use a small, consistent sample count, keep the target and settings unchanged, and wait for the run to finish. The monitor classifies the successful observations in that bounded run as stable or rotating.
How to interpret the monitor result
| Result | What it supports | What to do next |
|---|---|---|
| One IP across all successful samples | The tested route appeared stable during this run | Change the session ID and close pooled connections |
| Multiple IPs | The tested route rotated during this run | Compare cadence with the provider's documented mode |
| Early change during a sticky test | The exit did not remain stable for the full observed period | Check exit churn, disconnects, and lifetime wording |
| Partial failures | Some requested samples did not complete | Review authentication, proxy availability, policy, and network errors |
| Configured route differs from application | The browser page and application may use different routes | Test the application's own proxy settings separately |
What this test proves and does not prove
The monitor records the public IPs observed for successful samples through the selected test path. It can show whether that bounded sample appeared stable or rotating.
It does not guarantee future provider behavior, identify why an exit changed, prove that every device application uses the same route, or make a provider's pool unique. A stable result is an observation, not a provider guarantee. Confirm route ownership separately with IP Lookup and use Proxy/VPN Detection only as a signal, not as proof of route correctness.
Rotation troubleshooting checklist
Change one variable at a time
- Record endpoint, port, protocol, and target.
- Confirm whether credentials request rotation or stickiness.
- Create a new unique session ID.
- Close pooled connections or restart the client.
- Keep geographic filters unchanged.
- Record failures and retries, not only successful IPs.
- Compare the observed lifetime with provider wording.
- Test IPv4 and IPv6 separately.
- Repeat a bounded run before drawing a conclusion.
FAQ
Why does my rotating proxy keep the same IP?
The most common causes are a reused sticky session ID, provider credentials that request a persistent session, an open pooled connection, or a rotation lifetime that has not expired. Test those controls separately before treating the route as broken.
Does rotating per request guarantee a different IP every time?
No. It describes when the provider may select an exit, not a promise that every consecutive result will be unique. Available pool size, provider policy, and failed attempts can produce repeated observations.
Can connection pooling stop a proxy from rotating?
It can make a test appear sticky. HTTP clients and browser sessions may reuse an existing TCP connection, so the provider may not receive a fresh connection on which to select another exit.
Why did the proxy IP change before its advertised TTL?
A TTL is usually a maximum requested lifetime, not a guarantee. The exit device can disconnect, become unhealthy, or leave the provider pool before that time.
Should I test IPv4 and IPv6 separately?
Yes. They are separate address families and can follow different routes. A changing IPv4 result does not prove that an IPv6 request used the same proxy path.
What does Aerod's Proxy Rotation Monitor prove?
It records the successful samples observed through the tested route during that bounded run. It does not guarantee future rotation, describe every application on the device, or prove why a failed sample failed.