Residential Proxy Supply Chain Explained: Where the IPs Come From

Quick Answer

Residential proxy capacity begins with Internet connectivity, not with a ready-made proxy pool. Internet number resources are used by an ISP access network, and a subscriber connection obtains a public egress context.

That connectivity can become proxy-capable supply through several different models: an explicit participant application, an embedded SDK with separate user opt-in, an authorized supplier or partner, a direct ISP or address-block relationship, or – in a distinct unauthorized category – compromised devices or hidden proxy code.

The capacity may then pass through a supply operator, aggregator, wholesaler, reseller, or customer-facing proxy provider before it becomes raw proxy-capable inventory.

This is a conceptual supply-chain model, not a universal industry architecture. The branches are alternative models, not stages every provider uses.

Becoming known to a provider also does not make a resource eligible, available, or allocatable. Those decisions belong to downstream pool management.

Key Takeaways

• Residential proxy supply does not come from one universal source. Documented models include explicit participant apps, opt-in SDKs, authorized upstream suppliers, reseller arrangements, and separate ISP-address relationships.
• A residential IP address is not a household, subscriber, device, peer, or proxy endpoint. Those entities do not map one-to-one.
• NAT can let several devices share one public IP, while carrier-grade NAT can let several subscribers share one public IPv4 address.
• Dynamic address allocation means the public IP associated with a connection can change over time.
• A customer-facing proxy brand may be different from the organization that originally obtained or operated the supply.
• Residential classification describes network context. By itself, it does not reveal the sourcing or consent mechanism behind a proxy resource.
• Clear disclosure, affirmative participation, withdrawal controls, supplier accountability, and abuse controls are supply-integrity questions. Ethical best practices and legal requirements must be evaluated separately.
• Potential supply, online supply, raw inventory, eligible pool size, and the resources observed by one user are different measurements.

Start With Residential Connectivity, Not a Proxy Product

A residential proxy uses a public network path associated with consumer or subscriber Internet access as the outward-facing route for traffic.

That does not explain how the provider obtained permission or technical access to use the path, who operates the participating resource, or whether another organization sits between the original source and the customer-facing service.

For the general request path, proxy gateway, exit behavior, and uses of this proxy category, see Residential Proxies Explained.

This article owns a different question: what can happen upstream before residential connectivity reaches a provider as raw proxy-capable inventory?

At the highest level, the technical context is:

Internet Number Resources → ISP Access Network → Subscriber Connection / Public Egress Context

This line is intentionally simple. It does not mean every address moves directly from one registry to one ISP and then permanently to one household.

Address allocation, routing, customer assignment, and public egress are separate relationships, and their implementation varies by network.

ARIN’s official IPv4 guidance provides one registry-level example: ARIN allocates blocks to ISPs for reassignment to their customers.

Registry allocation establishes number-resource context. It does not establish that an address is a proxy, that a particular device uses it, or that anyone has authorized commercial proxy traffic.

Residential IP Is Not a Household, Device, or Peer

The most important technical guardrail is:

Residential IP ≠ Subscriber ≠ Household ≠ Device ≠ Peer ≠ Proxy Endpoint

These entities can be related, but none is a reliable one-to-one substitute for another.

Entity	Meaning in this article	What it does not prove
IP address	A network-layer address used in a routing or egress context	One permanent person, household, device, or proxy resource
ISP	A network operator that provides Internet access and uses or manages address resources	That it is also the proxy provider or supply operator
Subscriber	The customer or account receiving Internet service	That the subscriber owns every connected device or personally joined a proxy network
Household / premises	A physical or service location that may have one subscriber connection	One device, one public IP, or one participant
Residential connection	The access relationship between subscriber premises and an ISP network	A proxy resource by itself
Household gateway / CPE	A router, modem, or other equipment connecting local devices to the ISP	Every device behind it or necessarily the device running participant software
Device	A computer, phone, router, TV, streaming box, or other networked system	A unique public IP or an authorized proxy peer
Peer / participant	A resource enrolled in a particular provider’s or operator’s system	Every device sharing the same connection
Proxy endpoint	The client-facing address or interface used to access a proxy service	The residential exit device, household, or original supply operator
Exit IP	The public address observed by the destination for routed traffic	One device, one subscriber, one household, or one sourcing model
Supply operator	An organization that obtains or manages proxy-capable participation or capacity	That it sells directly to the final proxy customer
Customer-facing provider	The organization that sells or exposes proxy access to the customer	That it originated, owns, or directly operates every underlying resource

