Proxy bandwidth describes how much network capacity is theoretically or operationally available to carry traffic, but it does not tell you how much useful data an application can actually transfer per second. A proxy connection may have access to a high-bandwidth network while still delivering much lower real-world throughput.

This distinction becomes especially important in web scraping, browser automation, API collection, file transfer, and other data-intensive workloads.

Consider two proxy connections:

Proxy A
Available Bandwidth: 100 Mbps
Observed Throughput: 82 Mbps

Proxy B
Available Bandwidth: 100 Mbps
Observed Throughput: 18 Mbps

Both may operate on infrastructure capable of 100 Mbps, yet their applications experience very different transfer rates.

The reason is that:

Bandwidth
    ≠
Throughput
    ≠
Goodput

Bandwidth describes capacity.

Throughput describes how much traffic actually crosses the network during a period of time.

Goodput goes one step further and measures how much useful application data is successfully delivered.

Understanding these three layers provides a much better model for evaluating proxy performance than simply asking, “How many Mbps does this proxy have?”

---

What Is Proxy Bandwidth?

Proxy bandwidth refers to the amount of network traffic a proxy connection or part of the proxy infrastructure can theoretically or operationally carry over time.

It is commonly expressed in:

Mbps
Gbps

For example:

100 Mbps
1 Gbps
10 Gbps

But a bandwidth number needs context.

It could describe:

Client internet connection
Proxy gateway interface
Gateway uplink
Exit node connection
ISP connection
Data center port
Shared network capacity

These are not interchangeable.

A proxy path contains multiple network segments:

Client
   ↓
Client Network
   ↓
Proxy Gateway
   ↓
Proxy Infrastructure
   ↓
Exit Network
   ↓
Destination Network
   ↓
Server

The effective transfer capacity of the complete path is influenced by all of them.

A 1 Gbps gateway cannot force a residential exit connected through a much slower access network to transfer at 1 Gbps.

---

Bandwidth Is Capacity, Not Delivered Performance

A useful analogy is a road.

Bandwidth is similar to the maximum capacity of the road.

Throughput is how many vehicles actually pass through it during a particular period.

A four-lane road may support more traffic than a one-lane road, but actual traffic flow still depends on:

Congestion
Intersections
Accidents
Traffic patterns
Vehicle behavior
Downstream roads

Networks behave similarly.

A high-capacity link provides room for traffic, but does not guarantee that a single TCP connection can consume all of that capacity.

This is why:

100 Mbps available

does not automatically mean:

100 Mbps observed

---

What Is Proxy Throughput?

Throughput measures the amount of traffic successfully transferred during a period of time.

A simplified calculation is:$$Throughput = \frac{Transferred\ Bits}{Transfer\ Time}$$

Suppose a connection transfers 50 MB in 10 seconds.

Ignoring decimal/binary unit differences for illustration:$$50\ MB \times 8 = 400\ Mb$$

Therefore:$$Throughput = \frac{400\ Mb}{10s} = 40\ Mbps$$

Even if the underlying network supports:

100 Mbps

the measured transfer produced only:

40 Mbps

That difference is not necessarily evidence that the advertised capacity is false.

The complete network path may simply prevent the application from reaching the theoretical capacity.

---

Goodput Is Often More Useful Than Throughput

For proxy applications, throughput is still not the final metric.

Imagine that 100 MB crosses the network.

Not all 100 MB necessarily represents the data the application actually wanted.

Traffic can include:

TCP/IP headers
TLS overhead
HTTP headers
Proxy protocol overhead
Retransmitted packets
Control traffic

If the application ultimately receives 85 MB of useful payload, then the useful data rate is lower than the raw network throughput.

This is called goodput.

Conceptually:

Bandwidth
    ↓
Maximum Available Capacity
    ↓
Throughput
    ↓
Actual Traffic Transferred
    ↓
Goodput
    ↓
Useful Application Data

For scraping systems, goodput can be more meaningful than raw throughput because the business objective is usually not to move packets.

