98IP Proxy

Posted on Aug 21

Measure Residential Proxy Session Stickiness Without Assuming a Stable IP

#python #webdev #testing #automation

Residential proxy providers often describe sessions as "sticky," but that word can hide several different behaviors:

the same exit IP is preserved for a fixed time;
the route remains stable only while requests are active;
the session resets after an idle timeout;
a reconnect silently chooses a new exit;
the provider preserves geography but not the exact IP.

If your automation depends on continuity, test the behavior you actually need instead of treating the marketing label as a guarantee.

Define the contract first

Before writing a test, decide what "stable" means for the workload.

For an authenticated browsing flow, you may need the same exit IP for ten minutes. For market research, keeping the same country and ASN may be enough. For a long-running data collection job, you may care more about predictable rotation than a permanently fixed exit.

Write down:

required session duration;
acceptable idle time;
whether exact IP, ASN, city, or country must remain stable;
maximum reconnect count;
whether failed requests may rotate the route;
what event is allowed to start a new session.

This converts a vague promise into measurable acceptance criteria.

Use one logical session identifier

A stickiness test should keep credentials, endpoint, session token, target, and client behavior constant. Changing multiple inputs at once makes the result impossible to interpret.

A minimal Python probe can record the visible route repeatedly:

import time
import requests

PROXY = "http://user-session123:password@proxy.example:port"
PROXIES = {"http": PROXY, "https": PROXY}

def sample():
    response = requests.get(
        "https://your-authorized-check-endpoint.example/route",
        proxies=PROXIES,
        timeout=20,
    )
    response.raise_for_status()
    return response.json()

for attempt in range(8):
    started = time.time()
    try:
        route = sample()
        print({
            "attempt": attempt,
            "elapsed_ms": round((time.time() - started) * 1000),
            "ip": route.get("ip"),
            "asn": route.get("asn"),
            "country": route.get("country"),
        })
    except requests.RequestException as exc:
        print({"attempt": attempt, "error": type(exc).__name__})
    time.sleep(30)

Use an endpoint you control or are explicitly authorized to query. Do not send repetitive diagnostic traffic to unrelated public services.

Separate active and idle tests

Run at least three patterns.

Active continuity

Send a request at a steady interval shorter than the expected idle timeout. This shows whether the provider preserves the route while the session is active.

Idle recovery

Pause longer than the expected idle timeout, then reuse the same session identifier. Record whether the exact IP returns, the geography remains stable, or a new route appears.

Failure recovery

Introduce a controlled connection failure without changing the session token. A route that rotates only after a failure behaves differently from one that expires on time alone.

Do not manufacture failures against a third-party target. Use a controlled endpoint, a local timeout, or a test environment you own.

Track more than the exit IP

Exact IP stability is useful, but it is not the whole story. Capture:

timestamp;
session identifier hash;
exit IP;
address family;
ASN;
country and region;
connection time;
response status;
error class;
retry count;
client reconnect events.

A provider can preserve the IP while latency becomes unusable. It can also rotate the IP inside the same country while keeping the application flow healthy. The acceptance decision should match the product requirement.

Avoid a hidden retry bias

HTTP libraries, browser frameworks, queue workers, and proxy SDKs may retry automatically. A successful final response can hide several failed routes.

Disable or instrument hidden retries during the test. Count every connection attempt, not only completed logical requests. Otherwise a "stable" session may simply be rotating until one exit works.

Build a simple scorecard

For each test window, calculate:

exact-IP retention rate;
geography retention rate;
successful requests per initial request;
p50 and p95 connection time;
error rate before and after idle periods;
unexpected rotations;
cost per usable session.

Then compare providers or configurations using the same schedule and destination set. Do not compare one provider during peak traffic with another during a quiet window.

A practical pass condition

An example acceptance rule might be:

For a 15-minute active session with requests every 30 seconds, at least 95% of sessions must preserve the same exit IP, 99% must preserve the requested country, and p95 connection time must remain below the application's limit.

Your threshold may differ. The important part is making it explicit before the test.

Compliance

Session stickiness is a routing feature, not permission to evade access controls. Test only authorized systems, respect target terms and rate limits, minimize personal data, and rotate or stop when a workflow's lawful purpose ends.

Disclosure: I work with 98IP. We publish practical proxy testing guidance for authorized automation and data teams. More resources: https://en.98ip.com/?k=dev

DEV Community