A proxy success rate is legible only with its unit, numerator, denominator, validator, retry policy, and taxonomy version. Change one of those and the number can move while every raw network event stays exactly the same.
Two honest proxy tests can disagree because they are not answering the same question.
Six ways the reported rate changes
1. Request, attempt, or job
A browser job can produce one main-document request, dozens of subresource requests, and more than one physical attempt. “95 successful requests out of 100” is not comparable to “95 completed jobs out of 100.” Pick the operational unit first. Keep job_id, attempt_id, and request role separate so more than one valid view can be calculated later.
2. First attempt or final retry result
A job that fails once and passes on retry is a completed job and a failed first attempt. Job completion tells you whether the system eventually delivered. First-attempt success tells you how much retry budget, time, and traffic it needed. Publishing only the final job result hides that cost. Retries also share route, pool, session, destination, and time-window state, so do not assume they are independent samples.
3. Transport, HTTP, or workload success
For HTTPS through an HTTP proxy, a successful CONNECT means the proxy formed a tunnel. It does not mean the page loaded. RFC 9110 is precise about that boundary. A requested-transfer 2xx means the client received a successful-class HTTP response after tunnel setup. It does not prove which intermediary generated it or that the payload satisfied the task. A 200 can still carry the wrong regional variant, a maintenance document, incomplete data, or a response that fails the declared validator.
Client defaults add another split. On a completed requested transfer, cURL can exit 0 for a 4xx or 5xx unless options such as --fail change status handling. Playwright's page.goto() does not throw merely because a valid response is 404 or 500, while requestfailed is for a request where the browser did not obtain an HTTP response. Transport completion, status, and workload validation belong in separate columns.
4. Started attempts or post-hoc eligible attempts
Removing timeouts, authentication failures, unfinished work, or unsupported scenarios after seeing the result usually raises the percentage. A genuine fixture or harness fault can be excluded, but the rule should exist before the run and the count and reason should be published. Preserve every started attempt in the raw log; a later report can mark a predeclared exclusion without erasing the event.