Metrics & Request Counting

How Octoprox tracks request metrics, and the important distinction between connection counting and request counting.

Octoprox tracks per-proxy and per-project metrics including request counts, success/failure rates, average latency, and bytes transferred. These metrics are visible in the web UI and available via the API.

How Counting Works

Octoprox counts at the CONNECT tunnel level, not at the individual HTTP request level. When a client opens an HTTPS tunnel via CONNECT, that tunnel is counted as a single request in the metrics — regardless of how many HTTP requests flow through it.

This distinction matters because most HTTP clients use connection pooling (keep-alive). A single CONNECT tunnel can carry dozens or hundreds of sequential HTTP requests without closing the connection.

Example

A client creates one BlockingClient and makes 42 requests to https://httpbin.org/ip through Octoprox. Because the client reuses the same CONNECT tunnel for all 42 requests via keep-alive, Octoprox records:

• request_count: 1 (one CONNECT tunnel was opened)
• Not 42 (the actual number of HTTP requests)

What Is Accurate

While request_count reflects the number of CONNECT tunnels rather than individual HTTP requests, bytes transferred (bytes_sent and bytes_received) are accurately reported. The proxy measures all bytes that flow through the tunnel for its entire lifetime, so the total bandwidth consumed by all HTTP requests within a keep-alive connection is correctly captured.

In the example above, even though request_count shows 1, the bytes_sent and bytes_received values reflect the full payload of all 42 HTTP requests and responses.

Why This Limitation Exists

When HTTPS tunneling is used without TLS interception (MITM disabled), Octoprox creates a raw TCP tunnel between the client and the upstream server. The traffic inside this tunnel is encrypted — the proxy sees only opaque ciphertext and has no way to distinguish where one HTTP request ends and another begins.

This is by design: it preserves the client’s TLS fingerprint (JA3/JA4), which is critical for anti-detection when scraping.

MITM Mode and Accurate Counting

When TLS interception is enabled, Octoprox terminates the client’s TLS session and parses each HTTP request individually using h11. In this mode, the proxy can see individual requests — however, the current metrics implementation still counts at the tunnel level.

Note: Even with MITM enabled, request counting currently reflects tunnel count, not individual HTTP request count. Accurate per-request counting in MITM mode is planned for a future release.

Impact on Other Features

This counting behavior also affects:

• Rate limiting — Rate limits are evaluated per CONNECT tunnel, not per HTTP request within a tunnel. A client sending 100 requests over a single keep-alive connection only triggers one rate limit check.
• Latency tracking — avg_latency_ms reflects the time to establish the CONNECT tunnel to the upstream proxy, not the latency of individual HTTP requests within the tunnel.

Workarounds

If accurate request counting is important for your use case, you have several options:

Disable client-side connection pooling

Configure your HTTP client to not reuse connections. This forces a new CONNECT tunnel per request, making each request individually countable. For example, with the rnet Python library:

from rnet import BlockingClient, Proxy, Impersonate

client = BlockingClient(
    impersonate=Impersonate.Firefox133,
    proxies=[Proxy.all("http://user:pass@proxy:8080")],
    timeout=15,
    pool_max_idle_per_host=0,  # Disable connection reuse
)

This keeps the client object reusable (no need to recreate it per request) while forcing a fresh CONNECT tunnel for each request.

Other HTTP libraries have similar options:

Use the MITM request log

When TLS interception is enabled, Octoprox records each individual HTTP request in the request log (visible in the web UI under the project’s request inspector). This log contains accurate per-request data including method, URL, status code, and latency — even though the top-level metrics count at the tunnel level.

Track requests client-side

If you control the client, maintain your own request counter alongside Octoprox metrics. Use Octoprox metrics for proxy health and bandwidth tracking, and your own counter for request volume.