It is to collect usable data.

---

1. Proxy Bandwidth Does Not Describe the Entire Network Path

Suppose a proxy gateway has:

10 Gbps Uplink

A user might conclude:

My proxy connection can reach 10 Gbps.

That conclusion ignores the rest of the path.

Imagine:

Client
  │
  │ 500 Mbps
  ↓
Gateway
  │
  │ 10 Gbps
  ↓
Exit Network
  │
  │ 80 Mbps
  ↓
Destination

The gateway’s 10 Gbps capacity does not remove the 80 Mbps limitation farther downstream.

A simplified model is:$$Path\ Capacity \leq Minimum\ Capacity\ Along\ The\ Path$$

If the relevant links support:

500 Mbps
10 Gbps
80 Mbps
1 Gbps

then a single flow cannot simply assume the 10 Gbps link determines performance.

This is why proxy bandwidth claims must always be interpreted in terms of where that capacity exists.

---

2. Latency and Bandwidth Measure Different Properties

Latency measures how long data takes to travel.

Bandwidth describes how much data a network can carry over time.

They are related to performance, but they are not the same thing.

Consider:

Proxy	RTT	Available Capacity	Observed Throughput
A	30 ms	100 Mbps	25 Mbps
B	90 ms	500 Mbps	120 Mbps
C	50 ms	1 Gbps	70 Mbps

Proxy A has the lowest latency but not the highest throughput.

Proxy C has the highest theoretical capacity but still does not achieve the highest measured throughput.

Therefore:

Low Latency
    ≠
High Throughput

and:

High Bandwidth
    ≠
Low Latency

A proxy can be responsive for small requests while performing poorly for large transfers.

Another can have a slower initial response while delivering large amounts of data efficiently once the transfer is established.

---

3. Bandwidth-Delay Product Explains Why Latency Still Matters

Bandwidth and latency interact through an important networking concept called the Bandwidth-Delay Product, or BDP.

A simplified formula is:$$BDP = Bandwidth \times RTT$$

Suppose a network path supports:

100 Mbps

with:

100 ms RTT

Then:$$100,000,000\ bits/s \times 0.1s = 10,000,000\ bits$$

which is approximately:

1.25 MB

This means roughly 1.25 MB of data would need to be in flight to fully utilize that 100 Mbps path under this simplified model.

Now imagine the sender can keep only a much smaller amount of data in flight.

The connection may fail to use the available bandwidth efficiently.

This is why a high-bandwidth, high-latency path requires sufficient TCP windowing and congestion-control behavior to reach its potential throughput.

---

TCP Window Size Can Limit Effective Throughput

TCP cannot simply send unlimited data and hope it arrives.

The receiver advertises how much data it can accept, while TCP congestion control also regulates how much data can be in flight.

A simplified relationship is:$$Throughput \lesssim \frac{Window}{RTT}$$

Suppose:

Effective Window = 256 KB
RTT = 100 ms

Then the amount of data that can be kept in flight may limit the transfer rate even when the underlying network has much more available capacity.

Modern TCP implementations use mechanisms such as window scaling and dynamic congestion control, so real behavior is more sophisticated than this simple equation.

But the principle remains important:

A fast network interface does not guarantee that one TCP flow can fully utilize it.

---

4. TCP Slow Start Can Prevent Short Transfers From Reaching Full Bandwidth

TCP does not normally begin a new connection by immediately sending data at the maximum possible rate.

Congestion control gradually determines how much data can safely be placed into the network.

A simplified connection might behave like:

Connection starts
      ↓
Small congestion window
      ↓
Acknowledgments arrive
      ↓
Window grows
      ↓
More data in flight
      ↓
Higher throughput

For a large file transfer, the connection may have enough time to reach a high transfer rate.

But many proxy workloads consist of short responses:

HTML page
JSON API
Search result
Product page
Small image

The transfer may finish before TCP ever approaches the available network capacity.

This creates an important distinction:

Maximum Link Bandwidth
        ≠
Bandwidth Used by a Short Request

