Before interpreting a 403, 407, 429, or timeout, ask one question: did the client record an HTTP response? The first three are protocol results. A cURL exit 28 or Playwright timeout is a client observation. Those facts point to different layers, and mixing them under one failed label discards the best evidence you have.
A status code is evidence, not attribution.
A response means some HTTP responder wrote back. It does not automatically name that responder. A failure without a status means the client stopped without recording response headers. It does not automatically name the slow or broken hop.
Trace the signal before naming the cause
Use the local decision tree to preserve exactly what you observed. It asks whether a response arrived, which exchange produced it, and what the client reported when no status was available. The result stays deliberately narrower than a root-cause verdict.
Place the first thing you actually observed.
This local classifier separates an HTTP response from a client-side failure before it suggests a layer.
There is not enough evidence to name a failing layer. Layer: Evidence collection. Evidence: insufficient evidence.
There is not enough evidence to name a failing layer.
No HTTP status or normalized client failure has been recorded.
This does not prove
- That the proxy, destination, client, or local network caused the failure.
- That no HTTP response existed. It may simply be absent from the capture.
Capture next
- Record whether an HTTP status appeared at any point.
- Record the client name, normalized error category, and event order.
- Keep a timestamp and a sanitized request label. Omit URLs, IP addresses, and credentials.
Nothing leaves this page. Selections stay in this browser tab and are not saved or sent. Do not paste URLs, IP addresses, headers, or credentials into a diagnostic note.
What each result actually says
403: a responder refused the request
RFC 9110 defines 403 as a response from a server that understood the request and refused to fulfill it. That establishes refusal. It does not identify the origin application, CDN, gateway, or another destination-facing component, and it does not prove bot detection, bad proxy credentials, or a dead proxy.
If cURL response_code or a Playwright Response records 403 after a successful CONNECT, the strongest safe reading is destination-facing HTTP refusal. Preserve the CONNECT code, redirect chain, timestamp, sanitized response fingerprint, client version, and any permitted correlation ID. Use owner or provider logs to go further.
407: a proxy is asking for authentication
RFC 9110 defines 407 as a proxy-authentication challenge. A conforming response includes Proxy-Authenticate. This is the clearest proxy-layer signal in this group, but it still does not prove that the password alone is wrong. Credentials may be absent, rejected, expired, incomplete, or offered with an unsupported scheme.
Record the challenge scheme and realm, proxy endpoint alias, proxy scheme, CONNECT code, and whether credentials were configured. Never record the raw credentials in your evidence row.