One Household Connection Can Serve Many Devices

A home router can connect laptops, phones, televisions, consoles, and other devices to one Internet connection.

Network Address and Port Translation can make traffic from several internal hosts appear under one public IP. RFC 4787 documents the limited technical point that NAPT allows multiple internal hosts to share a single public IP address simultaneously.

If participant software runs on one device behind that gateway, the destination may observe the connection’s public egress IP – not a unique address that identifies the participating device.

Observing one exit IP therefore does not tell an outside observer how many local devices exist or which one carried the software.

One Public IPv4 Can Represent Several Subscribers

Address sharing can also occur inside the ISP network.

In a carrier-grade NAT context, several subscriber connections can share public IPv4 resources. RFC 6598 reserves Shared Address Space for service-provider NAT deployments, while RFC 6888 defines requirements for carrier-grade NAT devices.

CGNAT is not used by every ISP or connection.

Its significance here is narrower: one observed public IPv4 cannot be assumed to identify one subscriber, let alone one household device or one proxy participant.

An Address Can Change Over Time

Residential addresses are not always fixed.

RFC 2131 defines dynamic DHCP allocation as assigning an address for a limited period or until it is relinquished.

The RFC does not specify how frequently any particular ISP changes subscriber addresses, and this article does not infer an ISP-specific lease or reassignment interval.

The counting consequence is important.

One subscriber connection can appear under different public IPs at different times, while one public IPv4 can represent multiple devices – or, in some networks, multiple subscribers.

IP counts cannot be converted directly into device, subscriber, or household counts.

Residential Classification Does Not Reveal Sourcing

An IP can be described as residential because of its ISP, ASN, routing context, commercial intelligence data, or another classification method.

There is no protocol flag that explains whether the proxy capacity came from an opt-in app, an SDK, an upstream supplier, an ISP relationship, or unauthorized software.

Commercial IP-intelligence systems also expose different fields.

For example, MaxMind’s official GeoIP documentation separates ISP, organization, ASN, geolocation, and connection-type data and publishes accuracy limitations.

A classification is therefore sourced information with a methodology and uncertainty – not proof of a particular supply relationship.

A Branching Residential Proxy Supply Chain

The conceptual starting point is:

Internet Number Resources → ISP Access Network → Subscriber Connection / Public Egress Context

From there, different supply branches are possible:

• Explicit Participant App → Supply Operator
• Embedded SDK + Separate User Opt-In → Supply Operator
• Authorized Supplier / Partner → Upstream Aggregator
• Unauthorized Compromise / Hidden Proxy Code → Malicious Network

One possible commercial hand-off then looks like:

Supply Operator / Upstream Network → Wholesale / Reseller / Customer-Facing Provider → Raw Proxy-Capable Inventory

The downstream boundary is:

Raw Proxy-Capable Inventory → Pool Management

This is a conceptual supply-chain model; real implementations vary. The branches are possible models, not stages every provider uses.

A provider may use one branch, several sources, direct relationships, or a structure not shown here. The model is not a description of Mango Proxy sourcing.

Supply Model 1: Explicit Participant Application

In an explicit participant-application model, a person installs a dedicated application whose stated purpose includes sharing some network capacity.

When the application is active, the supply operator can route permitted customer traffic through that participant’s connection under the operator’s terms.

The participant, device, connection, and public IP still remain different entities.

The application may run on one device behind a household gateway, while the destination observes the connection’s public egress IP.

Closing the application can remove that device’s participation without changing the existence of the Internet connection itself.

PacketStream’s Packeter program is one documented example of this model. Its official materials describe a desktop client that routes customer traffic through a participant’s Internet connection while the application runs, credits metered bandwidth, and can be stopped or uninstalled.

This documents one explicit participant-app model.

It does not show that every residential proxy provider uses desktop peers, pays participants by bandwidth, or applies the same controls.

Compensation is also an implementation detail, not a universal requirement.

Some participation arrangements may pay money, exchange access for a product benefit, use another incentive, or have no comparable reward.

The presence of compensation does not establish informed consent by itself.

Supply Model 2: Embedded SDK With Separate User Opt-In

An embedded software development kit can let the developer of a host application offer network participation to its users.

In a transparent model, installing the host application and joining the bandwidth-sharing program are separate decisions: the user receives a clear explanation and takes an affirmative action before the SDK activates proxy participation.