For web scraping, this is especially relevant because many workloads consist of thousands or millions of relatively small transfers rather than one enormous file.

---

5. Packet Loss Can Reduce Throughput Without Reducing Nominal Bandwidth

Suppose a path has:

Available Capacity:
500 Mbps

but packets are occasionally lost.

TCP detects missing data and retransmits it.

Conceptually:

Send Data
   ↓
Packet Lost
   ↓
Loss Detected
   ↓
Retransmission
   ↓
Congestion Control Reacts
   ↓
Transfer Continues

The physical or configured bandwidth may still be 500 Mbps.

But useful application throughput can fall substantially.

This is because packet loss can produce both:

Retransmission overhead

and:

Reduced sending rate

depending on the congestion-control algorithm and loss pattern.

Therefore:

High Bandwidth + Packet Loss

can perform worse than:

Lower Bandwidth + Stable Path

for some workloads.

---

Retransmitted Bytes Are Not Goodput

Suppose the network sends:

110 MB total

to successfully deliver:

100 MB application payload

because some packets needed retransmission.

The network carried 110 MB.

But the application gained only 100 MB of useful new data.

Conceptually:

110 MB Network Traffic
        ↓
10 MB Duplicate / Retransmitted
        ↓
100 MB Useful Data

This illustrates why throughput and goodput should be measured separately.

For proxy workloads where traffic is billed by transferred bytes, unnecessary retransmission can also have operational significance depending on where and how traffic accounting is performed.

---

6. Shared Proxy Bandwidth Is Different From Dedicated Bandwidth

Another source of confusion is shared infrastructure.

Suppose a proxy gateway has:

10 Gbps capacity

but serves many concurrent connections.

That does not mean:

Every connection = 10 Gbps

Instead:

                    ┌→ User A
                    ├→ User B
10 Gbps Gateway ────┼→ User C
                    ├→ User D
                    └→ ...

Capacity is shared across workloads.

Actual throughput per connection can depend on:

Concurrent traffic
Traffic shaping
Gateway load
Exit capacity
Upstream congestion
Destination capacity

This distinction becomes even more important for residential proxy networks because the exit side can also operate on consumer access networks with variable capacity.

---

Residential Exit Bandwidth Can Change Over Time

A residential proxy endpoint exists on a real access network.

Its available capacity can vary because the underlying connection may simultaneously serve other traffic.

Conceptually:

Residential Connection
       │
       ├→ Proxy Traffic
       ├→ Video Streaming
       ├→ Downloads
       ├→ Mobile Devices
       └→ Other Household Traffic

Even if the nominal access connection remains unchanged, the bandwidth available to a particular proxy flow can vary.

For example:

10:00
Available to Proxy Flow → 80 Mbps

20:00
Available to Proxy Flow → 25 Mbps

The exact behavior depends on the underlying network.

This is one reason residential proxy throughput should be measured over time rather than inferred from a single speed test.

---

7. Destination Servers Can Limit Proxy Throughput

Sometimes the bottleneck is not the proxy at all.

Consider:

Client
   ↓
500 Mbps
   ↓
Proxy
   ↓
500 Mbps
   ↓
Destination

but the destination delivers data to the connection at:

20 Mbps

Then observed throughput cannot exceed what the destination provides for that transfer.

A destination can limit effective delivery because of:

Server load
Application processing
Per-connection behavior
CDN selection
Rate controls
Storage performance
Network congestion

This means testing a proxy against one website does not necessarily reveal the maximum throughput of the proxy infrastructure.

You may instead be measuring:

Proxy
+
Internet Path
+
Destination

as one combined system.

---

CDN Selection Can Change the Result

Modern websites often serve content through Content Delivery Networks.

The selected CDN edge can depend on network topology, DNS behavior, geography, and other routing mechanisms.

Two proxy exits can therefore receive content from different infrastructure:

Proxy A
   ↓
CDN Edge A

Proxy B
   ↓
CDN Edge B

