What to Include in a Proxy Error Report

Give support the failed step and exact error, rather than only “the proxy does not work.” A small report can use this structure:

Client and version:
Proxy protocol and port:
Attempt time and timezone:
Connection / overall timeout settings:
Last completed stage:
Exact error or numeric status:
Same target over an allowed direct route:
Same target through another comparable endpoint:

Describe the stage as proxy connection, proxy authentication, tunnel setup, destination TLS or final HTTP response. For example, “HTTP proxy on port 8080; TCP connected; CONNECT returned 407; no destination TLS yet” identifies the problem without exposing a login. For a certificate error, keep its category and expected-hostname context, redacting private names where needed.

Review the actual text before sharing it. Remove proxy URL userinfo, Proxy-Authorization, destination Authorization, Cookie, Set-Cookie, private query values and request bodies. A session cookie or bearer token can grant access without resembling a password. Tool masking can vary by version and output mode; a verbose log and full trace need not redact alike.

Use markers such as REDACTED_PROXY_PASSWORD while keeping the header names, URL structure and numeric errors visible. Do not delete the entire exchange around a failure. Share private endpoints and network details only in the appropriate support channel.

If a minimal request to a harmless destination or a service you control reproduces the issue, include it instead of a business-data trace. If the error happens only with the original target, say so: changing the target changes what the reproduction establishes. For an HTTP proxy, a bounded curl request can supply a minimal example.