Dedicated proxy HTTPS checks: October 2026 results

12 October follow-up: latency and simultaneous connections

On 12 October 2026, between 08:03:59 and 08:06:53 UTC, we made 90 additional HTTPS HEAD requests through the same three reserved Dedicated test proxies. This is a separate follow-up; it does not replace or add observations to the 5–7 October study above.

We tested a global limit of one, two and four active requests. Only one proxy was tested at a time: four means up to four connections through that proxy, with no simultaneous tests on the other two proxies. Each level includes two rounds of the same five destinations for each of three proxies, giving 30 attempts per level. Each request used a separate cURL process and a fresh connection.

The timing medians use successful HTTP 2xx requests with cURL exit code zero. Errors and non-2xx responses remain in the attempt counts and downloads. TCP connect measures time from the start of a request to the connection to the HTTP proxy. Time to first byte (TTFB) and total time include the proxy tunnel, destination TLS, destination processing and network travel; these are not proxy-only latency figures.

Reproducible settings

The client was curl 8.21.0 (Windows) libcurl/8.21.0 Schannel zlib/1.3.2 WinIDN WinLDAP, with Python 3.12.10 on Windows. We used HEAD over HTTP/1.1, destination TLS verification, six-second connection and total timeouts, no redirects and no retries. The response body was not downloaded. A 1 MiB file-size safeguard was configured. The five fixed targets and anonymous aliases retain the D01–D05 and T01–T03 mappings above.

For each proxy, run levels 1, 2 and 4 in that order. At each level, schedule the five target requests with a worker pool limited to that level, wait for all five to finish, pause two seconds and repeat once. Pause ten seconds before the next level or proxy. Connections are not reused between requests. This produces 90 attempts and never multiplies the concurrency level by the number of proxies.

To repeat the full matrix on Windows with Python 3 and cURL 8.4 or newer, download the reproducible study runner. Run python -B reproduce-https-concurrency.py to inspect the offline plan. In a fresh folder, run python -B reproduce-https-concurrency.py --execute and enter only your own authorized test access in the hidden prompts. The runner writes anonymous measurements locally and refuses to overwrite a previous attempt. No credentials are passed on the cURL command line or written to the result file.

The following cURL configuration template makes one request through standard input. Keep real credentials out of shared scripts, shell history and saved results.

curl.exe --disable --config -
# Supply this configuration on standard input, replacing placeholders:
url = "https://www.ripe.net/"
proxy = "http://PROXY_HOST:PROXY_PORT"
proxy-user = "PROXY_USERNAME:PROXY_PASSWORD"
proxy-basic
noproxy = ""
head
http1.1
silent
connect-timeout = 6
max-time = 6
max-redirs = 0
max-filesize = 1048576
proto = "=https"
proto-redir = "=https"
output = "NUL"
write-out = "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} http=%{http_code} tunnel=%{http_connect} exit=%{exitcode}"

The established-connection peaks were independently sampled from the Windows IPv4 TCP table approximately every 20 milliseconds, filtering by each cURL process and its proxy endpoint. Private addresses were matched only in memory. A sampled peak confirms connections seen during that round; brief peaks can be missed, and this does not establish the maximum connection limit of a service.

What this follow-up can tell you

These figures describe three reserved proxies, five destinations and one short Windows session. The level order was fixed rather than randomized. Destination load, network paths, caching and timing can change the results, so differences between levels do not isolate a causal effect of concurrency. We did not measure throughput, continuous uptime, browser sessions, logins or a maximum capacity limit, and the sample cannot establish performance across the whole proxy pool or rank Dedicated against Semi-Dedicated.

Download the anonymous follow-up CSV (90 observations) or download the JSON with the test matrix and connection-count receipts. Timing definitions follow the official cURL documentation.

Controlled static GET check: 13 October 2026

Between 16:01:50 UTC and 16:03:01 UTC on 13 October 2026, we made six direct GET requests and 60 GET requests through the same three previously reserved test proxies. Each request fetched our own versioned compatibility JSON (10,227 bytes). All 66 attempts returned HTTP 200, verified destination TLS and the exact pinned body hash. The 60 proxy attempts also returned CONNECT 200. There were zero failed responses, retries or followed redirects in this session.

Method and response consistency

The client was Python 3.12.10 and cURL 8.21.0 with Schannel on one Windows computer. We used HTTP/1.1 GET through authenticated HTTP proxies, six-second connection and total timeouts, destination TLS verification and a 64 KiB transfer bound. Each request used a fresh cURL process and connection. The target’s SHA-256 was verified against its native static file before traffic and checked on every response.

