IP Pools & Gateway Endpoints
An IP pool is a collection of exit addresses a proxy service can provide. A gateway endpoint is the host and port through which your application reaches those exits. A gateway lets you use the pool without managing a separate connection record for every exit IP.
The pool determines which exits the service can offer; the gateway provides access to them. Whether your traffic keeps an assigned address or moves between addresses is a separate choice, covered in Static vs Rotating Proxies.
How IP pools and gateways work
Behind each usable exit is a working connection: through a server, a household connection, or a cellular connection. An address recorded in a database is not enough to relay traffic. The service must have a route through the equipment using that address and permission to use the connection.
When you connect through a gateway, the service identifies your account and the pool you can access. It applies your selection settings and routes traffic through an eligible exit. The destination receives that connection from the exit IP; the gateway address is the entry point on your side.
For example, a product-monitoring application may need French exits for one set of checks and German exits for another. With suitable pool access, it can keep the same gateway and change the location setting for each job. The service handles the choice of available exits, so the application does not need to maintain its own worldwide proxy list.
A provider can operate several pools, separated by network type, location, or customer allocation. One account may use a shared selection; another may have an assigned subset. Connecting to the same gateway does not establish that both accounts can reach the same exits.
Gateway endpoints and proxy lists
Connection details normally include a host, a port, the supported proxy protocol, and the required authentication method. The host and port tell your software where to connect. Credentials or an allowed source IP establish access. Product and routing settings tell the service which exits to use.
For an illustrative endpoint such as gateway.example:8000, the hostname identifies the entry service and the number is its port. Neither reveals the size of the pool. Depending on the product, changing a port might select a protocol, a location, or an assigned exit. Port numbers only have the meaning the provider gives them.
The connection list you receive can therefore represent different arrangements:
| Access arrangement | What a list entry selects | How you choose an exit |
|---|---|---|
| Direct proxy addresses | A proxy reached at its own address and port | Your application chooses a proxy from the list. |
| Gateway with assigned ports | An exit assigned to that gateway port | Your application chooses the port for the required assigned IP. |
| Gateway with pool selection | A pool and routing settings | The service selects an eligible exit using those settings. |
A gateway can consequently serve fixed addresses as well as a rotating pool. In an assigned-port product, the entry point may remain unchanged even when the provider replaces the IP behind it. Conversely, generating many connection records for a rotating gateway does not reserve the same number of unique exits. An endpoint generator prepares settings, not necessarily an address allocation.
Location and session settings
Pool selection starts with the product or allocation your account can use. Supported filters then narrow that choice: for example, country, city, network, or IP version. A location check that needs any German exit has a wider potential selection than one that also requires a particular city and network.
Services may accept these settings through username parameters, dedicated endpoints, or dashboard configuration. The syntax is specific to the service. A sticky-session setting adds another instruction: attempt to reuse the exit already assigned to that session. It does not add addresses to the pool or reserve the whole pool for you.
The gateway's location and the exit's location serve different purposes. A regional gateway can improve the route from your application to the service, while a separate filter selects the country seen by the destination. Looking up the gateway's IP location therefore does not verify your requested exit country.
Narrow filters also affect availability. A city listed in the selector may have no suitable exits online at a particular moment. The service's behavior in that case matters: an error lets you decide whether to wait or relax a condition. Where a product offers a fallback, its permitted changes must still suit the job; completing a city-specific check through an unwanted location would give the wrong result.
IP pool size
The following approximate benchmarks help put pool sizes in perspective. They are starting points for assessing an offer, not fixed limits on network size. A provider's inventory, unique IPs recorded over a period, and exits available to your account now are different quantities.
Datacenter pools. 50,000–100,000 IPs is already a substantial datacenter pool. A provider managing defined address ranges can count its configured inventory accurately. The full capacity of its subnets may be larger because some addresses are reserved or unavailable. Your package may include only part of that inventory: a provider with 100,000 IPs does not automatically give every customer all 100,000.
Native ISP pools. 20,000–50,000 IPs is a useful benchmark for a substantial ISP offering. These pools are generally smaller than datacenter pools. They consist of managed proxy addresses registered with internet access providers. Check how many addresses are available in the countries you need and which part of that inventory your plan includes.
Residential pools. An advertised 20,000,000 IPs may count addresses encountered over a week or month, or reflect an estimate based on activity. For cautious initial planning, work with an assumption of 100,000–1,000,000 distinct IPs across multiple locations over your intended working period, then check whether the service can meet your requirement. Even access to 1,000,000 suitable exits is not established by a much larger headline total. Devices connect and disconnect, addresses change, and country, city or network filters narrow the selection. This working range is not a measurement of the whole network or the number of IPs online simultaneously.
Mobile modem farms. An IP-pool total tells you little about the capacity you are buying. The mobile carrier controls public IP allocation; the proxy provider operates the modems and SIMs using its network. Access to a modem does not reserve a fixed list of future IPs. Compare available modem connections, carriers, locations and shared or reserved access.
Rotating mobile pools supplied by distributed devices. Use tens of thousands of IPs, or 100,000–300,000 for a broader selection across locations and carriers, as a cautious working scale to verify over your intended period. An advertised multi-million total does not guarantee that access, and one country or carrier can offer much less. Devices supplying exits, including those running connection-sharing software (SDKs), must be online, available to relay traffic and using mobile data. Installed apps are not active exits. Device counts and IP counts also differ: IPs can change, and several devices can share one public IP through carrier-grade NAT (CGNAT).
IP diversity and pool usage
A pool's usefulness depends on where its addresses come from as well as how many it contains. Many distinct IPs can belong to one subnet or routing network. A task that needs several internet providers gains less from those addresses than from a selection across the required networks. Address ranges and autonomous system numbers, or ASNs, help describe that distribution; different IPs alone do not prove broad network coverage.
Demand is uneven too. Suppose customers of a particular service rarely request Mongolia but frequently request Frankfurt am Main. The Frankfurt exits may be used repeatedly while addresses elsewhere receive little traffic. This hypothetical example shows why global supply does not describe pressure on the part of the pool your task needs. A large unused selection in another country cannot satisfy a Frankfurt-only request.
In a shared pool, an exit may also carry other customers' traffic, either concurrently or at another time. Its recent use can matter when a destination applies limits to a source IP. Heavy use is not, by itself, proof that an address is blocked; equally, a large worldwide pool does not establish that a particular exit has little previous activity.
Repeated addresses can result from a narrow eligible set, current availability, session settings, or the service's selection policy. Selection need not visit every IP in turn. Repeats are evidence about what your account receives under those conditions, not a direct measurement of the provider's entire inventory.
Connection limits and performance
IP count and traffic capacity measure different things. One exit can carry several connections, while an account with access to a large pool may still have a limit on simultaneous connections or request rate. Creating more endpoint records does not increase those account limits. Traffic allowance, connection capacity, and address availability each affect how much work you can complete.
Performance depends on the route from your application to the gateway, the connection used by the exit, and the destination's response. A nearby gateway may improve the first part, but it cannot remove a slow household uplink or a congested cellular connection further along the route. Regional entry points are useful when they improve your connection to the service; they are not substitutes for testing the full path.
Gateway availability and exit availability are separate as well. A reachable gateway can still fail to find an exit matching your filters. With automatic selection, the service can use another eligible exit for later connections when one disappears. A fixed assignment may instead need replacement. These cases require different responses from a failure to reach the gateway itself.
Checking a gateway and its exits
Start with a request through the supplied endpoint to a destination that reports the source IP. This checks that traffic passes through the proxy and shows the exit used for that connection. Compare the returned location and network with your settings, rather than comparing them with the gateway's DNS address. Location databases can disagree, so a label from one checker is not proof of how every website classifies that IP.
Next, observe the pool under your intended settings. Record the time, exit address, filters, and session mode across new proxy connections. Count distinct addresses and how often each returns. A test intended to sample different exits should not deliberately hold one through a sticky session or reuse a single connection throughout. Repeat the sample at times relevant to your workload to see whether available supply changes.
Then run the actual task at a representative request rate. Record successful results, errors, and response times. Separate failures to connect or authenticate at the gateway from a shortage of matching exits and responses from the destination. The gateway's error details can help distinguish them; changing exit IPs will not repair an incorrect password or an exhausted traffic allowance.
Use these observations to choose access that fits the work. A known assigned list gives your application explicit control over which listed address it uses. A gateway with pool selection lets you request the required kind of exit while the service manages the available candidates. In either case, the useful result is dependable access to the addresses and capacity your task needs, rather than the largest unexplained IP total.