Even if the proxies themselves have similar network capacity, the resulting throughput can differ because the downstream paths are different.

This is why proxy throughput should ideally be tested against multiple controlled destinations rather than one arbitrary website.

---

HTTP Response Time Is Not the Same as Throughput

Consider a request that returns:

HTTP 200

in:

150 ms

That number alone does not tell you the connection throughput.

For a small 5 KB JSON response, 150 ms might mostly represent:

Connection setup
TLS
Server processing
RTT

The payload is too small to meaningfully test sustained transfer performance.

For a 500 MB transfer, throughput becomes much more visible.

Therefore:

Small Request Latency Test

and:

Large Transfer Throughput Test

measure different properties.

This is why using a simple IP-check endpoint as a “proxy speed test” provides only limited information.

---

Time to First Byte and Throughput Should Be Separated

Another useful distinction is Time to First Byte (TTFB).

Consider:

Request Sent
    ↓
Wait
    ↓
First Byte
    ↓
Data Transfer
    ↓
Last Byte

TTFB measures the delay before response data begins arriving.

Throughput measures how quickly data transfers over time.

A connection can have:

Low TTFB
Low Throughput

or:

High TTFB
High Throughput

For example:

Connection A

TTFB: 100 ms
Download: 5 Mbps

Connection B

TTFB: 400 ms
Download: 100 Mbps

Which is better depends on the workload.

For thousands of tiny API requests, Connection A may feel faster.

For large downloads, Connection B may finish much sooner.

---

Browser Workloads Rarely Use Bandwidth Like a Single Download

Browser automation makes bandwidth analysis even more complicated.

A webpage may load:

HTML
CSS
JavaScript
Images
Fonts
API responses
Video
Analytics
Third-party resources

The browser does not necessarily download them as one continuous stream.

Instead:

Navigation
    ↓
HTML
    ↓
Resource Discovery
    ↓
Multiple Requests
    ↓
Parallel / Multiplexed Transfers
    ↓
JavaScript Execution
    ↓
Additional API Requests

A browser can therefore spend significant time:

Waiting
Parsing
Executing JavaScript
Rendering
Discovering resources

while the network connection is not using its full available bandwidth.

As a result:

1 Gbps Network

does not imply:

Webpage loads 10× faster than on 100 Mbps

once network capacity is no longer the dominant bottleneck.

---

HTTP/2 Can Improve Connection Utilization Without Increasing Bandwidth

HTTP/2 can multiplex multiple streams over a connection.

Instead of:

Connection 1 → Resource A
Connection 2 → Resource B
Connection 3 → Resource C

the architecture can look like:

One Connection
    ├→ Stream A
    ├→ Stream B
    └→ Stream C

This can reduce some connection-management overhead and improve how network capacity is used.

But it does not magically increase physical bandwidth.

If the bottleneck is:

50 Mbps

HTTP/2 does not transform it into:

500 Mbps

Protocol efficiency and network capacity are separate concepts.

---

Compression Can Make Application Throughput Look Higher Than Network Throughput

Suppose a server has:

100 MB uncompressed JSON

and compression reduces it to:

20 MB transferred

The network only needs to transport 20 MB.

The application then decompresses it back into a much larger representation.

From the network perspective:

20 MB transferred

From the application-data perspective:

100 MB processed

This means “MB/s” can become ambiguous unless you define what is being measured.

Are you measuring:

Wire bytes?
Compressed payload?
Decompressed payload?
Stored dataset size?

Professional proxy benchmarking should specify the measurement layer.

---

Protocol Overhead Reduces Useful Payload Efficiency

Application data is wrapped by multiple protocol layers.

Conceptually:

Application Data
      ↓
HTTP
      ↓
TLS
      ↓
TCP
      ↓
IP
      ↓
Link Layer

Each layer introduces some overhead.

For large transfers, this overhead may represent a relatively small percentage of total traffic.

For many tiny requests, however, the relative overhead can become much more noticeable.

For example, repeatedly transferring tiny payloads may involve:

