How to Measure Mobile Proxy Quality: 7 Metrics, Protocol, and Scripts

Introduction: Why One Speed Number Doesn't Tell the Whole Story

Imagine you're choosing a mobile proxy and see a flashy claim: 50 Mbps speed. Sounds convincing, right? But that number tells you almost nothing about how the proxy will behave in real work. Speed is just one facet of quality, and far from the most important one. Much more often, people are let down not by a slow channel but by instability: the proxy responds instantly one moment and hangs for several seconds the next.

In this guide, you'll learn to measure mobile proxy quality honestly and systematically. You'll master seven key metrics, get ready-made scripts in bash and Python, learn a unified measurement protocol, and know how to read results properly. By the end, you'll be able to compile the data into a single table and objectively compare two providers.

What you'll get in the end: your own testing methodology, ready tools, and an understanding of which numbers are red flags. You'll stop believing advertising figures and start relying on your own measurements.

Who this guide is for: those who buy or already use mobile proxies and want to know what they're paying for. It's suitable for beginners because every step is explained in detail. There are also advanced elements: percentiles, long runs, and interpretation of distributions.

What you need to know beforehand: just enough to open a terminal and copy commands. No programming experience required. We will explain everything as we go.

How much time it will take: basic measurements will take about two to three hours. A full 24-hour run takes a full day, of course, but it runs in the background and doesn't require your constant attention. Set aside one quiet evening for reading and setup.

Why a single run proves nothing. The mobile network lives its own life. At one moment the tower is free, at the next it's overloaded. If you make one request and it turns out fast, that's a coincidence. The real picture emerges only from a series of dozens or hundreds of measurements distributed over time. That's why we will measure not once, but in series, and look not at the average but at the distribution.

Preliminary Preparation: Tools and a Unified Protocol

Before pressing buttons, let's gather a working set. Proper preparation ensures your numbers are comparable.

Necessary Tools

• curl – a command-line utility for sending requests. It's already installed on most systems.
• Python 3.8 or newer – for a script that calculates metrics and percentiles.
• Terminal – your operating system's command line.
• Text editor – for saving scripts and notes.
• Proxy access – address, port, login, and password for your mobile proxy.

How to Check That Everything Is Installed

1. Open a terminal.
2. Type curl --version and press Enter.
3. If you see a version number, curl is ready.
4. Type python3 --version and press Enter.
5. If you see something like Python 3.11, you're all set.

Tip: if python3 is not found, download Python from the official website. When installing on Windows, be sure to check Add Python to PATH, otherwise the terminal won't see the command.

Set of Reference Endpoints

An endpoint is the address we send requests to. It's crucial to choose real targets similar to those you'll actually work with. Don't test the proxy only on special speed test servers – they don't reflect real load.

Prepare three or four different addresses. For example, an IP check page, a lightweight text page, and one or two resources you plan to work with. Different targets give different pictures, and that's normal.

⚠️ Attention: Only use resources whose rules permit access and that don't violate the law. Do not use proxies or test scripts for actions that contravene legislation or terms of service.

Unified Measurement Protocol

To ensure fair comparison, fix the conditions and do not change them between tests of different providers.

• Fixed time of day. Measure both proxies in the same time window. The mobile network behaves differently at noon and at night.
• Minimum number of runs. Make a series of at least several dozen requests for each metric. The more samples, the more reliable the result.
• Same endpoints. Test both proxies on the same set of addresses.
• Same timeout settings. Set a uniform waiting limit for all requests.
• Same computer and channel. Don't switch devices mid-test.

Tip: create a separate folder for each provider and store logs there. That way you won't confuse anything when comparing.

✅ Check: you have curl and Python installed, a list of endpoints ready, and the protocol conditions written down. Now you can move on to theory.

Basic Concepts in Simple Terms

Let's break down the terms you'll encounter at every step. Understanding these words is half the battle.

Latency

