Pools and routing

A pool is a reusable routing group. It can combine provider allocations, constrain location behavior, and be public or private. Packages can then reuse the pool instead of duplicating the same supply policy.

Open full size

The list exposes the pool's operational identity and access/randomization policy; open a row to review its full provider allocation.

1. 1Search, create, and other pool controls start from the resource header.
2. 2The current table contract shows name, private state, randomize-ASN policy, and last update.

When to create a pool

Create a pool when at least two packages or access contexts should share a routing policy, or when operators need to change the upstream mix without editing every product. Useful examples include:

• a balanced residential pool with two weighted providers;
• a premium private pool for selected enterprise customers;
• a country-fixed pool for a product that must never leave one market;
• a pool that randomizes across an approved city set;
• a migration pool used to move traffic gradually between suppliers.

Do not create a pool merely to rename one provider when a direct package allocation is clearer.

Configure a pool

1. Give the pool an operator-facing name that states its purpose and expected service class.
2. Add only providers that can satisfy the pool’s promised protocol and geography.
3. Set provider weights. Treat them as relative selection intent, not a guaranteed invoice split.
4. Choose the location policy: preserve customer targeting, fix one location, or randomize within an approved set.
5. Mark the pool private if it is reserved for linked users, resellers, or packages; otherwise keep it public.
6. Attach the pool to a test package and verify targeting, health exclusion, sticky behavior, and analytics.
7. Roll out weight changes gradually and compare provider traffic before and after the change.

Weights operate only among routes that remain eligible. A provider with a configured 60% weight receives none of a country it cannot serve, and a provider that is uniquely capable of a requested city or UDP mode can receive all matching requests.

Route-selection precedence

The following operator model reflects the current routing behavior. Constraints such as active access, protocol, provider health, geography, and session compatibility are applied throughout the selection:

1. Authenticate and resolve entitlement. The gateway resolves the user, package, order, ledger, credential tokens, and destination.
2. Apply linked overrides. An explicitly linked ASN route has the most specific precedence.
3. Honor an explicit provider. If the credential or access context selects a permitted provider, routing validates and uses it.
4. Honor a pool. A selected pool applies its private-access rule, provider weights, and requested/fixed/random location policy.
5. Resolve continent-only targeting. When only a continent is requested, routing selects from eligible countries and providers inside it.
6. Use the configured default path. A package default provider or route applies when no more specific selector is present.
7. Choose by weight. The remaining eligible providers participate in weighted selection; sticky state can make subsequent connections choose the same compatible route.

Failure boundaries

Situation	Gateway behavior	Operator or client action
No provider supports the complete target	Returns an error without widening geography	Remove only a business-approved constraint or correct the catalog
Provider target is unhealthy before selection	Excludes it from a new eligible set	Investigate health and ensure alternate compatible supply exists
Active request times out	Does not replay the application operation	Client performs a bounded retry only when safe
Destination returns 403	Does not assume the exit is bad	Diagnose destination policy; do not rotate identities blindly
Sticky route becomes unavailable	Continuity can break and a compatible route may be selected later	Application must tolerate a new exit and re-establish state
All supply behind a package is removed	New connections fail	Disable sales, communicate impact, and restore a tested route

Change weights safely

Before

Record a closed provider-analytics window and verify spare capacity on the route receiving more traffic.

During

Change one pool or package, send synthetic traffic, and watch health, errors, bytes, requests, and exit behavior.

After

Reconcile the next closed window and retain the audit reason and rollback value.

Use the pool as an input to package creation, not as a substitute for customer entitlement or ledger controls.