How much does it cost to run 100 rotating proxies per month?

The cost to run 100 rotating proxies per month depends on connections and traffic. Calculate your budget from billing units, retries and accepted results.

The cost to run 100 rotating proxies per month depends on whether you mean 100 concurrent connections, 100 assigned addresses, or a traffic allowance on a rotating gateway. On Node4, the connection-based reading maps to Rotating Unmetered, priced from $29.00/month for 250 connections ($0.116 per connection) (the smallest sold rung starts at 250 connections, not 100); the traffic-based reading maps to Rotating Datacenter, billed per gigabyte from $5.90/month for 10 GB ($0.59/GB). Match the billing unit to your measured workload rather than multiplying either rate by 100. The subscription also excludes your scraping compute, storage and the extra traffic generated by retries.

TL;DR

• Rotating proxies price by concurrent connections (Rotating Unmetered) or by the gigabyte (Rotating Datacenter); the two ladders are below.
• Python can calculate projected traffic from measured request sizes without assuming a provider's rates.
• A connection allowance does not promise that many distinct exit IPs.
• Compare proxy spending against accepted records, not attempted requests.

These are Node4's own prices, not a market average; larger rungs are on the linked pricing pages.

Define what "100" means before pricing it

There is no universal monthly total for 100 rotating proxies. A connection-based subscription and a traffic-based subscription measure different things. Neither becomes comparable until you define the workload each must support.

Start with the rotating proxies for web scraping guide if your application still treats a gateway address, an exit IP and a connection as interchangeable. That distinction determines what you need to buy.

Build the budget in this order:

1. Define what 100 means. Record whether the requirement concerns simultaneous connections, application workers or independently assigned addresses.
2. Measure actual traffic. Include failed attempts and retries, not just successful response bodies.
3. Match the billing unit. Use the current connection allowance or traffic allowance from the applicable plan.
4. Add application expenses. Keep compute, storage and data processing separate from the proxy subscription.
5. Compare accepted output. Divide the resulting operating expense by records that pass your validation rules.

A quote is useful only when it identifies the product, billing interval, included allowance and applicable limits. Keep those conditions beside the amount in your budget sheet. Otherwise, the total loses its meaning when someone changes the workload.

Write the requirement as a workload statement

A request to buy "100 proxies" leaves the purchasing decision underspecified. Your developer might mean 100 simultaneous network connections, while your data team means enough rotating exits to finish a collection job.

Those requirements are not equivalent. Increasing a connection allowance does not establish how many distinct addresses a target website will see, how long sessions persist, or how many accepted records your pipeline produces.

Write the requirement as a workload statement instead: target domains, permitted collection scope, operating schedule, maximum concurrency, session behavior and required output. Then ask providers to quote against that statement. You get an auditable comparison instead of a list of unrelated headline rates.

Connection-based billing: budget for simultaneous use

A connection-based plan sells an allowance for connections open at the same time. It does not sell that same number of unique addresses.

Best for: workloads where you need to control simultaneous network use and the plan's other limits match your collection pattern. The benefit is a capacity unit you can connect to client-side connection limits. The limitation is that concurrency alone does not establish throughput or accepted output.

Check how the provider counts a connection. An application worker is not automatically a connection: browser automation can open multiple connections, while connection reuse lets sequential requests share an established connection.

For a requirement of 100 concurrent connections, confirm that the allowance applies to the whole account or to a particular endpoint. Also confirm what happens when your application exceeds it. Treat that behavior as an operational requirement, not a footnote.

Do not multiply a connection-based quote by the number of exit addresses observed in your logs. Address rotation and connection capacity describe different properties of the service.

Traffic-based billing: budget for bytes transferred

A traffic-based plan charges against transferred data under the provider's billing rules. The number of configured workers is not the billing quantity.

Best for: workloads with measured transfer volume and a clear definition of billable traffic. The advantage is a direct relationship between usage and the traffic allowance. The limitation is that retries, large responses and browser assets can consume traffic without producing usable records.

The comparison below separates the billing dimensions. It does not assume either model includes a particular performance or session commitment.

Use the same collection workload in both columns. A lightweight HTTP response and a browser-rendered page are not equivalent units of work, even when both produce a single record.

Check whether the traffic counter includes uploads, downloads, unsuccessful responses and protocol overhead. Your local response-body measurement is useful for planning, but it is not automatically identical to the provider's billable counter.

Calculate traffic from measurements, not worker count

The useful arithmetic starts with accepted records, attempts and bytes. Keep those measurements separate so you can see whether consumption comes from workload growth, larger responses or deteriorating success.

Use these relationships:

• Projected attempts = required accepted records × measured attempts per accepted record.
• Projected transfer = projected attempts × measured bytes per attempt.
• Projected billable units = projected transfer ÷ the provider's bytes-per-unit definition.

The following Python calculator uses your inputs rather than inserting assumed traffic or rates. Run it with measurements from a representative collection job. It projects transfer only, not a subscription charge.

from decimal import Decimal


def positive_decimal(prompt):
    value = Decimal(input(prompt).strip())
    if not value.is_finite() or value <= 0:
        raise ValueError("Enter a finite positive number")
    return value


accepted = positive_decimal("Required accepted records per month: ")
attempts_per_record = positive_decimal(
    "Measured attempts per accepted record: "
)
bytes_per_attempt = positive_decimal(
    "Measured transferred bytes per attempt: "
)
bytes_per_unit = positive_decimal(
    "Provider-defined bytes per billing unit: "
)