Request headers
Response headers
TCP acknowledgments
TLS records
Connection setup

that are large relative to the useful data.

This leads to a useful metric.$$Payload\ Efficiency = \frac{Useful\ Application\ Bytes}{Total\ Transferred\ Bytes}$$

Higher payload efficiency means more of the network traffic contributes directly to the application’s objective.

---

Scraping Throughput Should Not Be Measured Only in Mbps

For web scraping, Mbps is often not the most meaningful performance metric.

Suppose:

Proxy A:
100 Mbps

and:

Proxy B:
50 Mbps

But the scraper produces:

Proxy A:
120 valid product pages / second

Proxy B:
180 valid product pages / second

Which is actually faster for the workload?

Proxy B.

This suggests a more useful metric:$$Useful\ Data\ Throughput = \frac{Valid\ Records}{Time}$$

For example:

Valid pages / second
Products / minute
Successful API responses / second
Valid MB / second

The correct unit depends on the task.

This moves performance measurement from the network layer to the business-result layer.

---

Bandwidth Consumption and Data Collection Efficiency Are Different

Imagine two scraping systems.

System A

Transferred:
500 GB

Valid Records:
5 million

System B

Transferred:
300 GB

Valid Records:
5 million

Both produce the same dataset.

System B requires less transferred traffic per valid record.

A useful metric is:$$Bytes\ per\ Valid\ Record = \frac{Total\ Transferred\ Bytes}{Valid\ Records}$$

For System A:

500 GB / 5,000,000

For System B:

300 GB / 5,000,000

The second architecture is more traffic-efficient even if its peak Mbps is lower.

For traffic-based proxy plans, this distinction can directly affect infrastructure cost.

---

Browser Resource Blocking Can Reduce Bandwidth Without Reducing Useful Data

Consider a browser automation task whose only goal is to extract:

Product Name
Price
Availability
SKU

The page may also load:

Large images
Video
Fonts
Analytics
Advertising resources

If those resources are unnecessary for the permitted workflow and the page continues to function correctly without them, reducing unnecessary transfers can improve efficiency.

The goal becomes:

Useful Page Data
-----------------
Transferred Bytes

rather than maximizing raw network utilization.

A scraper using 30 Mbps efficiently can therefore outperform one consuming 100 Mbps while downloading unnecessary resources.

---

Proxy Bandwidth Should Be Measured in Both Directions

Network traffic has two directions:

Upload
Download

Many scraping workloads are download-heavy:

Small HTTP Request
       ↓
Large HTTP Response

But other workflows can send larger request bodies.

For example:

API uploads
Form submissions
File transfers

A network path can have asymmetric capacity:

Download: 500 Mbps
Upload:    50 Mbps

Therefore, one generic “bandwidth” number may hide important differences.

A professional benchmark should specify:

Upstream throughput
Downstream throughput

where both matter.

---

Aggregate Throughput and Per-Connection Throughput Are Different

Suppose one proxy gateway supports:

1 Gbps aggregate traffic

That does not mean one TCP connection can necessarily reach 1 Gbps.

Imagine:

Connection A → 50 Mbps
Connection B → 60 Mbps
Connection C → 45 Mbps
...

Together:

Many Connections
      ↓
800 Mbps Aggregate

while:

Single Connection
      ↓
60 Mbps

This distinction matters for workload design.

A system performing thousands of independent requests may care more about:

Aggregate Throughput

while a large file transfer may care more about:

Single-Flow Throughput

Those should be benchmarked separately.

---

Concurrency Can Increase Throughput—Until It Does Not

Suppose a proxy workload produces:

Concurrency	Aggregate Throughput
10	20 Mbps
50	75 Mbps
100	130 Mbps
250	190 Mbps
500	195 Mbps
1,000	170 Mbps

Initially, increasing concurrency improves utilization.

Eventually, throughput plateaus.

At still higher concurrency, it can decline.

Possible bottlenecks include:

Gateway capacity
Exit bandwidth
CPU
Sockets
NAT
Packet loss
Queueing
Destination limits