For each proxy, limits 1, 2 and 4 ran in that fixed order. Each level had two rounds, with three requests per round at limits 1 and 2 and four at limit 4. The limit applied globally while testing one proxy at a time. One second separated rounds and five seconds separated cells. A Windows TCP-table observer sampled approximately every 10 milliseconds; both rounds for all three proxies showed established-connection peaks of 1, 2 and 4 at the corresponding levels, with zero observer errors.

All repeated requests matched the same expected content during this short session. This is a response-consistency observation; it does not establish continuous uptime or long-term stability. Total time includes the connection, proxy tunnel, destination TLS, routing, destination/CDN processing and body transfer. It is not a measurement of proxy-only latency.

How to read these numbers

The direct baseline ran first, and proxy and level order were fixed. Requests to one static URL can benefit from caches. Those differences, the small sample and changing network conditions prevent a causal conclusion about concurrency from the median changes. P95 uses the nearest-rank sample value, ceil(0.95 × n), calculated only from qualified responses; with six or 18 observations it equals the observed maximum and is not a robust estimate of a population tail.

This check covers three reserved proxies, one owned target and one origin. It does not measure SOCKS, verified exit locations, other destinations, throughput, browser sessions, maximum service capacity, whole-pool performance, product comparisons or long-term reliability. Sampled TCP peaks may miss brief connections.

Download the anonymous JSON with all 66 observations and round receipts, the CSV or the results and standalone reproducer ZIP. In a fresh folder, run the supplied reproducer without arguments to inspect its offline plan. Add --execute only with your own authorized test access, entered in hidden prompts. The Windows runner caps traffic at 66 GETs and four active requests, writes anonymous results locally, and refuses to replay an existing attempt. Timing definitions follow the official cURL documentation.

Summary, graph and citation

This completed one-day session contains 66 qualified responses: six direct and 60 proxied GETs through three reserved HTTP proxies to one owned static target. It lasted approximately 71 seconds on 13 October 2026. The chart reports total request time, including connection setup, CONNECT, destination TLS and body transfer; it is not proxy-only latency. Small samples, fixed request ordering and uncontrolled caches prevent a causal concurrency comparison or a whole-pool performance claim.

To reference these observations, identify the date, dataset version and exact measured scope. Keep the study limitations with any reproduced chart. This citation refers to the completed 13 October session only; the separate seven-day follow-up below now reports its final observations and two missed windows.

BuyProxies (2026). Controlled static GET check: 13 October 2026. Dataset version 2026-10-13. https://buyproxies.org/dedicated-proxy-https-check-october-2026#bp-study-static-get-20261013 (accessed 14 October 2026).

Download the citation and scope as plain text. The anonymous source dataset is versioned 2026-10-13; its SHA-256 is a65a096f726293ab2a55924dfd6de31a957dee14ba8d3c2a40198dcaab121aac. The CSV and ZIP downloads immediately above retain the same observations.

Seven-day follow-up: final observations, 13–19 October 2026

The observation period has ended. Five of seven scheduled days were measured; the 14 and 19 October windows were missed and have no observations. We did not backfill, retry or extend the study. Day one adopts the original verified 13 October session rather than adding another run.

Across the five measured windows, 30 direct GETs and 300 proxied GETs were recorded. All 330 returned HTTP 200, passed destination TLS verification, and matched the expected SHA-256 and 10,227-byte body. All 300 proxied attempts also returned CONNECT 200. Zero failed attempts were recorded within those measured windows. Missing windows remain missing; these results do not describe the intervening hours.

The method used the same three reserved test proxies, one Windows computer and the same owned static compatibility JSON. Each measured day was capped at 66 GETs and four active requests globally: six direct controls followed by 60 proxied requests, fixed proxy and concurrency-level order, HTTP/1.1 through HTTP CONNECT, fresh cURL processes, six-second deadlines, verified TLS, no redirects or retries, and a 64 KiB response bound.

The following timings describe qualified responses in each individual window. Values are milliseconds for total request time; p95 uses nearest rank, ceil(0.95 × n). Proxy limits 1, 2 and 4 are configured concurrency caps, not measures of capacity. We do not pool or average the daily p95 values.

Anonymous, immutable daily evidence: JSON daily aggregate (SHA-256 c46ad690b003ea12127c3d8d63abab163b5ffff6091ad5ea091cf726a49ec561); CSV daily aggregate (SHA-256 ba4ed9f396b0b51aedead048b21616409b27e830b370ee8c0f337b6e765352a3). Files contain the observed counts, failures and missing days; they contain no proxy endpoints or credentials.

This small sample can describe response consistency during these short windows. It cannot establish continuous uptime, whole-pool performance, throughput, maximum capacity or a causal effect of concurrency. Direct controls ran first; proxy and level order were fixed; caches and external network conditions were uncontrolled. A missing window provides no evidence of either success or failure.