Several roles may exist even inside this one branch:

• the host-app developer distributes and maintains the application;
• the SDK provider supplies the participation component;
• the user or authorized device operator chooses whether to participate;
• the supply operator manages the resulting capacity;
• a separate organization may later sell proxy access.

EarnApp’s official SDK description is one documented implementation. It describes an opt-in screen, use of available network resources, and developer compensation.

These are the vendor’s statements about its own implementation.

They do not establish that all SDK-based supply uses the same disclosure, compensation, resource limits, customer screening, or opt-out design.

An SDK model is not automatically transparent merely because an SDK exists.

The relevant sourcing question is whether the person with authority over the device and connection knew what participation meant and affirmatively enabled it.

Supply Model 3: Authorized Suppliers, Aggregators, Resellers, and White-Label Providers

Residential proxy supply does not have to move directly from a participant to the brand that serves the final customer.

A supply operator may sell capacity to an upstream network, aggregator, wholesaler, or reseller.

A customer-facing proxy provider may combine several sources or expose another operator’s network under its own commercial interface.

Role	Possible supply-chain function	Important limitation
Participant	Makes an authorized device or connection available under a specific model	May not know or contract with the final customer-facing provider
Supply operator	Enrolls or manages participating capacity	May sell only upstream rather than to end customers
Upstream aggregator	Combines capacity from one or more authorized sources	Is not necessarily the original participation operator
Wholesaler	Provides network capacity or access to another business	May not own the consumer relationship or customer interface
Reseller / white-label provider	Sells access under its own brand or product layer	May rely on another operator for some or all capacity
Customer-facing provider	Authenticates, bills, supports, or routes final customers	Is not automatically the original source of every exit resource

PacketStream’s Terms of Service provide one documented example. They describe approved resellers that can offer proxy access under their own brand while PacketStream supplies white-label services.

This proves that a separation between upstream network and customer-facing reseller exists in at least one documented implementation.

It does not prove that any other named provider is a reseller.

The core conclusion is narrow but important:

The customer-facing proxy brand and the original supply operator can be different organizations.

Provider ownership, supplier relationships, and white-label status must be established with evidence for that specific provider.

They cannot be inferred from a gateway hostname, an overlapping IP observation, a similar interface, or a generic industry model.

Supply Model 4: Direct ISP or Address-Block Relationships

Some proxy products are built around commercial relationships involving ISP-associated address space rather than software running on household devices.

This is a separate boundary model, often discussed in connection with static ISP proxies.

Bright Data’s official materials provide one vendor-specific example, describing ISP proxy sourcing through agreements and partnerships with ISPs.

That illustrates one ISP-relationship model.

It does not establish an industry-wide sourcing method or describe Mango Proxy.

An ISP-associated address block can be routed through server infrastructure and still be classified differently from a datacenter range.

That does not prove that a subscriber household, end-user device, or participant application sits behind each address.

For the category boundary, see ISP Proxies Explained.

Commercial rights to use address space, hosting arrangements, letters of authorization, and routing announcements are separate operational and legal subjects.

They belong in an IP leasing or address-rights deep dive, not in this residential supply-chain article.

Unauthorized Supply Exists – but It Is a Separate Category

Residential proxy capacity can also be created without valid authorization through malware, hidden proxy components, or compromised devices.

This branch must be kept distinct from opt-in participation and authorized supplier relationships.

In July 2026, Google Threat Intelligence Group documented a specific disrupted malicious residential proxy network that it said used hidden proxy code, pre-installed malware, compromised home devices, and reseller relationships.

In a separate 2024 case, the U.S. Department of Justice alleged that the 911 S5 service sold access to residential computers compromised by malware.

These sources establish that unauthorized residential proxy supply has been officially documented.

They do not establish that residential proxy supply is universally malicious, that legitimate participant models are equivalent to botnets, or that any provider not identified by the evidence uses compromised devices.

The purpose of this distinction is simple: authorization is part of the supply relationship, and a residential-looking exit IP does not reveal whether that relationship was legitimate.

Consent, Transparency, and Supply Integrity

Supply integrity concerns how capacity entered the chain and whether each organization can account for the authority under which it was provided.

It is broader than a payment record or a vendor’s use of the word “ethical.”

Ethical Best Practices

The following are useful questions for evaluating an authorized participant or SDK model.

They are not presented as universal statutory requirements.

