Proxy Route Timing: A Measured Mexela Case Study

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

Direct HTTPS compared with validated destination TLS through an HTTP proxy CONNECT tunnel
Original Mexela request-path diagram. HTTP CONNECT establishes the tunnel before the client negotiates destination TLS; the HTTP proxy connection itself is not a separately encrypted HTTPS proxy hop.

Method and qualification

  1. Run a new direct control before each round against https://mexela.com/proxy-checker/?format=json.
  2. Issue one authenticated request per configured HTTP proxy, sequentially in fixed route order. Repeat for 20 rounds with a 30-second pause between rounds.
  3. 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.
  4. 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.
  5. 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

Per-route observations; timing columns use only qualified successful samples.
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

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')

Seven-day follow-up: hourly observations, 16–23 October 2026 UTC

A separate seven-day observation window was collected using the same five human-authorized dedicated test assignments and one owned HTTPS checker destination. The collector schedules one direct control followed by at most five sequential route requests in each hourly slot. Connections are fresh, redirects are disabled and destination TLS validation stays enabled.

The window contains 168 planned hourly slots and has a fixed expiry. Each slot can be attempted once. A failed direct control is retained, and its proxy requests are marked not executed; a missing or interrupted slot is not filled with a fabricated result. Successful timing samples and failed attempts remain separate in the final dataset.

The completed seven-day results were published on 25 October 2026. Read the final hourly observations and download the sanitized JSON/CSV. Hourly observations do not establish continuous uptime, a country, anonymity, throughput or a guarantee for every package. The original short-window study and its failures above remain unchanged.

Seven-day hourly observations: 16–23 October 2026

Published 25 October 2026. The observation window ran from 16 October 2026, 15:58 UTC to 23 October 2026, 15:58 UTC. All 168 planned hourly slots have recorded observations; no slots are missing or interrupted. The data contains 1,008 attempted requests: 168 direct controls and 168 attempts for each of five dedicated test assignments.

This is hourly sampling from one client host to one Mexela-owned HTTPS checker, not continuous uptime monitoring. The route labels are pseudonymous; the observations do not establish geography, throughput, anonymity, performance on other destinations or results for customer assignments.

Actual attempts and successful-request timing, in milliseconds
Path Attempts Qualified successes Failures Success median (ms) Success p95 (ms)
Direct control 168 168 0 199.162 277.536
route-1 168 136 32 2515.686 5437.158
route-2 168 168 0 1097.850 1200.236
route-3 168 168 0 1095.318 1214.374
route-4 168 168 0 1091.244 1223.229
route-5 168 168 0 1090.706 1220.854

Route-1 retained 32 unsuccessful attempts: 18 cURL connection failures (error 7), 9 timeouts (error 28) and 5 receive errors (error 56), all with HTTP status 0. Its qualified-success fraction was 136/168 (80.95%). These unsuccessful attempts remain in the denominator and in the downloads. The other four assignments and the direct control each had 168 qualified successes in these recorded attempts; that is not an availability guarantee.

A qualified success requires HTTP 200, no cURL error, verified destination TLS, a fresh checker timestamp and, for a proxy route, matching configured peer/exit checks and an exit distinct from the direct control. A failed control would skip the five proxy requests rather than manufacture failures; this completed window had no failed controls or skipped route requests. Median and nearest-rank p95 use qualified-success timings only, so they must not be read as failure-inclusive response-time percentiles.

Summary statistics were independently recomputed from the recorded rows. Comparison of the derived median and success fraction accounts only for the observed fourteen-significant-digit PHP7 JSON serialization; counts, status/error totals, p95, timestamps, coverage and qualification checks remain exact. The original native journals were not changed.

The downloads include only slot, pseudonymous path, timestamps, HTTP/cURL outcome, qualification and total time, plus aggregate coverage/statistics in JSON. They contain no proxy endpoints, credentials or customer data. This dated follow-up supplements the earlier short-window observations above; it does not demonstrate an SEO, conversion or ranking effect.