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.
Worked cost: package bill & operating effort
Price example checked on 11 October 2026: the entry packages below have the same monthly bill but different quantities and assignment models. Use the existing pricing and checkout next step to confirm current packages before ordering; taxes, options, promotions, location and availability can change the final total.
| Package | Observed bill | Assignment & arithmetic |
|---|---|---|
| 5 private proxies | $12.00 USD/month; $0.00 USD setup | Assigned to one customer. $12.00 divided by 5 is $2.40 per listed address per month. |
| 10 shared proxies | $12.00 USD/month; $0.00 USD setup | Each address is shared between three users. $12.00 divided by 10 is $1.20 per listed address per month. |
Those per-address figures are package arithmetic, not measured cost per successful request or a guarantee of ten usable routes for your destination. Review private access and exclusive assignment when that control matters, or shared access and its operating compromises when the workflow tolerates other assigned users influencing load and reputation. Test the same permitted client and destination before comparing usable capacity.
Illustrative operating effort, not measured: if investigating a failed check takes 15 minutes, record those 15 minutes against whichever route failed. This is your team’s time, not an extra charge from Mexela. No labor rate, measured retry rate or claim that either plan causes more work is assumed. Add observed setup, validation and diagnosis time to your own budget alongside the plan bill, applicable taxes and options; a cheaper listed address does not by itself establish a lower operating cost.
After separating address assignment from session behavior, use the monthly proxy cost calculator to compare current private and shared package totals and setup fees. The proxy plan selector matches a listed package to your minimum quantity, exclusivity, protocol and authentication requirements; it does not establish that a plan rotates IPs.
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.
Can a shared static proxy keep the same exit IP?
Yes: sharing describes who can use the assignment, while static describes address continuity. Ask the provider about both properties separately. For an allowlisted API, a stable address can satisfy continuity while still leaving reputation or concurrent load outside your control. Select exclusivity only when the workload needs that additional control.
For the related implementation or diagnosis, plan stable egress for an allowlisted API.
Before buying a shared proxy, confirm these assignment details
A search for shared proxies does not specify the workload. Confirm who can use the assignment, whether the exit must remain stable, which client and protocol are required, and what happens when an assignment is replaced. Keep exclusivity, address continuity and destination acceptance as separate requirements.
Read the current shared proxy offering for commercial terms, then use the same small acceptance test before scaling. A lower package price does not establish that the route meets an allowlist, account-session or protocol requirement. Keep unsupported requirements visible in the comparison.