This produces a saturation curve rather than unlimited linear scaling.

A useful benchmark therefore searches for:

Optimal Operating Range

not:

Maximum Possible Concurrency

---

Queueing Can Increase Latency Before Bandwidth Is Fully Understood

When demand approaches a bottleneck’s service capacity, packets or requests can begin waiting in queues.

Conceptually:

Incoming Traffic
       ↓
      Queue
       ↓
Limited-Capacity Link

Longer queues can increase latency.

This means a proxy benchmark might observe:

Throughput → still increasing slightly
Latency → increasing dramatically

before outright failures begin.

Therefore, saturation should be evaluated with both:

Throughput
Latency

rather than throughput alone.

---

Why One Speed Test Is Not Enough

A single bandwidth test captures only one moment.

Proxy network conditions can vary by:

Time
Exit
ISP
Country
Destination
Route
Concurrency
Payload size
Protocol

A more useful test matrix might include:

Dimension	Example Values
Transfer size	100 KB / 10 MB / 100 MB
Concurrency	1 / 10 / 100
Destination	A / B / C
Region	US / JP / DE
Proxy type	Residential / ISP
Time	Multiple intervals

The objective is not simply to produce the largest Mbps number.

It is to understand where performance changes and why.

---

A Better Proxy Bandwidth Benchmark

A professional benchmark should separate at least four layers.

Layer 1: Connection Performance

Measure:

DNS time
TCP connection time
Proxy negotiation time
TLS handshake time

Layer 2: Transfer Performance

Measure:

TTFB
Transfer duration
Bytes transferred
Average throughput

Layer 3: Network Quality

Measure where practical:

RTT
Packet loss
Retransmissions
Connection resets

Layer 4: Application Goodput

Measure:

Valid pages / second
Valid records / second
Useful bytes / second
Bytes per valid record

This prevents one metric from being mistaken for the entire performance picture.

---

Record Transfer Size When Measuring Throughput

Throughput without transfer size can be misleading.

For example:

Test A
Payload: 5 KB
Observed rate: 2 Mbps

Test B
Payload: 100 MB
Observed rate: 90 Mbps

That does not necessarily mean the network became 45 times faster.

The small transfer spends proportionally more time in setup and ramp-up phases.

A benchmark record should therefore include:

{
  "proxy_type": "residential",
  "exit_country": "JP",
  "payload_bytes": 104857600,
  "ttfb_ms": 180,
  "transfer_ms": 10400,
  "throughput_mbps": 80.66,
  "valid_response": true
}

This makes results comparable.

---

Use Percentiles Instead of Only Average Throughput

Suppose five tests produce:

95 Mbps
92 Mbps
90 Mbps
88 Mbps
15 Mbps

An average hides the slow tail.

At scale, users experience the distribution.

Useful statistics include:

Median
P75
P90
P95
P99

depending on sample size and purpose.

You can also track:

Throughput variance
Slow-transfer rate
Timeout rate

A proxy network with slightly lower median throughput but much more stable performance may behave very differently from one with high peaks and severe tail degradation.

---

Do Not Mix Bandwidth and Traffic Quota

Another common terminology problem is using “bandwidth” to describe how much traffic a user is allowed to consume.

These are different concepts.

For example:

100 GB Traffic

describes a quantity of transferred data.

100 Mbps Bandwidth

describes a rate.

The difference is similar to:

GB
→ How much data

versus:

Mbps
→ How fast data can move

A proxy plan can theoretically have:

10 GB Traffic Allowance

while supporting a high transfer rate.

Or it could provide a large traffic allowance while individual connections experience lower throughput.

Always distinguish data volume from data transfer rate.

---

Where ColaProxy Fits Into Bandwidth and Throughput

For proxy infrastructure such as ColaProxy, application performance depends on the complete network path rather than one isolated bandwidth number.

A simplified path is:

Application
     ↓
Client Network
     ↓
ColaProxy Gateway
     ↓
Proxy Routing
     ↓