Supply-integrity question	Why it matters
Is the purpose clearly disclosed?	A participant should understand that third-party traffic may use the device or Internet connection, not merely that the app earns rewards.
Is participation an affirmative choice?	A separate opt-in distinguishes proxy participation from merely installing or opening an unrelated host application.
Can participation be paused or ended?	A visible pause, disable, opt-out, or uninstall path gives the authorized user continuing control.
Are bandwidth and resource effects explained?	The participant should be able to understand that traffic can consume network capacity and may use device resources.
Does the participant have authority to share the device and connection?	A device user may not be the network owner, account holder, employer, school, landlord, or other party entitled to authorize this use.
Is compensation explained separately from consent?	Payment or a product benefit can motivate participation but does not prove that disclosure was clear or the choice was informed.
Can suppliers and resellers be held accountable?	Each commercial layer should be able to explain its supplier standards, escalation path, and responsibility for unauthorized capacity.
Are security and abuse controls addressed?	Network operators need a meaningful process for acceptable use, customer screening, incident handling, and removal of unauthorized resources.

For SDK-based supply, accountability does not stop at the SDK vendor.

Android’s official SDK safety guidance says app developers should understand an SDK’s permissions and data behavior and that SDK providers should support disclosure and user-preference mechanisms.

This is Android platform guidance, not a universal legal code, but it illustrates why a host app cannot treat an embedded component as invisible to its own users.

Legal Requirements Depend on the Applicable Framework

Ethical best practices and legal requirements are related but not identical.

Applicable law can depend on jurisdiction, the data and traffic involved, the relationship between the parties, the device and network owner, platform rules, contract terms, and the chosen legal basis.

For example, the European Data Protection Board explains that when consent is relied on as a GDPR legal basis, it must be freely given, specific, informed, and unambiguous, and withdrawal must be possible.

That is a defined European data-protection framework.

It should not be converted into a claim that the same legal test governs every proxy-supply relationship worldwide.

This article therefore does not decide whether a particular implementation is lawful.

Providers, developers, suppliers, and participants should evaluate the laws, contracts, ISP terms, device policies, and platform requirements that actually apply to them.

Why Residential Supply Changes Over Time

Residential supply is not a permanent mapping between one person, one device, and one address.

Capacity can change before it ever reaches pool management.

Possible upstream changes include:

• a participant application starts or stops;
• a host device goes online, sleeps, disconnects, or leaves the program;
• a household or subscriber connection changes state;
• an ISP dynamically reassigns an address;
• an upstream supplier changes which authorized resources it exposes;
• a reseller changes suppliers or combines capacity from several networks;
• a participant withdraws authorization;
• a compromised resource is remediated or removed from a malicious network.

These are categories of change, not claims about universal event frequency.

No specific peer lifetime, churn rate, online percentage, freshness period, or replacement cadence can be inferred without a defined provider, sample, geography, and observation window.

The term “supply volatility” is useful here because it refers to upstream capacity changing before or as it reaches a provider.

Operational pool churn – changes to eligibility or availability inside a managed proxy pool – is downstream and belongs to the pool-management lifecycle.

Potential Supply Is Not the Same as What a User Can Observe

Supply-size claims compress several different measurements into one phrase.

A more accurate model is:

Potential Supply

↓

Connected / Online Supply During a Defined Window

↓

Raw Provider Inventory

↓

Eligible Pool

↓

Resources Available to One User

Potential Supply

Potential supply may refer to registered participants, installed applications, supplier relationships, address resources, or another provider-defined universe.

The counted unit must be stated.

A count of potential IP observations is not automatically a count of enrolled devices or authorized participants.

Connected or Online During a Defined Window

Only some potential resources may be connected during a particular measurement window.

The window matters: an instantaneous view, a day, and a monthly deduplicated count answer different questions.

A resource seen at some point during a month is not necessarily connected at every moment in that month.

Raw Provider Inventory

Raw inventory is capacity or resource information that has reached a provider and can be considered for management.

It may arrive from the provider’s own supply operation, an upstream supplier, an aggregator, or a commercial partner.

Raw inventory is the endpoint of this article’s supply chain.

It is not a claim that the resource has passed validation or can serve a customer request.

Eligible Pool and Resources Available to One User

These last two layers belong to pool management.

Eligibility rules, current availability, metadata, targeting, access scope, and allocation policy can all create a narrower operational set.

They are shown only to preserve the measurement boundary – not to retell the downstream lifecycle.

What the Numbers Do Not Mean

