In a first-party observation on 11 October 2026, Mexela checked five dedicated test proxy routes against its own HTTPS checker. 98 of 100 proxied requests met the route-and-response contract; all 20 direct controls passed. This case study reports actual median and p95 request durations, keeps the failed attempts, and provides a reproducible sanitized record.
The question and observation window
Would each configured route return a fresh, valid response with the expected source-address relationship, and what total request duration would the client observe? The run began at 2026-10-11T19:21:17+00:00 and ended at 2026-10-11T19:33:07+00:00, lasting 710.364 seconds, approximately 11.84 minutes. These are UTC timestamps.
This was an internal operations test using five explicitly authorized dedicated test assignments, not customer sessions or a customer testimonial. The client was PHP 7.0.33 with libcurl 7.47.0 on Linux. Physical client and exit locations were not measured. Route labels intentionally replace endpoint identities.
The route being observed
Method and qualification
- Run a new direct control before each round against
https://mexela.com/proxy-checker/?format=json. - Issue one authenticated request per configured HTTP proxy, sequentially in fixed route order. Repeat for 20 rounds with a 30-second pause between rounds.
- Use fresh connections, a five-second connection budget and a ten-second total budget. Keep certificate and hostname verification enabled; follow no redirects and persist no cookies.
- Qualify a request only when it returns HTTP 200 without a transport error, passes destination TLS verification and returns a valid source address with a checker timestamp within 60 seconds. For a proxy route, the connected peer and observed exit must match the configured assignment and the exit must differ from that round’s direct control.
- Retain every attempted duration and error. Summarize qualified successful total times separately; keep unsuccessful attempts in the failure denominator.
total_ms is libcurl’s elapsed time for the completed or failed operation, converted from seconds to milliseconds. It includes work such as connection setup, the tunnel, destination TLS and response transfer; it is not pure proxy-processing delay. TTFB and connection timing observations remain in the dataset. libcurl documentation explains total transfer timing and error codes.
Measured request results
| Route | Qualified / attempted | Failed attempts | Median total ms | p95 total ms |
|---|---|---|---|---|
| Direct control | 20 / 20 | 0 | 48.891 | 63.521 |
| route-1 | 18 / 20 | 2 | 2304.226 | 3393.998 |
| route-2 | 20 / 20 | 0 | 1070.812 | 1133.484 |
| route-3 | 20 / 20 | 0 | 1080.577 | 1118.647 |
| route-4 | 20 / 20 | 0 | 1076.534 | 1127.520 |
| route-5 | 20 / 20 | 0 | 1076.633 | 1139.661 |
The median averages the two middle observations for an even sample count. p95 uses nearest rank ceil(0.95 × n). Values shown are rounded to three decimal places. With only 20 attempts per route, the upper-tail estimate is coarse; repeated windows are needed to characterize a distribution.
Failed attempts remain visible
- route-1, round 7: HTTP 0, libcurl error 56, attempted duration 4999.008 ms. The attempt remains in the raw record and failure count.
- route-1, round 8: HTTP 0, libcurl error 28, attempted duration 5001.433 ms. The attempt remains in the raw record and failure count.
Failed durations remain in the sanitized samples, but are excluded from the successful-latency distribution. Error 28 identifies a timeout; error 56 identifies a receive failure. Neither result had an HTTP response status, so neither is reported as a confirmed authentication rejection. The available fields do not establish the sole underlying cause. A later successful sample does not erase an earlier failure.
How to use these results
The direct control helps show that the owned destination was responding during each round. In this run, one route had a slower successful distribution and two unsuccessful attempts, while the other four qualified in all 20 rounds. This supports investigating that route from the measured client and target. It does not rank all proxy products or compare applications run at different times.
The correct operational next step is to preserve the failing samples, reproduce the relevant layer with the same authorized assignment, and compare the application requirement with the recorded behavior. Use the layered troubleshooting guide and the checker field interpretation guide.
Download and reproduce
- Download all sanitized observation rows as JSON.
- Download the PHP runner, observation record and reproduction notes.
- Download the original request-path diagram.
The runner accepts private configuration only through standard input, permits this owned target only, bounds routes/rounds/pauses, and rejects nonpublic proxy addresses. Supply your own authorized test assignments privately. Do not put credentials into shell history, command-line arguments, screenshots or public reports.
What the window establishes
This is sampled stability, not continuous uptime. Gaps between checks can hide failures. Fixed route order and one client/target confound any causal comparison; the run did not test throughput, sessions, client geography, exit geography, DNS leaks, anonymity, third-party acceptance or future availability. It is not an SLA or a service-wide reliability percentage.
The observations are a dated first-party engineering case. They do not contain customer identities, credential values, endpoint identities or response bodies. For the broader review process, see how Mexela tests proxy guides. For capacity planning, compare the required access, protocol, location and continuity with current proxy plans, then confirm inventory and test the intended workload.
Download the CSV and reproduce the analysis
Download the 120-attempt benchmark CSV and offline Python analysis notebook. Save both in the same folder and run the notebook there. A notebook environment such as Jupyter opens the notebook; its analysis uses only Python’s standard library, with no network access, credentials or package installs.
The original 11 October 2026 UTC observations and limitations apply. The CSV retains 20 direct controls, 98 qualified proxy checks and two failures. Literal null values remain distinct from false and 0. Median and coarse nearest-rank p95 use qualified samples only; all attempts remain in success/failure denominators. The notebook verifies the CSV SHA-256 and can optionally write a standalone SVG. Original copyright and attribution terms are retained.
This short example reads the same local CSV and prints each route’s qualified count, failed count and median total time:
import csv
import statistics
with open('mexela-proxy-route-observations-20261011.csv', newline='', encoding='utf-8') as file:
rows = list(csv.DictReader(file))
for route in ('direct', 'route-1', 'route-2', 'route-3', 'route-4', 'route-5'):
attempts = [row for row in rows if row['route'] == route]
times = [float(row['total_ms']) for row in attempts if row['qualified'] == 'true']
print(f'{route}: {len(times)}/{len(attempts)} qualified, '
f'{len(attempts) - len(times)} failed, median {statistics.median(times):.4f} ms')
Observation data license: The sanitized JSON and CSV observation data are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Credit Mexela, link to this study and the license, and indicate any changes. This license applies only to the observation data; it does not cover the article text, code, diagrams or other resources.