Latency is the time between sending a request and receiving a response. Measured in milliseconds. The lower, the better. Imagine yelling into a mountain and waiting for an echo: latency is the pause until the first sound.

TTFB

TTFB stands for Time to First Byte. It's the moment when the server starts sending a response. This is the most important part of latency because it shows how fast the proxy and server reacted to your request, before the main content is transferred.

Throughput

Throughput is how much data the proxy can transmit per second. This is the speed that's often advertised. It's important, but only alongside other metrics.

Jitter

Jitter is the variation in latency from request to request. If one response came in 100 ms, the next in 105 ms, and the third in 98 ms, the jitter is small and that's good. If values jump from 80 to 900 ms, the jitter is huge and work will be erratic.

Success Rate

This is the percentage of requests that completed successfully, without errors or interruptions. This metric shows reliability. A proxy can be fast, but if every tenth request fails, it's painful to work with.

Percentiles p50, p95, and p99

These describe the distribution of values. The p50 percentile is the median: half of requests are faster than this value, half slower. The p95 percentile means 95% of requests finished within that time, while 5% were worse. The p99 percentile shows the behavior of the slowest cases.

Tip: Remember the key rule: the average lies, but percentiles tell the truth. If you have nine fast responses and one that hung for ten seconds, the average looks tolerable, but p99 immediately shows the problem.

How Slow Differs from Unstable

A slow proxy consistently gives high latency values. That's predictable. An unstable proxy gives sometimes excellent, sometimes terrible results. Often instability is worse than steady slowness because you can't plan for it.

✅ Check: you understand latency, TTFB, throughput, jitter, success rate, and percentiles. Great, let's move to practice.

Step 1: Measure Availability and Success Rate

Goal of this step: find out how reliably the proxy responds to requests and understand what errors occur.

What We Do

We'll send a series of several dozen identical requests and count how many complete successfully. At the same time, we'll collect errors by type: timeouts, connection drops, responses with error codes.

Step-by-Step Instructions

1. Open a terminal.
2. Prepare the proxy access string in the format: login, password, address, and port.
3. Execute a series of requests using a simple loop, where the curl command connects to your endpoint through the proxy.
4. For each request, record the response code and whether it succeeded or failed.
5. After the series, calculate the percentage of successful responses.

The basic command for one request looks like: curl with the proxy flag, a timeout flag, and the address. The --max-time flag limits waiting time so a hung request doesn't stop the entire series.

How to Read the Result

