Rotating vs sticky sessions explained in one support note: the gateway and port do not change. The dashboard-generated username changes how the route behaves. If somebody fixes a session problem by changing 2555 to some random port, they are debugging the wrong thing.
The useful comparison is not provider name against provider name. It is route behavior against the page that pays the bill: status codes, retries, usable rows, and billed bytes.
Rotating mode changes routes. It is the one I use for public, stateless collection where the next request does not need to remember the last one. Price checks, broad catalog reads, simple SERP pulls. If the target state matters, rotation is usually the first thing I question.
Sticky mode keeps a session identifier mapped upstream. Same identifier, same route for the window. Different identifier, different session. This is the mode for short chains where cookies, queue state, or a server-side session needs the same exit for more than one request.
Hard session is the longer pin. It keeps the same IP until that IP dies or the line is released. Useful when the workflow really needs a stable route, annoying when that route starts returning weak responses and everyone forgets it is pinned.
HTTP, HTTPS, SOCKS5, and socks5h all point at proxynade.net:2555. Session mode is carried by the dashboard-generated username, not by the protocol label and not by a separate sticky port.
scheme://USERNAME:PASSWORD@proxynade.net:2555My rule is plain: rotate for stateless collection, sticky for short stateful flows, hard for long route continuity. Do not share one sticky identifier across unrelated workers just because it works once. That makes the logs useless later.
When a run looks expensive, compare Usage Logs against the app counter. The app may skip retries, redirects, failed responses, discarded bodies, and late provider-metered bytes. The proxy side still counted the traffic.