Exit Network
     ↓
Internet Path
     ↓
Destination

For permitted automation and data collection, developers should benchmark the workload that actually matters to their application.

For example, a scraper can measure:

Valid responses / second

alongside:

Transferred Mbps

while a large-data workflow may care more about:

Sustained transfer throughput

and a browser automation workload may care about:

Navigation completion time
Useful data collected
Transferred bytes per task

This approach avoids treating proxy bandwidth as a universal performance score.

The relevant question is not simply:

How much bandwidth is available?

It is:

How efficiently can the complete proxy path deliver the data required by this workload?

---

7 Differences Between Proxy Bandwidth and Throughput

The distinction can be summarized in seven points.

1. Bandwidth describes capacity; throughput describes actual transfer.

A high-capacity network can still produce low observed throughput.

2. Throughput depends on the complete path.

Client networks, gateways, exits, transit networks, and destinations can all become bottlenecks.

3. Latency interacts with throughput but does not define bandwidth.

High-bandwidth paths can still have high RTT.

4. TCP behavior affects how much capacity a connection can use.

Congestion control, windowing, slow start, and packet loss all influence transfer rates.

5. Shared capacity does not equal per-connection capacity.

A multi-gigabit gateway may serve many simultaneous flows.

6. Throughput is not the same as useful application data.

Protocol overhead and retransmissions mean goodput can be lower than raw throughput.

7. The best proxy metric depends on the workload.

Scrapers may care about valid records per second, browsers about task completion time, and file-transfer applications about sustained Mbps.

---

Conclusion

Proxy bandwidth is an important infrastructure characteristic, but it should not be treated as a direct measurement of real-world proxy performance.

A more accurate model is:

Network Capacity
      ↓
Bandwidth
      ↓
TCP / Protocol Behavior
      ↓
Actual Transfer
      ↓
Throughput
      ↓
Useful Application Data
      ↓
Goodput

Between bandwidth and useful data are many variables:

Latency
Packet loss
TCP windows
Congestion control
Slow start
Shared capacity
Exit network conditions
Destination performance
Protocol overhead
Compression
Concurrency

This is why two proxy connections with identical nominal bandwidth can produce dramatically different application results.

For high-volume proxy workloads, the most useful question is therefore not:

“How many Mbps does this proxy support?”

A better question is:

“How much useful data can this proxy path deliver reliably for my actual workload?”

That shift—from bandwidth to throughput and finally to goodput—produces a much more realistic way to evaluate proxy infrastructure.

---

Frequently Asked Questions

What is proxy bandwidth?

Proxy bandwidth describes network transfer capacity associated with a proxy connection or infrastructure component. It is typically expressed in Mbps or Gbps.

What is proxy throughput?

Proxy throughput is the amount of traffic actually transferred through the proxy path over a period of time.

Why is proxy throughput lower than bandwidth?

Throughput can be limited by latency, packet loss, TCP behavior, network congestion, shared infrastructure, the exit connection, the destination server, and other parts of the end-to-end path.

What is the difference between throughput and goodput?

Throughput measures transferred traffic. Goodput measures useful application data successfully delivered, excluding traffic that does not contribute new useful payload, such as retransmissions and protocol overhead.

Does lower proxy latency mean higher throughput?

Not necessarily. Latency and throughput measure different properties. A low-latency connection can have limited capacity, while a higher-latency connection can still achieve high sustained throughput.

Can packet loss reduce proxy throughput?

Yes. Packet loss can trigger retransmissions and congestion-control responses, reducing effective transfer rates even when nominal network bandwidth remains unchanged.

Does increasing proxy concurrency increase throughput?

Initially it can, especially when one connection does not fully utilize available capacity. But throughput eventually reaches a bottleneck, and excessive concurrency can increase queueing, resource usage, loss, and failures.

Is proxy bandwidth the same as proxy traffic?

No. Bandwidth is a rate, typically measured in Mbps or Gbps. Traffic is a quantity of transferred data, typically measured in MB, GB, or TB.