Divide responses into groups. Successful ones have normal codes. Separately count timeouts (server didn't respond in time), connection drops, and server error code responses.

Note: The distribution of errors is more important than their total count. If all failures are timeouts, the problem is speed or network overload. If they are connection drops, the proxy may be unstable at the mobile channel level.

Tip: Don't draw conclusions from five requests. The minimum meaningful series is several dozen. For important decisions, use hundreds.

Possible Issues

• All requests fail. Check the login, password, address, and port. One typo breaks everything.
• Some requests hang forever. Always use a timeout, otherwise the series will never finish.
• Error codes fluctuate. The target resource might be unstable itself. Try a different endpoint for control.

✅ Check: You have a count of successful responses, a count of each error type, and an understanding of where the proxy stumbles.

Step 2: Measure Latency and TTFB via Percentiles

Goal of this step: get an honest picture of latency based on distribution, not a misleading average.

Why the Average Is Misleading

Suppose you have ten requests. Nine came back in 100 ms, and one hung for five seconds. The average will be about 600 ms, which is a lie from both sides. In reality, the proxy is almost always fast, but occasionally catastrophically slow. Percentiles show this honestly.

Curl's Output Format with the -w Flag

curl can output detailed timing breakdowns. The -w flag lets you request specific metrics. The most useful variables for us are time_starttransfer – essentially TTFB, time to first byte. Also time_connect – connection setup time, and time_total – total request time.

1. Compose a curl command with the -o flag to discard the response body so it doesn't interfere.
2. Add the -s flag to suppress the progress indicator.
3. Add the -w flag with the required time variables.
4. Run the command in a loop the required number of times through your proxy.
5. Save all TTFB values to a file, one number per line.

How to Calculate Percentiles

Sort the collected numbers in ascending order. The value in the middle of the sorted list is p50. The value at the 95% position of the list length is p95. The value at the 99% position is p99. The Python script at the end of this guide does this automatically.

Tip: Always look at the pair p50 and p95 together. If they are close, the proxy is stable. If there's a chasm between them, the proxy has rare but painful drops.

Possible Issues

• TTFB values suspiciously small. Caching might be at play. Disable connection reuse with a flag that turns off keep-alive, and add a unique parameter to the address.
• Values vary greatly between runs. This is normal for a mobile network. That's exactly why we do series, not single measurements.

✅ Check: You have a file with TTFB values and three percentile numbers that describe the real latency behavior.

Step 3: Measure Throughput Honestly

Goal of this step: find out the actual data transfer speed without self-deception.

How to Measure Honestly

Download a file of known size through the proxy and measure how long it took. Divide the size by the time to get the speed. Sounds simple, but there are nuances easily missed.

1. Choose several files of different sizes from real resources.
2. Download each through the proxy using curl, measuring time with the -w flag and variables time_total and size_download.
3. Repeat the download several times for each file.
4. Calculate the speed for each run and look at the distribution.

Why Multiple Files and Endpoints

One file from one server may be bottlenecked by that server itself, not your proxy. Different sources give different pictures. If speed is consistently low across all sources, the issue is the proxy. If it varies, the bottleneck might be a specific server.

Effect of Tariff Limits

Many mobile plans have speed or data caps. After a certain threshold, speed may drop sharply. Keep this in mind: if you download a lot of data in a row, the slowdown might be a tariff limit, not proxy quality.

⚠️ Attention: Do not download huge amounts of data just for testing if your plan is limited. You risk exhausting your data package. Use files of moderate size.

Tip: Measure throughput at the same time of day as the other metrics. Network congestion heavily affects results.

Possible Issues

• Speed is unstable. This is typical for mobile networks. Look at median speed, not a single best result.
• Speed dropped sharply mid-test. A tariff limit might have kicked in, or the network mode changed.

✅ Check: You have speed values from multiple sources and understand where the bottleneck is.

Step 4: Measure Jitter and Stability

Goal of this step: understand how smoothly the proxy performs, not just how fast.

What We Do

We take the series of latency measurements from previous steps and look at the spread. Jitter is essentially a measure of how much neighboring values differ from each other.

1. Take the file with latency values collected in step 2.
2. Calculate the difference between consecutive measurements.
3. Average the absolute values of these differences – that's an estimate of jitter.
4. Additionally, look at the standard deviation of the entire series.

What Is Considered Normal

There are no universal numbers because normal depends on the task. The general principle: the smaller the jitter relative to the latency itself, the better. If latency is 100 ms and jitter is 5 ms – that's excellent. If jitter is comparable to latency, the work will be jerky.

Tip: Visualize the series of measurements with a simple chart. A flat line is a good sign. A sawtooth with sharp spikes is alarming.

Value Spread

Pay attention to rare outliers. One sharp spike every hundred requests might be tolerable. Regular spikes indicate the proxy is more susceptible to mobile network fluctuations than normal.

✅ Check: You have an estimate of jitter and an understanding of whether the proxy is stable or jumpy.

Step 5: Check Behavior During IP Rotation

Goal of this step: understand how fast and how well the proxy changes its IP address.

What We Measure

Mobile proxies can change IP address on demand or on a schedule. We care about several things: how long the change takes, whether the new address stays in the same network and city, and how many unique addresses appear in an hour.

1. Request the current IP address through an IP check endpoint.
2. Initiate an IP change using the method provided by your provider.
3. Measure the time until the new address becomes available.
4. Request the IP again and record it.
5. Repeat the cycle many times over the course of an hour.
6. Count the number of unique addresses and the time for each change.

How to Evaluate the Result

Look at several parameters. Change speed shows how quickly you get a fresh address. Number of unique addresses per hour indicates the diversity of the pool. Belonging to the same network and city confirms you stay within the expected segment.

Tip: Record not only the address itself but also the network and city data returned by the check endpoint. That way you'll see if geography is stable during changes.

⚠️ Attention: Use IP rotation only for legitimate purposes and within the rules of the services you work with. Technical capabilities of a proxy do not override legal requirements and terms of service.

Possible Issues

• Change takes too long. Check if you're using the correct method. Ask the provider for the standard approach.
• Addresses repeat. Some repetition is possible, but constant duplicates indicate a small pool.

✅ Check: You have the change time, number of unique addresses per hour, and data about their geography.

Step 6: Verify Geography and Connection Type

Goal of this step: ensure the proxy actually matches the claimed characteristics.

What We Check

The provider usually specifies the country, region, and connection type, e.g., mobile network. Our task is to compare the stated and actual data.

1. Access an endpoint through the proxy that returns information about your IP.
2. Record the detected country and region.
3. Record the connection type detected by the service.
4. Repeat the check several times with different IP addresses.
5. Compare the results with what the provider promised.

How to Read the Result

If geography and connection type consistently match what was claimed – excellent. If other regions occasionally appear or the connection type doesn't match, it's worth asking the provider questions.

Tip: Verify geography using several independent geolocation sources. Databases of IP ownership sometimes diverge, and one source might be wrong.

✅ Check: You have confirmed or disproved the match between claimed and actual geography and connection type.

Step 7: Run a 24-Hour Long Test

Goal of this step: see what cannot be observed in five minutes.

Why a 24-Hour Run Is Needed

A short test captures only the current network state. A 24-hour run shows proxy behavior at different times: morning, rush hour, night. You'll see how latency, success rate, and stability change throughout the day.

1. Set up a script to take periodic measurements, e.g., every few minutes.
2. Run it in the background and let it work for 24 hours.
3. Make sure results are written to a file with timestamps.
4. After 24 hours, collect the data and build a picture by the hour.

What a Long Run Reveals

You'll see drops during peak hours when the mobile network is overloaded. You'll notice windows of stability at night. You'll detect rare bursts of errors that simply wouldn't have shown up in five minutes. It's the 24-hour run that separates a good proxy from a mediocre one.

⚠️ Attention: Monitor data usage during a 24-hour run. Make light requests so you don't exhaust your plan's data cap in a day of continuous operation.

Tip: Don't run a 24-hour test on a computer that might go into sleep mode. Disable sleep, otherwise measurements will be interrupted.

✅ Check: You have a 24-hour log with timestamps showing proxy behavior over time.

Ready-Made Scripts for Measurements

Below are templates that calculate the described metrics. Adapt them to your access data and endpoints.

Bash Script

This script makes a series of requests, collects TTFB and response codes, and saves them to a file. The logic: in a loop, curl is executed through the proxy, the -w flag outputs time to first byte and response code, and the result is appended to a log.

Key elements of the script: a variable with the proxy address in the format protocol, login, password, address, and port. A variable with the target endpoint. A loop with a given number of repetitions. Inside the loop, a curl call with flags -s for silence, -o to discard the body, --max-time to limit wait time, and -w with variables time_starttransfer and http_code. Each result line is appended to a text file. After the loop, bash can compute basic statistics or pass the file to Python.

To disable caching, add a unique query parameter to the address and use a flag to disable connection reuse. This ensures each measurement is honest and not pulled from memory.

Python Script

A Python script is more convenient for calculating percentiles and jitter. It reads the values file or makes requests itself using an HTTP library that supports proxies.

The script's logic is as follows. First, set parameters: proxy address, list of endpoints, number of repetitions, and timeout. Then, in a loop, requests are executed; for each, the time to first byte, total time, and response code are recorded. Successful and unsuccessful responses are counted separately. All latency values are stored in a list.

After data collection, the script sorts the latency list and calculates percentiles. The median is taken from the middle of the sorted list. The p95 percentile from the 95% position, and p99 from the 99% position. Jitter is calculated as the average of the absolute differences between consecutive measurements. The success rate is the number of successes divided by the total number of requests.

At the end, the script prints a final report: success rate, latency percentiles, jitter estimate, and error distribution by type. For a 24-hour run, add a timestamp to each record and wrap the measurements in a loop with a pause between series.

Tip: Save raw data, not just summary numbers. If you later need to recalculate a metric differently, you'll have the source.

⚠️ Attention: Store the proxy login and password in a separate configuration file, not directly in the script that you might accidentally show someone.

How to Compile Results into a Single Table

Once you have collected data, it's important to present them visually. A single table allows you to compare providers fairly.

Structure of the Final Table

Create a table where rows are metrics and columns are providers. For each metric, include the value and, where appropriate, percentiles. This way you'll immediately see who is stronger in what.

• Success rate – percentage for each provider.
• TTFB – three numbers: p50, p95, p99.
• Throughput – median speed.
• Jitter – spread estimate.
• IP change – change time and number of unique addresses per hour.
• Geography and connection type – matches claimed or not.
• 24-hour behavior – any drops during peak hours.

Metric Interpretation Table

Below is a verbal table of metric, how it is measured, and what a bad value means. We don't invent specific numbers – norms depend on the task.

• Success rate. Measured by a series of requests and counting successes. Bad value: a noticeable share of errors, especially drops, indicates unreliability.
• TTFB and percentiles. Measured via curl with time to first byte variable on a large series. Bad value: huge gap between p50 and p99, indicating rare but painful drops.
• Throughput. Measured by downloading files of known size. Bad value: speed that doesn't cover your needs or drops sharply.
• Jitter. Measured as the spread of consecutive latencies. Bad value: jitter comparable to latency itself, indicating erratic performance.
• IP change. Measured by a cycle of changes with timing. Bad value: slow change and few unique addresses.
• Geography and connection type. Measured by verifying with a geolocation endpoint. Bad value: mismatch with what was claimed.
• 24-hour stability. Measured by a long run. Bad value: strong drops in metrics during peak hours.

Tip: When comparing, don't make a decision based on one row. Weigh metrics according to what matters most for your specific task. For some, stability is critical; for others, IP rotation speed.

Verification: Quality Measurement Checklist

Before trusting your numbers, go through this list. It ensures your measurements are correct.

• Each metric was measured in a series, not a single request.
• Both providers were tested at the same time of day.
• Same endpoints and timeouts were used.
• For latency, percentiles were calculated, not just the average.
• Caching and connection reuse were disabled where important.
• Testing was done on real targets, not just speed test servers.
• At least one 24-hour run was conducted.
• Raw data were saved for possible recalculation.

✅ Check: If all points are ticked, your results are a reliable basis for decision-making.

Common Measurement Mistakes and Their Solutions

Here are the most frequent pitfalls. Each is described as a problem, cause, and solution.

Mistake One: A Single Run

Problem: conclusion based on one or two requests. Cause: desire to get a number quickly. Solution: always run a series of dozens or hundreds of requests and look at the distribution.

Mistake Two: Testing Only at Peak Hours

Problem: results seem terrible or, conversely, ideal. Cause: measurement taken during peak or minimum network load. Solution: measure at different times and always conduct a 24-hour run.

Mistake Three: Measuring to Speed Test Servers

Problem: numbers look good, but real work is different. Cause: special speed test servers don't reflect real targets. Solution: test on the actual resources you will use.

Mistake Four: Ignoring Cache

Problem: latency suspiciously low and stable. Cause: responses are coming from cache, not the network. Solution: add a unique parameter to the address and disable caching.

Mistake Five: Keep-Alive Skews the Picture

Problem: first request is slow, subsequent ones instant. Cause: connection is reused, and repeated measurements don't include connection setup. Solution: for honest measurement, disable connection reuse if you want to see full latency.

Mistake Six: Comparing Averages Instead of Percentiles

Problem: two proxies seem similar by average, but in practice one is noticeably worse. Cause: average hides drops. Solution: compare p95 and p99.

Mistake Seven: Different Conditions for Different Providers

Problem: comparison is unfair. Cause: one proxy was tested in the afternoon on one endpoint, the other at night on a different one. Solution: strictly adhere to the unified protocol.

Additional Possibilities and Optimization

Once you've mastered the basic methodology, you can go deeper.

Automating Regular Checks

Set up the script to run on a schedule, e.g., daily. This way you'll see if the proxy degrades over time. Accumulate history and look for trends.

Parallel Measurements

Advanced users can run multiple threads simultaneously to evaluate behavior under load. Do this carefully and within the provider's rules.

Data Visualization

Build charts from collected data. A latency vs. time-of-day graph clearly shows peak hours. A histogram of latency distribution shows if there's a long tail of slow responses.

Tip: Even a simple chart in a spreadsheet makes conclusions far more convincing than a column of numbers.

Segmentation by Endpoint

Calculate metrics separately for each endpoint. Sometimes a proxy works great with some targets and worse with others. This detail helps make targeted decisions.

FAQ: Common Questions About Proxy Quality Measurement

How many requests are needed for a reliable result?

The more, the better. A minimum meaningful series is several dozen. For important decisions, use hundreds of requests and always a 24-hour run.

Why can't I trust the advertised speed number?

Because speed is only one of seven metrics. A proxy can be fast but unstable, with poor availability or slow IP rotation. Advertising shows the best case, not the typical one.

What is more important: latency or throughput?

It depends on the task. For fast, lightweight requests, latency and stability are more important. For transferring large volumes, throughput matters more. Look at the whole set of metrics.

Why is the average latency misleading?

Because rare huge values inflate the average, and rare tiny values deflate it. Percentiles p50, p95, and p99 describe the distribution honestly and show how the worst cases behave.

How do I know if a proxy is unstable rather than just slow?

Look at jitter and the gap between percentiles. A slow proxy steadily delivers high but consistent values. An unstable one jumps from excellent to terrible.

Is it necessary to disable caching when measuring?

For honest latency measurement – yes. Otherwise, you measure memory speed, not network speed. Add a unique parameter to the address and disable connection reuse.

Why need a 24-hour run if a five-minute test already showed something?

A five-minute test captures a moment. A 24-hour run shows behavior during peak hours, at night, and in the morning, revealing rare error bursts. Only it separates a reliable proxy from a lucky coincidence.

Can I compare two providers by testing them at different times?

No. The network changes throughout the day, making the comparison unfair. Test both in the same time window under the same protocol.

What should I do if results vary greatly between runs?

This is normal for mobile networks. That's why we rely on series and percentiles, not single measurements. Increase the number of samples.

Do I need to test IP rotation if I don't plan to use it?

If the feature isn't important to you, you can skip this step. But it's quick and useful for a general understanding of the address pool quality.

Conclusion: From Advertising Numbers to Your Own Measurements

You've come from naive belief in a single speed number to a systematic quality evaluation methodology. Now you have seven metrics, a unified protocol, ready-made scripts, and an understanding of how to read results.

What you've mastered. You've learned to measure success rate, latency via percentiles, throughput, jitter, behavior during IP rotation, geography matching, and 24-hour stability. You know why the average lies and why one run proves nothing.

What to do next. Apply the methodology to your current proxy and establish baseline numbers. Then test an alternative provider using the same protocol and compare them in a single table. The decision will become obvious.

Where to go from here. Automate regular checks, accumulate history, and build charts. Over time, you'll notice degradation before it hurts your work. Remember the key: trust not advertising, but your own honest and systematic measurements. That's what distinguishes a confident user from someone who pays blindly.