Without a provider-specific counting methodology:

• IP count is not device count;
• IP count is not household count;
• IP count is not subscriber count;
• advertised pool size is not concurrently online supply;
• online supply is not necessarily raw inventory at every customer-facing provider;
• raw inventory is not the currently eligible pool;
• IPs observed during a finite test are not the entire supply;
• overlapping observations across brands do not independently prove a reseller relationship;
• a decrease between layers does not by itself indicate poor provider quality.

To compare supply claims, ask what is counted, how uniqueness is defined, which time window is used, whether addresses are concurrent or cumulative, which geography is included, and which commercial or operational layer the number represents.

Where the Residential Supply Chain Ends

The ownership boundary for this article is:

Supply Operator / Upstream Network → Proxy Provider Raw Inventory

At that point, a provider may know about or have commercial access to a proxy-capable resource.

Becoming known to a provider does not make a resource eligible, available, or allocatable.

Validation, eligibility, metadata enrichment, classification, segmentation, allocation, rotation, session policy, continuous monitoring, quarantine, removal, and possible re-entry are separate operational decisions.

They belong to the downstream pool-management article and are intentionally not reproduced here.

Practical Examples

Example 1: One Exit IP Does Not Reveal One Device

Assume a household connection serves a laptop, two phones, a television, and a router-connected device.

One authorized participant application runs on the laptop. NAT translates traffic from the local network to one public IPv4 address.

A destination observes the public exit IP.

From that observation alone, it cannot determine:

• that five devices are present;
• which device carried the participant software;
• who owns the subscriber account;
• whether another subscriber later receives the same dynamic address;
• whether the proxy customer connected through a gateway endpoint or directly to the participating resource.

The valid conclusion is only that traffic was observed from that public address under the test conditions.

Example 2: The App, SDK Operator, and Proxy Brand Are Different Parties

Assume a host application offers a separate, clearly described network-sharing option.

A user with authority over the device and connection affirmatively opts in.

The embedded SDK sends authorized capacity to a supply operator, which sells upstream access to a customer-facing proxy brand.

The chain is:

User Choice → Host App + SDK → Supply Operator → Customer-Facing Provider → Raw Inventory

This example shows why disclosure and supplier accountability must follow the chain.

It does not prove that the customer-facing brand created the SDK, contracted directly with the participant, or owns the underlying resource.

Example 3: A Large Advertised Number Produces a Small Test Sample

Assume a network advertises unique residential IPs observed across a month.

A customer runs a short test in one country and records a limited set of exit IPs.

The two measurements are not equivalent:

• the advertised figure may be cumulative across a longer period and many regions;
• the test samples one configuration during a finite window;
• IP reassignment can affect unique-address counts;
• NAT and CGNAT prevent conversion from IPs to devices or subscribers;
• downstream eligibility and access rules can narrow the customer-visible set.

The test can support a statement about what was observed under that configuration.

It cannot enumerate the complete upstream supply chain or establish the number of households behind it.

Follow the Handoff From Supply to Pool Management

Use the supply model to ask who originated the capacity, who was authorized to share it, which organizations handled it, and what a reported count actually measures.

Then continue with How Proxy Pools Are Built to understand how raw inventory can become an eligible, segmented, monitored, and allocatable pool.

Final Thoughts

Residential proxy supply is not a single pipeline and not a one-to-one map of people, devices, households, and IP addresses.

It begins with network connectivity, but commercial proxy capacity exists only after an authorized – or, in a distinct malicious model, unauthorized – mechanism makes that connectivity available to an operator.

The most useful evaluation questions are therefore not limited to “How many residential IPs are there?”

Ask what the counted unit is, who had authority to provide the capacity, whether the customer-facing brand operates or resells the upstream network, which time window the number covers, and where raw supply ends and pool management begins.

That separation prevents two common errors: assuming every residential IP represents one household device, and treating every resource known to a provider as immediately available to a customer.

Glossary

Internet Number Resource
An IP address or address block administered through Internet number-resource systems and used by networks under applicable allocation or assignment arrangements.

Residential Connection
An Internet access relationship serving a subscriber premises or consumer context. It is not a proxy resource by itself.

Public Egress IP
The public IP address a destination observes for outbound traffic after any relevant address translation or routing.

Subscriber
The customer or account receiving Internet access from an ISP. A subscriber is not necessarily the device owner or proxy participant.

Household Gateway / CPE
Router, modem, or other customer-premises equipment connecting local devices to an ISP network.

