Private versus shared describes who may use an assigned proxy, while static versus rotating describes how its exit address behaves over time. These are separate axes: a private endpoint can be static or part of a rotating pool, and a shared service can also keep or change exits. Choose access and continuity independently from the workload.
Scope: this guide compares assignment and session behavior. For network ownership such as residential or datacenter, use the network-type comparison; for the full taxonomy, visit the Proxy Basics hub.
Private access: controlled assignment
A private proxy is assigned under terms that restrict current use to one customer. This reduces simultaneous activity outside that customer’s control and gives load and reputation a clearer baseline. Confirm whether exclusivity applies to the IP, gateway credentials, port, or only a slice of capacity, and ask what happens during replacement.
Private does not mean anonymous, permanently owned, or accepted everywhere. Destinations still see the provider network and apply their own account, traffic, and reputation signals.
Shared access: lower control over concurrent history
A shared proxy serves multiple assigned customers. It can reduce cost for low-risk, stateless work, but another customer’s load or activity can affect latency and reputation. Ask how access is controlled, how capacity is managed, and whether sessions are isolated.
Expected observation: a suitable shared route should still authenticate consistently and follow documented limits. Large unexplained latency swings, frequent destination challenges, or exits that violate the stated session rule are signals to investigate rather than assumptions built into the word shared.
Static sessions: continuity for allowlists and state
A static session keeps the same exit for the documented assignment or session period. It suits source-IP allowlists, repeatable monitoring, and browser sessions that depend on continuity. Static is a service behavior, not an ownership guarantee; maintenance, abuse response, or plan changes can still replace an address.
Record the expected lifetime and replacement conditions. If the workflow cannot tolerate an address change, define recovery before deploying it.
Rotation: controlled address changes
A rotating service selects another exit per request, on a timer, or when a session token changes. Rotation can distribute independent authorized requests, but it can break account continuity, make evidence harder to reproduce, and trigger security checks when locations jump.
RFC 9110 defines HTTP semantics, but it does not make rotation safe for a destination or account. The application must preserve authorization, apply rate limits, and handle retries without multiplying requests.
Decision table
| Requirement | Likely fit | Reason to verify |
|---|---|---|
| Stable server allowlist | Private static | Confirm replacement and renewal behavior |
| Low-risk stateless checks | Shared static or documented rotation | Measure load and reputation variance |
| Persistent browser session | Private static or sticky session | Avoid unexpected location changes |
| Independent regional samples | Controlled rotation | Define trigger, geography, and evidence |
After choosing a row, test one endpoint in the real client. Compare direct and proxied exits, repeat the promised session interval, and classify authentication, network, TLS, and destination responses separately. The proxy verification guide provides that sequence.
Authorization and evidence limits: rotation is not permission to evade blocks or rate limits. Protect credentials, cap concurrency, retain a non-secret endpoint identifier in logs, and stop when a destination response indicates access or policy limits.
Price the model only after both axes are defined
Write access as private or shared and continuity as static, sticky, or per-request rotation, then add protocol, country, authentication, and expected volume. Compare current proxy pricing only for models that match that brief, beginning with the smallest representative set.
For provider-level questions about support and terms, continue with the reliable proxy service checklist.