attempts = accepted * attempts_per_record
transfer_bytes = attempts * bytes_per_attempt
billing_units = transfer_bytes / bytes_per_unit

print(f"Projected attempts: {attempts}")
print(f"Projected transferred bytes: {transfer_bytes}")
print(f"Projected traffic units: {billing_units}")

Measure attempts and transferred bytes over the same observation window. If you count retries in the attempts figure but exclude their traffic from the byte measurement, the projection understates consumption.

Use your provider's usage counter to reconcile the estimate. Investigate differences before scaling the job. Do not silently substitute downloaded HTML size for total transferred data.

This arithmetic also assumes your measured workload represents the planned workload. Recalculate when you change targets, rendering behavior, response formats or validation rules.

Why the monthly operating cost varies

The connection count is only part of the specification. These factors change the resources required to deliver the same accepted dataset:

• Transferred data: Larger responses and downloaded assets increase traffic. Measure the actual collection path, including browser resources where applicable.
• Retries: Repeating unsuccessful requests adds attempts and traffic without necessarily adding records. Record the reason for each retry.
• Active schedule: A job that runs continuously uses resources differently from a job that runs only during scheduled collection windows.
• Session requirements: Login flows and multi-step navigation need consistent session handling. Rotating an address at the wrong point can invalidate the workflow.
• Exit geography: Required countries constrain which products meet the specification. Verify that the quoted product covers the locations you need.
• Processing requirements: Rendering, parsing, validation and storage create application expenses separate from proxy usage.

Change one variable at a time during evaluation. If you change concurrency, request handling and proxy configuration together, the resulting usage figure will not tell you which change affected consumption.

Match the product to the workload before comparing quotes

Node4's rotating datacenter proxies fit developers who need owned datacenter exits in the United States, Italy and Spain. Rotating Unmetered is sold by concurrent connections, not gigabytes or a promised count of unique IPs. Node4's rotating gateway holds a sticky session's exit for up to 30 minutes from first assignment, not from the latest request.

That is a specific fit, not universal geographic coverage. A workload requiring datacenter exits outside those three countries needs a different product specification.

The session limit also belongs in your application design. Repeated activity does not restart the assignment clock. Read the guide to how long a rotating proxy keeps the same IP address before treating a session identifier as an indefinite address reservation.

Document the required locations and session duration before requesting capacity. Those requirements can disqualify a plan regardless of its billing model.

Does 100 rotating proxies mean 100 different IP addresses?

100 concurrent connections do not guarantee 100 different exit IP addresses. Connections describe simultaneous network use; exit addresses describe the source IPs visible to the destination.

If distinct addresses are a requirement, state that separately. Specify whether uniqueness must hold simultaneously, across a collection window or between successive requests. Otherwise, your purchasing requirement remains ambiguous.

Can I run 100 workers on a 100-connection plan?

100 workers do not necessarily fit within 100 concurrent connections. A worker can create multiple connections, and a worker waiting on local processing might have no active proxy connection.

Enforce connection limits in the HTTP client or browser execution layer. A task semaphore limits tasks, but it does not automatically prove that every task opens only a single connection.

Will reducing 100 connections lower monthly usage?

Reducing a 100-connection limit does not necessarily reduce total transferred data. If the job still performs the same attempts and downloads the same responses, it can finish later without transferring less.

Reduce unnecessary requests, unwanted assets and avoidable retries when your objective is lower traffic. Reduce concurrency when your objective is controlling simultaneous load. Keep those changes distinct in your measurements.

FAQ

What's the cost to run 100 rotating proxies per month?

There is no fixed monthly total attached to 100 rotating proxies. Define whether 100 means connections or addresses, then apply the current plan terms to measured usage and add application expenses.

Do 100 rotating proxies give me 100 unique IPs?

A 100-connection allowance does not guarantee 100 unique IPs. Ask separately about exit assignment and any contractual uniqueness requirement.

Is connection-based billing better than traffic-based billing?

Neither billing model is automatically better. Connection-based billing measures simultaneous use, while traffic-based billing measures transferred data under the applicable billing rules.

Do failed requests use proxy bandwidth?

Failed requests can transfer data, including error responses. Whether that traffic counts toward your allowance depends on the provider's billing rules.

Does a Node4 rotating sticky session last longer if I keep sending requests?

No. Node4's rotating gateway measures the 30-minute ceiling from first assignment, not from subsequent activity. Mint a new session id if a route keeps failing partway through a longer job.

What should I measure before buying rotating proxies?

Measure accepted records, total attempts, transferred bytes and active connections over the same observation window. Also document required countries and session behavior.

Does the proxy subscription include my scraping infrastructure?

Treat scraping infrastructure as a separate budget category unless your agreement explicitly includes it. Track compute, storage, rendering and data processing independently.

Track cost against accepted records, not attempts

Put accepted records in the denominator of your budget. Attempted requests measure activity, not useful output. A pipeline can send more requests while producing fewer valid records.

Define acceptance before comparing plans: the response must contain the required fields, pass validation and satisfy your freshness rules. Then track operating expense against that accepted dataset. This makes retries and parsing failures visible instead of hiding them behind a successful HTTP response.

Related guides

• How much bandwidth you need for web scraping proxies
• High-concurrency async scraping with aiohttp
• Automatically rotate proxy IPs after a blocked request