NAT / NAPT
Network address translation mechanisms that can let multiple internal hosts share a public address, commonly distinguished by port mappings.

CGNAT
Carrier-grade NAT performed in a service-provider network, allowing public IPv4 resources to be shared across subscriber connections.

Peer / Participant
An implementation-specific role for a device or resource enrolled in a supply operator’s network.

Participation Application
Software whose user-facing purpose includes enabling a device or connection to provide network capacity under a defined program.

Embedded SDK
A software component included inside a host application. In an authorized supply model, proxy participation should be separately and clearly disclosed to the user.

Supply Operator
An organization that obtains, manages, or exposes proxy-capable participation or capacity.

Upstream Aggregator
An organization that combines or supplies capacity from one or more upstream sources to another provider.

Reseller / White-Label Provider
A customer-facing seller that offers another operator’s service or capacity under its own commercial layer or brand.

Proxy Endpoint
The address or interface through which a customer accesses a proxy service. It is not necessarily the residential exit resource.

Raw Proxy-Capable Inventory
Resources or capacity known to or accessible by a provider before downstream eligibility, availability, and allocation decisions.

Supply Integrity
The transparency, authorization, accountability, and security conditions under which capacity enters and moves through the supply chain.

Frequently asked questions

Here we answered the most frequently asked questions.

Ask a question

Where do residential proxy IPs come from?

They originate in public egress contexts associated with ISP access networks. The capacity can reach a proxy provider through several models, including explicit participant applications, embedded SDKs with separate opt-in, authorized suppliers or aggregators, direct ISP or address-block relationships, and – separately – unauthorized compromised-device networks.

Do all residential proxies come from users who install bandwidth-sharing apps?

No. Explicit participant apps are one documented model, not a universal explanation. Other supply paths can include opt-in SDKs, upstream suppliers, reseller arrangements, or ISP-associated address relationships. A specific provider’s sourcing model requires provider-specific evidence.

Is one residential IP the same as one household?

No. One household connection can serve many devices behind NAT, a dynamic IP can be reassigned over time, and CGNAT can let multiple subscriber connections share public IPv4 resources. An IP observation cannot be converted directly into a household count.

Is one residential IP the same as one device or peer?

No. A participant application can run on one device behind a gateway while the destination sees the connection’s public egress IP. Other devices may share that IP without being peers, and one device can appear under different addresses over time.

What is the difference between a supply operator and a proxy provider?

A supply operator obtains or manages proxy-capable participation or capacity. A proxy provider exposes access to customers. One organization can perform both roles, but a customer-facing provider can also buy, aggregate, resell, or white-label capacity from another operator.

Does a residential ASN or ISP label prove that an IP came from a household device?

No. ASN, ISP, and connection-type labels describe network or classification context. They do not reveal whether traffic came from a household device, a gateway, a participant app, a hosted ISP proxy, an upstream supplier, or unauthorized software.

Does paying a participant prove informed consent?

No. Compensation explains an exchange of value. Consent concerns disclosure, authority, understanding, and an affirmative choice. A transparent model should explain participation separately and provide meaningful control to pause or end it.

Are SDK-based residential proxy networks always consensual?

No automatic conclusion follows from the presence of an SDK. Consent depends on how participation is disclosed, whether it is separately enabled, whether the user has authority over the device and connection, and whether withdrawal is practical. Those facts must be checked for the specific implementation.

Are all residential proxy networks malicious botnets?

No. Law enforcement and threat-intelligence sources have documented specific unauthorized networks, but those cases do not characterize every provider or authorized participant model. Unauthorized compromise is a separate supply category, not a synonym for the residential proxy industry.

Does advertised residential pool size mean all IPs are online at once?

Not necessarily. An advertised figure may represent unique IPs observed across a reporting window, potential supply, raw inventory, or another provider-defined scope. Concurrent availability should not be inferred unless the methodology explicitly measures it.

Why might a finite test show fewer IPs than a provider advertises?

A finite test samples one configuration over a limited period. Geography, time window, user access, downstream eligibility, and allocation conditions can narrow what appears. The test does not automatically enumerate all upstream supply or every resource known to the provider.

Where does the supply chain end and proxy pool management begin?

This article ends when a supply operator or upstream network provides raw proxy-capable inventory to a proxy provider. Validation, eligibility, metadata, segmentation, allocation, session policy, monitoring, and removal belong to downstream pool management.