I see the same hard-session ticket in a few forms. The user says the proxy rotated even though hard mode was selected. Then the log shows two requests using the new generated line, and one worker still using an old sticky line from a saved browser profile. From the target side that looks like a sudden IP change. From the gateway side it is just two different usernames asking for two different routes.
Use hard mode after sticky almost works: login loads, challenge page returns, a redirect or retry opens another connection, and the next request leaves through a different residential exit. That is enough for some targets to treat the flow like it changed owners.
Rotating residential traffic can move to another exit often. Sticky routing puts a session id on the route for a normal window. Hard session is Proxynade's label for the stronger version of that sticky route request. It asks the gateway to keep the assigned exit tied to that id longer than normal sticky behavior.
That does not mean the same TCP socket stays open. Browser automation closes sockets, opens sockets, retries, and follows redirects quietly. The useful part is that new connections carrying the same hard session id can keep leaving through the same exit while that route is available.
The generated line matters more than the scheme
The Proxynade host stays proxynade.net:2555. Hard mode is carried in the dashboard-generated username, along with the session id. Copy the line as generated. Rebuilding it from memory is how the hard-session marker disappears.
HTTP, HTTPS, SOCKS5, and socks5h are only client formats. They change how the tool connects to the proxy. They do not decide whether the route is rotating, sticky, or hard. A stale username in one worker can look like a protocol problem until the request log is lined up.
A hard session is still pool routing. It is not Static ISP. The exit can die, expire, or get pulled by policy, and the session can fail or move when that happens. Static ISP is the product for holding one address over days or weeks.
If the chosen exit is slow, flagged, or already disliked by the target, the whole run sits on that problem until the session is replaced. For broad scraping where each request stands alone, rotation is usually easier to work with.
The log row I want has the generated username, session id, plan, protocol, status, response size, retry count, latency, exit IP when available, and provider-metered bytes. Without that, a hard-session complaint turns into guesswork.
The bandwidth number is another place the app can lie. It may count only responses it saved. Provider-metered bytes include redirects, retries, failed responses, challenge pages, and bodies the code downloaded then threw away. That is why a run can look cheap in the scraper and expensive in the proxy log.