Rotating Residential Proxies - Fundamentals

What Is a Hard Session in Proxy Routing

Hard sessions pin a residential exit for longer than a normal sticky window, but they are not a dedicated IP, and the difference matters in logs.

Rotating residential pool Hard session mechanics Updated 2026-06-12

By

Sticky vs hard session: the single difference

A rotating residential proxy picks a new exit on each connection by default. A sticky session attaches a session id to the route so subsequent connections reuse the same exit for the duration of a window. A hard session is the stronger form of that: it asks the gateway to extend the assignment beyond the default sticky window.

That is the full definition. Hard session does not mean a dedicated address, and it does not mean the same TCP socket stays open. Browser automation and HTTP clients close and reopen sockets constantly. What the session id provides is that new connections carrying the same id can keep exiting through the same residential IP while that route is still available.

The session id lives in the username

The Proxynade gateway sits at proxynade.net:2555. Routing options are encoded in the username, not in a separate header or session API call. A generated line for a volume residential hard session looks like:

username: rt97db6958d9-plan-volume-country-us-lifetime-60
password: <your-password>
host:     proxynade.net
port:     2555

The lifetime-60 token sets a 60-minute window. That is the mechanism: the gateway keeps the assigned exit pinned to that username+session combination for up to that duration. Rebuilding the username from memory rather than copying it from the dashboard is how the session token disappears and the route silently falls back to rotating.

The protocol format, whether http://, https://, or socks5:// as defined in RFC 1928, changes how your client connects to the proxy. It has no effect on whether the route rotates, sticks, or holds hard.

When a hard session is the right choice

Use sticky or hard sessions when the target associates multiple requests to a single workflow by IP. The common case: a login page loads on one IP, a form submission follows on a second IP, and the target treats the mismatch as a session anomaly.

Hard session fits when a normal sticky window is too short for the workflow. If a checkout or verification flow takes 45 minutes and the default sticky window is 10, set lifetime-60 and keep the same username in every request across the flow.

For broad scraping where each request is independent, rotation is easier to work with. Pinning to one exit concentrates any blocks or slow responses on that single IP for the life of the session.

Hard sessions are still pool routing

The pinned exit is a residential device in the pool, not a static address. The exit can go offline, get pulled by policy, or expire before the lifetime window closes. When that happens the session fails or the gateway assigns a new exit. Depending on how the failure surfaces, the request log will show the exit IP change.

Static ISP is the product for holding one address over days or weeks. Static ISP proxies are pay-per-IP with unlimited bandwidth, and the address does not rotate. If the requirement is a stable, long-lived identity rather than a temporarily pinned pool exit, Static ISP is the right product.

What the log row should show

The Proxynade dashboard network log shows host, outcome, latency, and byte totals. When a hard session complaint comes in, the first check is whether all requests in the flow are using the same generated username. Two workers, one stale saved credential and one fresh dashboard line, will show two different exit IPs. From the target that looks like a rotation. From the gateway it is just two different session ids.

The byte total in the dashboard includes redirects, retries, failed responses, and challenge pages. The application-level byte counter usually only records successful responses. That gap is why a run can look cheap in the scraper and expensive in the proxy log.

Hard session FAQ

What makes a hard session different from a sticky session? A sticky session holds an exit for a normal rotation window. A hard session asks the gateway to keep that assignment for a longer period than the default sticky behavior allows.

Does a hard session guarantee the same TCP socket? No. New connections carrying the same session id route through the same exit while that route is available. The socket itself opens and closes independently.

When should I use Static ISP instead of a hard session? When you need the same address held over days or weeks. A hard session is still pool routing and the exit can die or expire. Static ISP is a dedicated address with unlimited bandwidth.

Where is the hard session id carried? In the dashboard-generated username, alongside the plan token and optional country code. Copy the line as generated; rebuilding it manually is how the session marker disappears.

Does changing from HTTP to SOCKS5 affect hard session behavior? No. The protocol format changes how your client connects to the proxy gateway. The routing mode is set by the username tokens, not the scheme. SOCKS5 username/password auth is defined in RFC 1929.

Quick checks

  • Copy the generated line from the dashboard; do not reconstruct it.
  • Verify every worker in the flow uses the same username.
  • Set lifetime-<minutes> to cover the full workflow duration.
  • Check the dashboard byte total, not just the app-level counter.
  • Switch to Static ISP when you need a stable address over days.