{"id":2005,"date":"2026-09-25T04:27:00","date_gmt":"2026-09-24T20:27:00","guid":{"rendered":"\/blog\/?p=2005"},"modified":"2026-09-24T16:34:48","modified_gmt":"2026-09-24T08:34:48","slug":"proxy-bandwidth","status":"publish","type":"post","link":"\/blog\/proxy-bandwidth","title":{"rendered":"Why Proxy Bandwidth Is Not the Same as Throughput"},"content":{"rendered":"\n

Proxy bandwidth<\/strong> 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.<\/p>\n\n\n\n

This distinction becomes especially important in web scraping, browser automation, API collection, file transfer, and other data-intensive workloads.<\/p>\n\n\n\n

Consider two proxy connections:<\/p>\n\n\n\n

Proxy A\nAvailable Bandwidth: 100 Mbps\nObserved Throughput: 82 Mbps\n\nProxy B\nAvailable Bandwidth: 100 Mbps\nObserved Throughput: 18 Mbps<\/code><\/pre>\n\n\n\n
Both may operate on infrastructure capable of 100 Mbps, yet their applications experience very different transfer rates.<\/p>\n\n\n\n
The reason is that:<\/p>\n\n\n\n
Bandwidth\n    \u2260\nThroughput\n    \u2260\nGoodput<\/code><\/pre>\n\n\n\n
Bandwidth describes capacity.<\/p>\n\n\n\n
Throughput describes how much traffic actually crosses the network during a period of time.<\/p>\n\n\n\n
Goodput goes one step further and measures how much useful application data<\/strong> is successfully delivered.<\/p>\n\n\n\n
Understanding these three layers provides a much better model for evaluating proxy performance than simply asking, “How many Mbps does this proxy have?”<\/p>\n\n\n\n
\n\n\n\n
What Is Proxy Bandwidth<\/a>?<\/h2>\n\n\n\n
Proxy bandwidth<\/strong> refers to the amount of network traffic a proxy connection or part of the proxy infrastructure can theoretically or operationally carry over time.<\/p>\n\n\n\n
It is commonly expressed in:<\/p>\n\n\n\n
Mbps\nGbps<\/code><\/pre>\n\n\n\n
For example:<\/p>\n\n\n\n
100 Mbps\n1 Gbps\n10 Gbps<\/code><\/pre>\n\n\n\n
But a bandwidth number needs context.<\/p>\n\n\n\n
It could describe:<\/p>\n\n\n\n
Client internet connection\nProxy gateway interface\nGateway uplink\nExit node connection\nISP connection\nData center port\nShared network capacity<\/code><\/pre>\n\n\n\n
These are not interchangeable.<\/p>\n\n\n\n
A proxy path contains multiple network segments:<\/p>\n\n\n\n
Client\n   \u2193\nClient Network\n   \u2193\nProxy Gateway\n   \u2193\nProxy Infrastructure\n   \u2193\nExit Network\n   \u2193\nDestination Network\n   \u2193\nServer<\/code><\/pre>\n\n\n\n
The effective transfer capacity of the complete path is influenced by all of them.<\/p>\n\n\n\n
A 1 Gbps gateway cannot force a residential exit connected through a much slower access network to transfer at 1 Gbps.<\/p>\n\n\n\n
\n\n\n\n
Bandwidth Is Capacity, Not Delivered Performance<\/h2>\n\n\n\n
A useful analogy is a road.<\/p>\n\n\n\n
Bandwidth is similar to the maximum capacity of the road.<\/p>\n\n\n\n
Throughput is how many vehicles actually pass through it during a particular period.<\/p>\n\n\n\n
A four-lane road may support more traffic than a one-lane road, but actual traffic flow still depends on:<\/p>\n\n\n\n
Congestion\nIntersections\nAccidents\nTraffic patterns\nVehicle behavior\nDownstream roads<\/code><\/pre>\n\n\n\n
Networks behave similarly.<\/p>\n\n\n\n
A high-capacity link provides room for traffic, but does not guarantee that a single TCP connection can consume all of that capacity.<\/p>\n\n\n\n
This is why:<\/p>\n\n\n\n
100 Mbps available<\/code><\/pre>\n\n\n\n
does not automatically mean:<\/p>\n\n\n\n
100 Mbps observed<\/code><\/pre>\n\n\n\n
\n\n\n\n
What Is Proxy Throughput?<\/h2>\n\n\n\n
Throughput measures the amount of traffic successfully transferred during a period of time.<\/p>\n\n\n\n
A simplified calculation is:T<\/mi>h<\/mi>r<\/mi>o<\/mi>u<\/mi>g<\/mi>h<\/mi>p<\/mi>u<\/mi>t<\/mi>=<\/mo>T<\/mi>r<\/mi>a<\/mi>n<\/mi>s<\/mi>f<\/mi>e<\/mi>r<\/mi>r<\/mi>e<\/mi>d<\/mi> <\/mtext>B<\/mi>i<\/mi>t<\/mi>s<\/mi><\/mrow>T<\/mi>r<\/mi>a<\/mi>n<\/mi>s<\/mi>f<\/mi>e<\/mi>r<\/mi> <\/mtext>T<\/mi>i<\/mi>m<\/mi>e<\/mi><\/mrow><\/mfrac><\/mrow>Throughput = \\frac{Transferred\\ Bits}{Transfer\\ Time}<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Suppose a connection transfers 50 MB in 10 seconds.<\/p>\n\n\n\n
Ignoring decimal\/binary unit differences for illustration:50<\/mn> <\/mtext>M<\/mi>B<\/mi>\u00d7<\/mo>8<\/mn>=<\/mo>400<\/mn> <\/mtext>M<\/mi>b<\/mi><\/mrow>50\\ MB \\times 8 = 400\\ Mb<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Therefore:T<\/mi>h<\/mi>r<\/mi>o<\/mi>u<\/mi>g<\/mi>h<\/mi>p<\/mi>u<\/mi>t<\/mi>=<\/mo>400<\/mn> <\/mtext>M<\/mi>b<\/mi><\/mrow>10<\/mn>s<\/mi><\/mrow><\/mfrac>=<\/mo>40<\/mn> <\/mtext>M<\/mi>b<\/mi>p<\/mi>s<\/mi><\/mrow>Throughput = \\frac{400\\ Mb}{10s} = 40\\ Mbps<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Even if the underlying network supports:<\/p>\n\n\n\n
100 Mbps<\/code><\/pre>\n\n\n\n
the measured transfer produced only:<\/p>\n\n\n\n
40 Mbps<\/code><\/pre>\n\n\n\n
That difference is not necessarily evidence that the advertised capacity is false.<\/p>\n\n\n\n
The complete network path may simply prevent the application from reaching the theoretical capacity.<\/p>\n\n\n\n
\n\n\n\n
Goodput Is Often More Useful Than Throughput<\/h2>\n\n\n\n
For proxy applications, throughput is still not the final metric.<\/p>\n\n\n\n
Imagine that 100 MB crosses the network.<\/p>\n\n\n\n
Not all 100 MB necessarily represents the data the application actually wanted.<\/p>\n\n\n\n
Traffic can include:<\/p>\n\n\n\n
TCP\/IP headers\nTLS overhead\nHTTP headers\nProxy protocol overhead\nRetransmitted packets\nControl traffic<\/code><\/pre>\n\n\n\n
If the application ultimately receives 85 MB of useful payload, then the useful data rate is lower than the raw network throughput.<\/p>\n\n\n\n
This is called goodput<\/strong>.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Bandwidth\n    \u2193\nMaximum Available Capacity\n    \u2193\nThroughput\n    \u2193\nActual Traffic Transferred\n    \u2193\nGoodput\n    \u2193\nUseful Application Data<\/code><\/pre>\n\n\n\n
For scraping systems, goodput can be more meaningful than raw throughput because the business objective is usually not to move packets.<\/p>\n\n\n\n
It is to collect usable data.<\/p>\n\n\n\n
\n\n\n\n
1. Proxy Bandwidth Does Not Describe the Entire Network Path<\/h2>\n\n\n\n
Suppose a proxy gateway has:<\/p>\n\n\n\n
10 Gbps Uplink<\/code><\/pre>\n\n\n\n
A user might conclude:<\/p>\n\n\n\n
My proxy connection can reach 10 Gbps.<\/code><\/pre>\n\n\n\n
That conclusion ignores the rest of the path.<\/p>\n\n\n\n
Imagine:<\/p>\n\n\n\n
Client\n  \u2502\n  \u2502 500 Mbps\n  \u2193\nGateway\n  \u2502\n  \u2502 10 Gbps\n  \u2193\nExit Network\n  \u2502\n  \u2502 80 Mbps\n  \u2193\nDestination<\/code><\/pre>\n\n\n\n
The gateway’s 10 Gbps capacity does not remove the 80 Mbps limitation farther downstream.<\/p>\n\n\n\n
A simplified model is:P<\/mi>a<\/mi>t<\/mi>h<\/mi> <\/mtext>C<\/mi>a<\/mi>p<\/mi>a<\/mi>c<\/mi>i<\/mi>t<\/mi>y<\/mi>\u2264<\/mo>M<\/mi>i<\/mi>n<\/mi>i<\/mi>m<\/mi>u<\/mi>m<\/mi> <\/mtext>C<\/mi>a<\/mi>p<\/mi>a<\/mi>c<\/mi>i<\/mi>t<\/mi>y<\/mi> <\/mtext>A<\/mi>l<\/mi>o<\/mi>n<\/mi>g<\/mi> <\/mtext>T<\/mi>h<\/mi>e<\/mi> <\/mtext>P<\/mi>a<\/mi>t<\/mi>h<\/mi><\/mrow>Path\\ Capacity \\leq Minimum\\ Capacity\\ Along\\ The\\ Path<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
If the relevant links support:<\/p>\n\n\n\n
500 Mbps\n10 Gbps\n80 Mbps\n1 Gbps<\/code><\/pre>\n\n\n\n
then a single flow cannot simply assume the 10 Gbps link determines performance.<\/p>\n\n\n\n
This is why proxy bandwidth claims must always be interpreted in terms of where that capacity exists<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
2. Latency and Bandwidth Measure Different Properties<\/h2>\n\n\n\n
Latency measures how long data takes to travel.<\/p>\n\n\n\n
Bandwidth describes how much data a network can carry over time.<\/p>\n\n\n\n
They are related to performance, but they are not the same thing.<\/p>\n\n\n\n
Consider:<\/p>\n\n\n\n
Proxy<\/th>RTT<\/th>Available Capacity<\/th>Observed Throughput<\/th><\/tr><\/thead>
A<\/td>30 ms<\/td>100 Mbps<\/td>25 Mbps<\/td><\/tr>
B<\/td>90 ms<\/td>500 Mbps<\/td>120 Mbps<\/td><\/tr>
C<\/td>50 ms<\/td>1 Gbps<\/td>70 Mbps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Proxy A has the lowest latency but not the highest throughput.<\/p>\n\n\n\n
Proxy C has the highest theoretical capacity but still does not achieve the highest measured throughput.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
Low Latency\n    \u2260\nHigh Throughput<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
High Bandwidth\n    \u2260\nLow Latency<\/code><\/pre>\n\n\n\n
A proxy can be responsive for small requests while performing poorly for large transfers.<\/p>\n\n\n\n
Another can have a slower initial response while delivering large amounts of data efficiently once the transfer is established.<\/p>\n\n\n\n
\n\n\n\n
3. Bandwidth-Delay Product Explains Why Latency Still Matters<\/h2>\n\n\n\n
Bandwidth and latency interact through an important networking concept called the Bandwidth-Delay Product<\/strong>, or BDP.<\/p>\n\n\n\n
A simplified formula is:B<\/mi>D<\/mi>P<\/mi>=<\/mo>B<\/mi>a<\/mi>n<\/mi>d<\/mi>w<\/mi>i<\/mi>d<\/mi>t<\/mi>h<\/mi>\u00d7<\/mo>R<\/mi>T<\/mi>T<\/mi><\/mrow>BDP = Bandwidth \\times RTT<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Suppose a network path supports:<\/p>\n\n\n\n
100 Mbps<\/code><\/pre>\n\n\n\n
with:<\/p>\n\n\n\n
100 ms RTT<\/code><\/pre>\n\n\n\n
Then:100<\/mn>,<\/mo>000<\/mn>,<\/mo>000<\/mn> <\/mtext>b<\/mi>i<\/mi>t<\/mi>s<\/mi>\/<\/mi>s<\/mi>\u00d7<\/mo>0.1<\/mn>s<\/mi>=<\/mo>10<\/mn>,<\/mo>000<\/mn>,<\/mo>000<\/mn> <\/mtext>b<\/mi>i<\/mi>t<\/mi>s<\/mi><\/mrow>100,000,000\\ bits\/s \\times 0.1s = 10,000,000\\ bits<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
which is approximately:<\/p>\n\n\n\n
1.25 MB<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
Now imagine the sender can keep only a much smaller amount of data in flight.<\/p>\n\n\n\n
The connection may fail to use the available bandwidth efficiently.<\/p>\n\n\n\n
This is why a high-bandwidth, high-latency path requires sufficient TCP windowing and congestion-control behavior to reach its potential throughput.<\/p>\n\n\n\n
\n\n\n\n
TCP Window Size Can Limit Effective Throughput<\/h2>\n\n\n\n
TCP cannot simply send unlimited data and hope it arrives.<\/p>\n\n\n\n
The receiver advertises how much data it can accept, while TCP congestion control also regulates how much data can be in flight.<\/p>\n\n\n\n
A simplified relationship is:T<\/mi>h<\/mi>r<\/mi>o<\/mi>u<\/mi>g<\/mi>h<\/mi>p<\/mi>u<\/mi>t<\/mi>\u2272<\/mo>W<\/mi>i<\/mi>n<\/mi>d<\/mi>o<\/mi>w<\/mi><\/mrow>R<\/mi>T<\/mi>T<\/mi><\/mrow><\/mfrac><\/mrow>Throughput \\lesssim \\frac{Window}{RTT}<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Suppose:<\/p>\n\n\n\n
Effective Window = 256 KB\nRTT = 100 ms<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
Modern TCP implementations use mechanisms such as window scaling and dynamic congestion control, so real behavior is more sophisticated than this simple equation.<\/p>\n\n\n\n
But the principle remains important:<\/p>\n\n\n\n
\n
A fast network interface does not guarantee that one TCP flow can fully utilize it.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
4. TCP Slow Start Can Prevent Short Transfers From Reaching Full Bandwidth<\/h2>\n\n\n\n
TCP does not normally begin a new connection by immediately sending data at the maximum possible rate.<\/p>\n\n\n\n
Congestion control gradually determines how much data can safely be placed into the network.<\/p>\n\n\n\n
A simplified connection might behave like:<\/p>\n\n\n\n
Connection starts\n      \u2193\nSmall congestion window\n      \u2193\nAcknowledgments arrive\n      \u2193\nWindow grows\n      \u2193\nMore data in flight\n      \u2193\nHigher throughput<\/code><\/pre>\n\n\n\n
For a large file transfer, the connection may have enough time to reach a high transfer rate.<\/p>\n\n\n\n
But many proxy workloads consist of short responses:<\/p>\n\n\n\n
HTML page\nJSON API\nSearch result\nProduct page\nSmall image<\/code><\/pre>\n\n\n\n
The transfer may finish before TCP ever approaches the available network capacity.<\/p>\n\n\n\n
This creates an important distinction:<\/p>\n\n\n\n
Maximum Link Bandwidth\n        \u2260\nBandwidth Used by a Short Request<\/code><\/pre>\n\n\n\n
For web scraping, this is especially relevant because many workloads consist of thousands or millions of relatively small transfers rather than one enormous file.<\/p>\n\n\n\n
\n\n\n\n
5. Packet Loss Can Reduce Throughput Without Reducing Nominal Bandwidth<\/h2>\n\n\n\n
Suppose a path has:<\/p>\n\n\n\n
Available Capacity:\n500 Mbps<\/code><\/pre>\n\n\n\n
but packets are occasionally lost.<\/p>\n\n\n\n
TCP detects missing data and retransmits it.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Send Data\n   \u2193\nPacket Lost\n   \u2193\nLoss Detected\n   \u2193\nRetransmission\n   \u2193\nCongestion Control Reacts\n   \u2193\nTransfer Continues<\/code><\/pre>\n\n\n\n
The physical or configured bandwidth may still be 500 Mbps.<\/p>\n\n\n\n
But useful application throughput can fall substantially.<\/p>\n\n\n\n
This is because packet loss can produce both:<\/p>\n\n\n\n
Retransmission overhead<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
Reduced sending rate<\/code><\/pre>\n\n\n\n
depending on the congestion-control algorithm and loss pattern.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
High Bandwidth + Packet Loss<\/code><\/pre>\n\n\n\n
can perform worse than:<\/p>\n\n\n\n
Lower Bandwidth + Stable Path<\/code><\/pre>\n\n\n\n
for some workloads.<\/p>\n\n\n\n
\n\n\n\n
Retransmitted Bytes Are Not Goodput<\/h2>\n\n\n\n
Suppose the network sends:<\/p>\n\n\n\n
110 MB total<\/code><\/pre>\n\n\n\n
to successfully deliver:<\/p>\n\n\n\n
100 MB application payload<\/code><\/pre>\n\n\n\n
because some packets needed retransmission.<\/p>\n\n\n\n
The network carried 110 MB.<\/p>\n\n\n\n
But the application gained only 100 MB of useful new data.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
110 MB Network Traffic\n        \u2193\n10 MB Duplicate \/ Retransmitted\n        \u2193\n100 MB Useful Data<\/code><\/pre>\n\n\n\n
This illustrates why throughput and goodput should be measured separately.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
\n\n\n\n
6. Shared Proxy Bandwidth Is Different From Dedicated Bandwidth<\/h2>\n\n\n\n
Another source of confusion is shared infrastructure.<\/p>\n\n\n\n
Suppose a proxy gateway has:<\/p>\n\n\n\n
10 Gbps capacity<\/code><\/pre>\n\n\n\n
but serves many concurrent connections.<\/p>\n\n\n\n
That does not mean:<\/p>\n\n\n\n
Every connection = 10 Gbps<\/code><\/pre>\n\n\n\n
Instead:<\/p>\n\n\n\n
                    \u250c\u2192 User A\n                    \u251c\u2192 User B\n10 Gbps Gateway \u2500\u2500\u2500\u2500\u253c\u2192 User C\n                    \u251c\u2192 User D\n                    \u2514\u2192 ...<\/code><\/pre>\n\n\n\n
Capacity is shared across workloads.<\/p>\n\n\n\n
Actual throughput per connection can depend on:<\/p>\n\n\n\n
Concurrent traffic\nTraffic shaping\nGateway load\nExit capacity\nUpstream congestion\nDestination capacity<\/code><\/pre>\n\n\n\n
This distinction becomes even more important for residential proxy networks because the exit side can also operate on consumer access networks with variable capacity.<\/p>\n\n\n\n
\n\n\n\n
Residential Exit Bandwidth Can Change Over Time<\/h2>\n\n\n\n
A residential proxy endpoint exists on a real access network.<\/p>\n\n\n\n
Its available capacity can vary because the underlying connection may simultaneously serve other traffic.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Residential Connection\n       \u2502\n       \u251c\u2192 Proxy Traffic\n       \u251c\u2192 Video Streaming\n       \u251c\u2192 Downloads\n       \u251c\u2192 Mobile Devices\n       \u2514\u2192 Other Household Traffic<\/code><\/pre>\n\n\n\n
Even if the nominal access connection remains unchanged, the bandwidth available to a particular proxy flow can vary.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
10:00\nAvailable to Proxy Flow \u2192 80 Mbps\n\n20:00\nAvailable to Proxy Flow \u2192 25 Mbps<\/code><\/pre>\n\n\n\n
The exact behavior depends on the underlying network.<\/p>\n\n\n\n
This is one reason residential proxy throughput should be measured over time rather than inferred from a single speed test.<\/p>\n\n\n\n
\n\n\n\n
7. Destination Servers Can Limit Proxy Throughput<\/h2>\n\n\n\n
Sometimes the bottleneck is not the proxy at all.<\/p>\n\n\n\n
Consider:<\/p>\n\n\n\n
Client\n   \u2193\n500 Mbps\n   \u2193\nProxy\n   \u2193\n500 Mbps\n   \u2193\nDestination<\/code><\/pre>\n\n\n\n
but the destination delivers data to the connection at:<\/p>\n\n\n\n
20 Mbps<\/code><\/pre>\n\n\n\n
Then observed throughput cannot exceed what the destination provides for that transfer.<\/p>\n\n\n\n
A destination can limit effective delivery because of:<\/p>\n\n\n\n
Server load\nApplication processing\nPer-connection behavior\nCDN selection\nRate controls\nStorage performance\nNetwork congestion<\/code><\/pre>\n\n\n\n
This means testing a proxy against one website does not necessarily reveal the maximum throughput of the proxy infrastructure.<\/p>\n\n\n\n
You may instead be measuring:<\/p>\n\n\n\n
Proxy\n+\nInternet Path\n+\nDestination<\/code><\/pre>\n\n\n\n
as one combined system.<\/p>\n\n\n\n
\n\n\n\n
CDN Selection Can Change the Result<\/h2>\n\n\n\n
Modern websites often serve content through Content Delivery Networks.<\/p>\n\n\n\n
The selected CDN edge can depend on network topology, DNS behavior, geography, and other routing mechanisms.<\/p>\n\n\n\n
Two proxy exits can therefore receive content from different infrastructure:<\/p>\n\n\n\n
Proxy A\n   \u2193\nCDN Edge A\n\nProxy B\n   \u2193\nCDN Edge B<\/code><\/pre>\n\n\n\n
Even if the proxies themselves have similar network capacity, the resulting throughput can differ because the downstream paths are different.<\/p>\n\n\n\n
This is why proxy throughput should ideally be tested against multiple controlled destinations rather than one arbitrary website.<\/p>\n\n\n\n
\n\n\n\n
HTTP Response Time Is Not the Same as Throughput<\/h2>\n\n\n\n
Consider a request that returns:<\/p>\n\n\n\n
HTTP 200<\/code><\/pre>\n\n\n\n
in:<\/p>\n\n\n\n
150 ms<\/code><\/pre>\n\n\n\n
That number alone does not tell you the connection throughput.<\/p>\n\n\n\n
For a small 5 KB JSON response, 150 ms might mostly represent:<\/p>\n\n\n\n
Connection setup\nTLS\nServer processing\nRTT<\/code><\/pre>\n\n\n\n
The payload is too small to meaningfully test sustained transfer performance.<\/p>\n\n\n\n
For a 500 MB transfer, throughput becomes much more visible.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
Small Request Latency Test<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
Large Transfer Throughput Test<\/code><\/pre>\n\n\n\n
measure different properties.<\/p>\n\n\n\n
This is why using a simple IP-check endpoint as a “proxy speed test” provides only limited information.<\/p>\n\n\n\n
\n\n\n\n
Time to First Byte and Throughput Should Be Separated<\/h2>\n\n\n\n
Another useful distinction is Time to First Byte (TTFB)<\/strong>.<\/p>\n\n\n\n
Consider:<\/p>\n\n\n\n
Request Sent\n    \u2193\nWait\n    \u2193\nFirst Byte\n    \u2193\nData Transfer\n    \u2193\nLast Byte<\/code><\/pre>\n\n\n\n
TTFB measures the delay before response data begins arriving.<\/p>\n\n\n\n
Throughput measures how quickly data transfers over time.<\/p>\n\n\n\n
A connection can have:<\/p>\n\n\n\n
Low TTFB\nLow Throughput<\/code><\/pre>\n\n\n\n
or:<\/p>\n\n\n\n
High TTFB\nHigh Throughput<\/code><\/pre>\n\n\n\n
For example:<\/p>\n\n\n\n
Connection A<\/h3>\n\n\n\n
TTFB: 100 ms\nDownload: 5 Mbps<\/code><\/pre>\n\n\n\n
Connection B<\/h3>\n\n\n\n
TTFB: 400 ms\nDownload: 100 Mbps<\/code><\/pre>\n\n\n\n
Which is better depends on the workload.<\/p>\n\n\n\n
For thousands of tiny API requests, Connection A may feel faster.<\/p>\n\n\n\n
For large downloads, Connection B may finish much sooner.<\/p>\n\n\n\n
\n\n\n\n
Browser Workloads Rarely Use Bandwidth Like a Single Download<\/h2>\n\n\n\n
Browser automation makes bandwidth analysis even more complicated.<\/p>\n\n\n\n
A webpage may load:<\/p>\n\n\n\n
HTML\nCSS\nJavaScript\nImages\nFonts\nAPI responses\nVideo\nAnalytics\nThird-party resources<\/code><\/pre>\n\n\n\n
The browser does not necessarily download them as one continuous stream.<\/p>\n\n\n\n
Instead:<\/p>\n\n\n\n
Navigation\n    \u2193\nHTML\n    \u2193\nResource Discovery\n    \u2193\nMultiple Requests\n    \u2193\nParallel \/ Multiplexed Transfers\n    \u2193\nJavaScript Execution\n    \u2193\nAdditional API Requests<\/code><\/pre>\n\n\n\n
A browser can therefore spend significant time:<\/p>\n\n\n\n
Waiting\nParsing\nExecuting JavaScript\nRendering\nDiscovering resources<\/code><\/pre>\n\n\n\n
while the network connection is not using its full available bandwidth.<\/p>\n\n\n\n
As a result:<\/p>\n\n\n\n
1 Gbps Network<\/code><\/pre>\n\n\n\n
does not imply:<\/p>\n\n\n\n
Webpage loads 10\u00d7 faster than on 100 Mbps<\/code><\/pre>\n\n\n\n
once network capacity is no longer the dominant bottleneck.<\/p>\n\n\n\n
\n\n\n\n
HTTP\/2 Can Improve Connection Utilization Without Increasing Bandwidth<\/h2>\n\n\n\n
HTTP\/2 can multiplex multiple streams over a connection.<\/p>\n\n\n\n
Instead of:<\/p>\n\n\n\n
Connection 1 \u2192 Resource A\nConnection 2 \u2192 Resource B\nConnection 3 \u2192 Resource C<\/code><\/pre>\n\n\n\n
the architecture can look like:<\/p>\n\n\n\n
One Connection\n    \u251c\u2192 Stream A\n    \u251c\u2192 Stream B\n    \u2514\u2192 Stream C<\/code><\/pre>\n\n\n\n
This can reduce some connection-management overhead and improve how network capacity is used.<\/p>\n\n\n\n
But it does not magically increase physical bandwidth.<\/p>\n\n\n\n
If the bottleneck is:<\/p>\n\n\n\n
50 Mbps<\/code><\/pre>\n\n\n\n
HTTP\/2 does not transform it into:<\/p>\n\n\n\n
500 Mbps<\/code><\/pre>\n\n\n\n
Protocol efficiency and network capacity are separate concepts.<\/p>\n\n\n\n
\n\n\n\n
Compression Can Make Application Throughput Look Higher Than Network Throughput<\/h2>\n\n\n\n
Suppose a server has:<\/p>\n\n\n\n
100 MB uncompressed JSON<\/code><\/pre>\n\n\n\n
and compression reduces it to:<\/p>\n\n\n\n
20 MB transferred<\/code><\/pre>\n\n\n\n
The network only needs to transport 20 MB.<\/p>\n\n\n\n
The application then decompresses it back into a much larger representation.<\/p>\n\n\n\n
From the network perspective:<\/p>\n\n\n\n
20 MB transferred<\/code><\/pre>\n\n\n\n
From the application-data perspective:<\/p>\n\n\n\n
100 MB processed<\/code><\/pre>\n\n\n\n
This means “MB\/s” can become ambiguous unless you define what is being measured.<\/p>\n\n\n\n
Are you measuring:<\/p>\n\n\n\n
Wire bytes?\nCompressed payload?\nDecompressed payload?\nStored dataset size?<\/code><\/pre>\n\n\n\n
Professional proxy benchmarking should specify the measurement layer.<\/p>\n\n\n\n
\n\n\n\n
Protocol Overhead Reduces Useful Payload Efficiency<\/h2>\n\n\n\n
Application data is wrapped by multiple protocol layers.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Application Data\n      \u2193\nHTTP\n      \u2193\nTLS\n      \u2193\nTCP\n      \u2193\nIP\n      \u2193\nLink Layer<\/code><\/pre>\n\n\n\n
Each layer introduces some overhead.<\/p>\n\n\n\n
For large transfers, this overhead may represent a relatively small percentage of total traffic.<\/p>\n\n\n\n
For many tiny requests, however, the relative overhead can become much more noticeable.<\/p>\n\n\n\n
For example, repeatedly transferring tiny payloads may involve:<\/p>\n\n\n\n
Request headers\nResponse headers\nTCP acknowledgments\nTLS records\nConnection setup<\/code><\/pre>\n\n\n\n
that are large relative to the useful data.<\/p>\n\n\n\n
This leads to a useful metric.P<\/mi>a<\/mi>y<\/mi>l<\/mi>o<\/mi>a<\/mi>d<\/mi> <\/mtext>E<\/mi>f<\/mi>f<\/mi>i<\/mi>c<\/mi>i<\/mi>e<\/mi>n<\/mi>c<\/mi>y<\/mi>=<\/mo>U<\/mi>s<\/mi>e<\/mi>f<\/mi>u<\/mi>l<\/mi> <\/mtext>A<\/mi>p<\/mi>p<\/mi>l<\/mi>i<\/mi>c<\/mi>a<\/mi>t<\/mi>i<\/mi>o<\/mi>n<\/mi> <\/mtext>B<\/mi>y<\/mi>t<\/mi>e<\/mi>s<\/mi><\/mrow>T<\/mi>o<\/mi>t<\/mi>a<\/mi>l<\/mi> <\/mtext>T<\/mi>r<\/mi>a<\/mi>n<\/mi>s<\/mi>f<\/mi>e<\/mi>r<\/mi>r<\/mi>e<\/mi>d<\/mi> <\/mtext>B<\/mi>y<\/mi>t<\/mi>e<\/mi>s<\/mi><\/mrow><\/mfrac><\/mrow>Payload\\ Efficiency = \\frac{Useful\\ Application\\ Bytes}{Total\\ Transferred\\ Bytes}<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
Higher payload efficiency means more of the network traffic contributes directly to the application’s objective.<\/p>\n\n\n\n
\n\n\n\n
Scraping Throughput Should Not Be Measured Only in Mbps<\/h2>\n\n\n\n
For web scraping, Mbps is often not the most meaningful performance metric.<\/p>\n\n\n\n
Suppose:<\/p>\n\n\n\n
Proxy A:\n100 Mbps<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
Proxy B:\n50 Mbps<\/code><\/pre>\n\n\n\n
But the scraper produces:<\/p>\n\n\n\n
Proxy A:\n120 valid product pages \/ second\n\nProxy B:\n180 valid product pages \/ second<\/code><\/pre>\n\n\n\n
Which is actually faster for the workload?<\/p>\n\n\n\n
Proxy B.<\/p>\n\n\n\n
This suggests a more useful metric:U<\/mi>s<\/mi>e<\/mi>f<\/mi>u<\/mi>l<\/mi> <\/mtext>D<\/mi>a<\/mi>t<\/mi>a<\/mi> <\/mtext>T<\/mi>h<\/mi>r<\/mi>o<\/mi>u<\/mi>g<\/mi>h<\/mi>p<\/mi>u<\/mi>t<\/mi>=<\/mo>V<\/mi>a<\/mi>l<\/mi>i<\/mi>d<\/mi> <\/mtext>R<\/mi>e<\/mi>c<\/mi>o<\/mi>r<\/mi>d<\/mi>s<\/mi><\/mrow>T<\/mi>i<\/mi>m<\/mi>e<\/mi><\/mrow><\/mfrac><\/mrow>Useful\\ Data\\ Throughput = \\frac{Valid\\ Records}{Time}<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Valid pages \/ second\nProducts \/ minute\nSuccessful API responses \/ second\nValid MB \/ second<\/code><\/pre>\n\n\n\n
The correct unit depends on the task.<\/p>\n\n\n\n
This moves performance measurement from the network layer to the business-result layer.<\/p>\n\n\n\n
\n\n\n\n
Bandwidth Consumption and Data Collection Efficiency Are Different<\/h2>\n\n\n\n
Imagine two scraping systems.<\/p>\n\n\n\n
System A<\/h3>\n\n\n\n
Transferred:\n500 GB\n\nValid Records:\n5 million<\/code><\/pre>\n\n\n\n
System B<\/h3>\n\n\n\n
Transferred:\n300 GB\n\nValid Records:\n5 million<\/code><\/pre>\n\n\n\n
Both produce the same dataset.<\/p>\n\n\n\n
System B requires less transferred traffic per valid record.<\/p>\n\n\n\n
A useful metric is:B<\/mi>y<\/mi>t<\/mi>e<\/mi>s<\/mi> <\/mtext>p<\/mi>e<\/mi>r<\/mi> <\/mtext>V<\/mi>a<\/mi>l<\/mi>i<\/mi>d<\/mi> <\/mtext>R<\/mi>e<\/mi>c<\/mi>o<\/mi>r<\/mi>d<\/mi>=<\/mo>T<\/mi>o<\/mi>t<\/mi>a<\/mi>l<\/mi> <\/mtext>T<\/mi>r<\/mi>a<\/mi>n<\/mi>s<\/mi>f<\/mi>e<\/mi>r<\/mi>r<\/mi>e<\/mi>d<\/mi> <\/mtext>B<\/mi>y<\/mi>t<\/mi>e<\/mi>s<\/mi><\/mrow>V<\/mi>a<\/mi>l<\/mi>i<\/mi>d<\/mi> <\/mtext>R<\/mi>e<\/mi>c<\/mi>o<\/mi>r<\/mi>d<\/mi>s<\/mi><\/mrow><\/mfrac><\/mrow>Bytes\\ per\\ Valid\\ Record = \\frac{Total\\ Transferred\\ Bytes}{Valid\\ Records}<\/annotation><\/semantics><\/math><\/p>\n\n\n\n
For System A:<\/p>\n\n\n\n
500 GB \/ 5,000,000<\/code><\/pre>\n\n\n\n
For System B:<\/p>\n\n\n\n
300 GB \/ 5,000,000<\/code><\/pre>\n\n\n\n
The second architecture is more traffic-efficient even if its peak Mbps is lower.<\/p>\n\n\n\n
For traffic-based proxy plans, this distinction can directly affect infrastructure cost.<\/p>\n\n\n\n
\n\n\n\n
Browser Resource Blocking Can Reduce Bandwidth Without Reducing Useful Data<\/h2>\n\n\n\n
Consider a browser automation task whose only goal is to extract:<\/p>\n\n\n\n
Product Name\nPrice\nAvailability\nSKU<\/code><\/pre>\n\n\n\n
The page may also load:<\/p>\n\n\n\n
Large images\nVideo\nFonts\nAnalytics\nAdvertising resources<\/code><\/pre>\n\n\n\n
If those resources are unnecessary for the permitted workflow and the page continues to function correctly without them, reducing unnecessary transfers can improve efficiency.<\/p>\n\n\n\n
The goal becomes:<\/p>\n\n\n\n
Useful Page Data\n-----------------\nTransferred Bytes<\/code><\/pre>\n\n\n\n
rather than maximizing raw network utilization.<\/p>\n\n\n\n
A scraper using 30 Mbps efficiently can therefore outperform one consuming 100 Mbps while downloading unnecessary resources.<\/p>\n\n\n\n
\n\n\n\n
Proxy Bandwidth Should Be Measured in Both Directions<\/h2>\n\n\n\n
Network traffic has two directions:<\/p>\n\n\n\n
Upload\nDownload<\/code><\/pre>\n\n\n\n
Many scraping workloads are download-heavy:<\/p>\n\n\n\n
Small HTTP Request\n       \u2193\nLarge HTTP Response<\/code><\/pre>\n\n\n\n
But other workflows can send larger request bodies.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
API uploads\nForm submissions\nFile transfers<\/code><\/pre>\n\n\n\n
A network path can have asymmetric capacity:<\/p>\n\n\n\n
Download: 500 Mbps\nUpload:    50 Mbps<\/code><\/pre>\n\n\n\n
Therefore, one generic “bandwidth” number may hide important differences.<\/p>\n\n\n\n
A professional benchmark should specify:<\/p>\n\n\n\n
Upstream throughput\nDownstream throughput<\/code><\/pre>\n\n\n\n
where both matter.<\/p>\n\n\n\n
\n\n\n\n
Aggregate Throughput and Per-Connection Throughput Are Different<\/h2>\n\n\n\n
Suppose one proxy gateway supports:<\/p>\n\n\n\n
1 Gbps aggregate traffic<\/code><\/pre>\n\n\n\n
That does not mean one TCP connection can necessarily reach 1 Gbps.<\/p>\n\n\n\n
Imagine:<\/p>\n\n\n\n
Connection A \u2192 50 Mbps\nConnection B \u2192 60 Mbps\nConnection C \u2192 45 Mbps\n...<\/code><\/pre>\n\n\n\n
Together:<\/p>\n\n\n\n
Many Connections\n      \u2193\n800 Mbps Aggregate<\/code><\/pre>\n\n\n\n
while:<\/p>\n\n\n\n
Single Connection\n      \u2193\n60 Mbps<\/code><\/pre>\n\n\n\n
This distinction matters for workload design.<\/p>\n\n\n\n
A system performing thousands of independent requests may care more about:<\/p>\n\n\n\n
Aggregate Throughput<\/code><\/pre>\n\n\n\n
while a large file transfer may care more about:<\/p>\n\n\n\n
Single-Flow Throughput<\/code><\/pre>\n\n\n\n
Those should be benchmarked separately.<\/p>\n\n\n\n
\n\n\n\n
Concurrency Can Increase Throughput\u2014Until It Does Not<\/h2>\n\n\n\n
Suppose a proxy workload produces:<\/p>\n\n\n\n
Concurrency<\/th>Aggregate Throughput<\/th><\/tr><\/thead>
10<\/td>20 Mbps<\/td><\/tr>
50<\/td>75 Mbps<\/td><\/tr>
100<\/td>130 Mbps<\/td><\/tr>
250<\/td>190 Mbps<\/td><\/tr>
500<\/td>195 Mbps<\/td><\/tr>
1,000<\/td>170 Mbps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Initially, increasing concurrency improves utilization.<\/p>\n\n\n\n
Eventually, throughput plateaus.<\/p>\n\n\n\n
At still higher concurrency, it can decline.<\/p>\n\n\n\n
Possible bottlenecks include:<\/p>\n\n\n\n
Gateway capacity\nExit bandwidth\nCPU\nSockets\nNAT\nPacket loss\nQueueing\nDestination limits<\/code><\/pre>\n\n\n\n
This produces a saturation curve rather than unlimited linear scaling.<\/p>\n\n\n\n
A useful benchmark therefore searches for:<\/p>\n\n\n\n
Optimal Operating Range<\/code><\/pre>\n\n\n\n
not:<\/p>\n\n\n\n
Maximum Possible Concurrency<\/code><\/pre>\n\n\n\n
\n\n\n\n
Queueing Can Increase Latency Before Bandwidth Is Fully Understood<\/h2>\n\n\n\n
When demand approaches a bottleneck’s service capacity, packets or requests can begin waiting in queues.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Incoming Traffic\n       \u2193\n      Queue\n       \u2193\nLimited-Capacity Link<\/code><\/pre>\n\n\n\n
Longer queues can increase latency.<\/p>\n\n\n\n
This means a proxy benchmark might observe:<\/p>\n\n\n\n
Throughput \u2192 still increasing slightly\nLatency \u2192 increasing dramatically<\/code><\/pre>\n\n\n\n
before outright failures begin.<\/p>\n\n\n\n
Therefore, saturation should be evaluated with both:<\/p>\n\n\n\n
Throughput\nLatency<\/code><\/pre>\n\n\n\n
rather than throughput alone.<\/p>\n\n\n\n
\n\n\n\n
Why One Speed Test Is Not Enough<\/h2>\n\n\n\n
A single bandwidth test captures only one moment.<\/p>\n\n\n\n
Proxy network conditions can vary by:<\/p>\n\n\n\n
Time\nExit\nISP\nCountry\nDestination\nRoute\nConcurrency\nPayload size\nProtocol<\/code><\/pre>\n\n\n\n
A more useful test matrix might include:<\/p>\n\n\n\n
Dimension<\/th>Example Values<\/th><\/tr><\/thead>
Transfer size<\/td>100 KB \/ 10 MB \/ 100 MB<\/td><\/tr>
Concurrency<\/td>1 \/ 10 \/ 100<\/td><\/tr>
Destination<\/td>A \/ B \/ C<\/td><\/tr>
Region<\/td>US \/ JP \/ DE<\/td><\/tr>
Proxy type<\/td>Residential \/ ISP<\/td><\/tr>
Time<\/td>Multiple intervals<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The objective is not simply to produce the largest Mbps number.<\/p>\n\n\n\n
It is to understand where performance changes and why.<\/p>\n\n\n\n
\n\n\n\n
A Better Proxy Bandwidth Benchmark<\/h2>\n\n\n\n
A professional benchmark should separate at least four layers.<\/p>\n\n\n\n
Layer 1: Connection Performance<\/h3>\n\n\n\n
Measure:<\/p>\n\n\n\n
DNS time\nTCP connection time\nProxy negotiation time\nTLS handshake time<\/code><\/pre>\n\n\n\n
Layer 2: Transfer Performance<\/h3>\n\n\n\n
Measure:<\/p>\n\n\n\n
TTFB\nTransfer duration\nBytes transferred\nAverage throughput<\/code><\/pre>\n\n\n\n
Layer 3: Network Quality<\/h3>\n\n\n\n
Measure where practical:<\/p>\n\n\n\n
RTT\nPacket loss\nRetransmissions\nConnection resets<\/code><\/pre>\n\n\n\n
Layer 4: Application Goodput<\/h3>\n\n\n\n
Measure:<\/p>\n\n\n\n
Valid pages \/ second\nValid records \/ second\nUseful bytes \/ second\nBytes per valid record<\/code><\/pre>\n\n\n\n
This prevents one metric from being mistaken for the entire performance picture.<\/p>\n\n\n\n
\n\n\n\n
Record Transfer Size When Measuring Throughput<\/h2>\n\n\n\n
Throughput without transfer size can be misleading.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Test A\nPayload: 5 KB\nObserved rate: 2 Mbps\n\nTest B\nPayload: 100 MB\nObserved rate: 90 Mbps<\/code><\/pre>\n\n\n\n
That does not necessarily mean the network became 45 times faster.<\/p>\n\n\n\n
The small transfer spends proportionally more time in setup and ramp-up phases.<\/p>\n\n\n\n
A benchmark record should therefore include:<\/p>\n\n\n\n
{\n  \"proxy_type\": \"residential\",\n  \"exit_country\": \"JP\",\n  \"payload_bytes\": 104857600,\n  \"ttfb_ms\": 180,\n  \"transfer_ms\": 10400,\n  \"throughput_mbps\": 80.66,\n  \"valid_response\": true\n}<\/code><\/pre>\n\n\n\n
This makes results comparable.<\/p>\n\n\n\n
\n\n\n\n
Use Percentiles Instead of Only Average Throughput<\/h2>\n\n\n\n
Suppose five tests produce:<\/p>\n\n\n\n
95 Mbps\n92 Mbps\n90 Mbps\n88 Mbps\n15 Mbps<\/code><\/pre>\n\n\n\n
An average hides the slow tail.<\/p>\n\n\n\n
At scale, users experience the distribution.<\/p>\n\n\n\n
Useful statistics include:<\/p>\n\n\n\n
Median\nP75\nP90\nP95\nP99<\/code><\/pre>\n\n\n\n
depending on sample size and purpose.<\/p>\n\n\n\n
You can also track:<\/p>\n\n\n\n
Throughput variance\nSlow-transfer rate\nTimeout rate<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
\n\n\n\n
Do Not Mix Bandwidth and Traffic Quota<\/h2>\n\n\n\n
Another common terminology problem is using “bandwidth” to describe how much traffic a user is allowed to consume.<\/p>\n\n\n\n
These are different concepts.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
100 GB Traffic<\/code><\/pre>\n\n\n\n
describes a quantity of transferred data.<\/p>\n\n\n\n
100 Mbps Bandwidth<\/code><\/pre>\n\n\n\n
describes a rate.<\/p>\n\n\n\n
The difference is similar to:<\/p>\n\n\n\n
GB\n\u2192 How much data<\/code><\/pre>\n\n\n\n
versus:<\/p>\n\n\n\n
Mbps\n\u2192 How fast data can move<\/code><\/pre>\n\n\n\n
A proxy plan can theoretically have:<\/p>\n\n\n\n
10 GB Traffic Allowance<\/code><\/pre>\n\n\n\n
while supporting a high transfer rate.<\/p>\n\n\n\n
Or it could provide a large traffic allowance while individual connections experience lower throughput.<\/p>\n\n\n\n
Always distinguish data volume<\/strong> from data transfer rate<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
Where ColaProxy<\/a> Fits Into Bandwidth and Throughput<\/h2>\n\n\n\n
For proxy infrastructure such as ColaProxy, application performance depends on the complete network path rather than one isolated bandwidth number.<\/p>\n\n\n\n
A simplified path is:<\/p>\n\n\n\n
Application\n     \u2193\nClient Network\n     \u2193\nColaProxy Gateway\n     \u2193\nProxy Routing\n     \u2193\nExit Network\n     \u2193\nInternet Path\n     \u2193\nDestination<\/code><\/pre>\n\n\n\n
For permitted automation and data collection, developers should benchmark the workload that actually matters to their application.<\/p>\n\n\n\n
For example, a scraper can measure:<\/p>\n\n\n\n
Valid responses \/ second<\/code><\/pre>\n\n\n\n
alongside:<\/p>\n\n\n\n
Transferred Mbps<\/code><\/pre>\n\n\n\n
while a large-data workflow may care more about:<\/p>\n\n\n\n
Sustained transfer throughput<\/code><\/pre>\n\n\n\n
and a browser automation workload may care about:<\/p>\n\n\n\n
Navigation completion time\nUseful data collected\nTransferred bytes per task<\/code><\/pre>\n\n\n\n
This approach avoids treating proxy bandwidth as a universal performance score.<\/p>\n\n\n\n
The relevant question is not simply:<\/p>\n\n\n\n
\n
How much bandwidth is available?<\/p>\n<\/blockquote>\n\n\n\n
It is:<\/p>\n\n\n\n
\n
How efficiently can the complete proxy path deliver the data required by this workload?<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
7 Differences Between Proxy Bandwidth and Throughput<\/h2>\n\n\n\n
The distinction can be summarized in seven points.<\/p>\n\n\n\n
1. Bandwidth describes capacity; throughput describes actual transfer.<\/strong><\/p>\n\n\n\n
A high-capacity network can still produce low observed throughput.<\/p>\n\n\n\n
2. Throughput depends on the complete path.<\/strong><\/p>\n\n\n\n
Client networks, gateways, exits, transit networks, and destinations can all become bottlenecks.<\/p>\n\n\n\n
3. Latency interacts with throughput but does not define bandwidth.<\/strong><\/p>\n\n\n\n
High-bandwidth paths can still have high RTT.<\/p>\n\n\n\n
4. TCP behavior affects how much capacity a connection can use.<\/strong><\/p>\n\n\n\n
Congestion control, windowing, slow start, and packet loss all influence transfer rates.<\/p>\n\n\n\n
5. Shared capacity does not equal per-connection capacity.<\/strong><\/p>\n\n\n\n
A multi-gigabit gateway may serve many simultaneous flows.<\/p>\n\n\n\n
6. Throughput is not the same as useful application data.<\/strong><\/p>\n\n\n\n
Protocol overhead and retransmissions mean goodput can be lower than raw throughput.<\/p>\n\n\n\n
7. The best proxy metric depends on the workload.<\/strong><\/p>\n\n\n\n
Scrapers may care about valid records per second, browsers about task completion time, and file-transfer applications about sustained Mbps.<\/p>\n\n\n\n
\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Proxy bandwidth<\/strong> is an important infrastructure characteristic, but it should not be treated as a direct measurement of real-world proxy performance.<\/p>\n\n\n\n
A more accurate model is:<\/p>\n\n\n\n
Network Capacity\n      \u2193\nBandwidth\n      \u2193\nTCP \/ Protocol Behavior\n      \u2193\nActual Transfer\n      \u2193\nThroughput\n      \u2193\nUseful Application Data\n      \u2193\nGoodput<\/code><\/pre>\n\n\n\n
Between bandwidth and useful data are many variables:<\/p>\n\n\n\n
Latency\nPacket loss\nTCP windows\nCongestion control\nSlow start\nShared capacity\nExit network conditions\nDestination performance\nProtocol overhead\nCompression\nConcurrency<\/code><\/pre>\n\n\n\n
This is why two proxy connections with identical nominal bandwidth can produce dramatically different application results.<\/p>\n\n\n\n
For high-volume proxy workloads, the most useful question is therefore not:<\/p>\n\n\n\n
\n
“How many Mbps does this proxy support?”<\/p>\n<\/blockquote>\n\n\n\n
A better question is:<\/p>\n\n\n\n
\n
“How much useful data can this proxy path deliver reliably for my actual workload?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
That shift\u2014from bandwidth to throughput and finally to goodput\u2014produces a much more realistic way to evaluate proxy infrastructure.<\/p>\n\n\n\n
\n\n\n\n
Frequently Asked Questions<\/h2>\n\n\n\n
What is proxy bandwidth?<\/h3>\n\n\n\n
Proxy bandwidth describes network transfer capacity associated with a proxy connection or infrastructure component. It is typically expressed in Mbps or Gbps.<\/p>\n\n\n\n
What is proxy throughput?<\/h3>\n\n\n\n
Proxy throughput is the amount of traffic actually transferred through the proxy path over a period of time.<\/p>\n\n\n\n
Why is proxy throughput lower than bandwidth?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
What is the difference between throughput and goodput?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Does lower proxy latency mean higher throughput?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Can packet loss reduce proxy throughput?<\/h3>\n\n\n\n
Yes. Packet loss can trigger retransmissions and congestion-control responses, reducing effective transfer rates even when nominal network bandwidth remains unchanged.<\/p>\n\n\n\n
Does increasing proxy concurrency increase throughput?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Is proxy bandwidth the same as proxy traffic?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u2026<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2005","post","type-post","status-publish","format-standard","hentry","category-proxy"],"_links":{"self":[{"href":"\/blog\/wp-json\/wp\/v2\/posts\/2005","targetHints":{"allow":["GET"]}}],"collection":[{"href":"\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"\/blog\/wp-json\/wp\/v2\/comments?post=2005"}],"version-history":[{"count":1,"href":"\/blog\/wp-json\/wp\/v2\/posts\/2005\/revisions"}],"predecessor-version":[{"id":2006,"href":"\/blog\/wp-json\/wp\/v2\/posts\/2005\/revisions\/2006"}],"wp:attachment":[{"href":"\/blog\/wp-json\/wp\/v2\/media?parent=2005"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"\/blog\/wp-json\/wp\/v2\/categories?post=2005"},{"taxonomy":"post_tag","embeddable":true,"href":"\/blog\/wp-json\/wp\/v2\/tags?post=2005"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}