Mid-session exit changes are the silent failure mode
The run report says timeout, missing selector, MFA loop, or page did not load. The trace shows the first page loaded fine. The break happened later, after the browser was already signed in and the rotating pool handed it a different exit.
A cleaned-up excerpt from a typical seller dashboard run shows the shape of the problem:
job: shopify-orders-poll
profile: chrome-profile-17
10:14 login ok via 45.129.xx.18
10:15 /admin/orders loaded
10:16 pool returned 172.96.xx.44
10:16 /admin/products requested from new exit
10:17 verification page returned
10:18 script still waiting for table.ordersThe last line is what ends up in the ticket. It is not the actual failure. The site treated the IP change as a different visitor and dropped the authenticated state. The script waited for a selector that never appeared because the page was a 403-class re-verification wall.
Static ISP proxies avoid this by design. One ISP-backed IP stays assigned until you rotate it on purpose.
The decision splits on whether requests are independent
Rotating residential works for jobs where each request can stand alone: public catalog pages, search result pages, regional price checks, availability checks, short stateless lookups. The exit for request N has no effect on request N+1.
Static ISP works for saved browser profiles, seller dashboards, fixed IP allowlists, active carts, profile edits, and any account that tracks session history. The exit for the login must be the same exit for every subsequent page in that session.
The messy cases sit in the middle. A scraper slowly acquires account-level features — saved searches, preferences, stored state — and nobody revisits the proxy setup. The first sign is usually a 2FA page appearing mid-run.
Per-IP vs per-GB billing shifts the cost at high bandwidth
Rotating residential plans bill per gigabyte transferred. On Proxynade, Volume Residential is $0.89/GB and Premium Residential is $5.00/GB. Static ISP is pay-per-IP with unlimited bandwidth — the bandwidth cost is flat once the line is assigned.
A browser session moves more traffic than the application typically admits. The app may record one HTML payload or one parsed result, while the proxy billed for redirects, retries, TLS negotiation, scripts, images, fonts, background calls, partial loads, verification pages, and failed attempts before the keeper.
A retry loop that ultimately produces nothing still moves data through the pool. That gap between what the app saved and what the proxy billed is where per-GB pricing surprises people. If the same session runs daily and the bandwidth is predictable, a static ISP line often has a lower effective cost than the per-GB equivalent.
| Job type | Exit requirement | Billing fit |
|---|---|---|
| Public catalog scrape | None — any exit per request | Per-GB rotating |
| Regional price check | Country only | Per-GB rotating with country token |
| Account dashboard poll | Same IP for the session lifetime | Per-IP static ISP |
| Daily account activity | Same IP across sessions | Per-IP static ISP |
| Short authenticated lookup | Sticky window covers the flow | Either — check break-even |
Rotating with a sticky window is not the same as static
On a Proxynade rotating pool, the lifetime-<minutes> token in the expanded username sets the rotation window. A login flow that needs 30 minutes on one exit would use a username like rt97db6958d9-plan-volume-country-us-lifetime-30. The pool holds the same exit for up to that window.
This works for bounded flows. It does not work for accounts that stay active across multiple sessions on different days. When the window expires, the pool assigns a new exit regardless of whether your account flow is finished. A static ISP line has no window — the IP stays assigned until you release it.
The other difference is predictability. A sticky window on a rotating pool still depends on the pool recycling the exit correctly. A static ISP line is a fixed assignment you can read in the dashboard, verify in a log, and allowlist if the target supports IP allowlisting.
Static ISP does not fix broken retry logic
Assigning a static IP to a job that hammers a target all day does not help. The site will block or rate-limit the IP the same way it would with a bad rotating pattern — except now there is no automatic exit change to recover from it.
Static ISP is for sessions that need continuity, not for jobs that need volume. Volume and exit diversity stay on the rotating pool. The failure mode on static is a blocked IP with no fallback; the failure mode on rotating is a mid-session exit change. Know which failure mode your job can tolerate before picking.
Static ISP vs rotating FAQ
When should I use static ISP instead of rotating residential? Use static ISP when the same account must reach the target from the same IP across multiple sessions. Use rotating residential when each request is independent and exit continuity does not matter.
Why does a mid-session IP change break account-based jobs? Sites track the IP as part of session identity. A new exit mid-session looks like a different visitor, which triggers re-verification or resets the authenticated state.
How does static ISP billing compare to rotating residential billing? Static ISP is billed per assigned IP with unlimited bandwidth. Rotating residential is billed per gigabyte transferred. High-traffic browser sessions often cost less on static ISP once the bandwidth crosses a break-even point.
What is the break-even point between static ISP and rotating residential? It depends on the per-IP price and your per-GB rate. At $0.89/GB for Volume Residential, a session that moves more than roughly the cost of one static IP in bandwidth favors static. Check the Proxynade pricing page for current rates.
Can a rotating proxy hold a sticky session long enough for account work? Yes, if the rotation window covers the session. On Proxynade the lifetime-<minutes> token in the username sets the window. The risk is that the window expires mid-flow or the pool recycles the exit before the window closes.
Decision checklist
- Does the same account need the same IP more than once? Use static ISP.
- Are requests stateless and independent? Use rotating residential.
- Estimate session bandwidth before comparing per-IP and per-GB costs.
- Check whether the target supports IP allowlisting — only static ISP can use it.
- If using a sticky window, confirm the window outlasts the longest expected flow.
- Read the dashboard network logs: host, outcome, latency, and byte totals tell you where the real cost is.