Qué incluir en un informe de error de proxy

Proporciona al soporte el paso que falló y el error exacto, en vez de decir solo «el proxy no funciona». Un informe breve puede usar esta estructura:

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 la etapa como conexión al proxy, autenticación del proxy, establecimiento del túnel, TLS del destino o respuesta HTTP final. Por ejemplo, «proxy HTTP en puerto 8080; TCP conectado; CONNECT devolvió 407; aún sin TLS del destino» identifica el problema sin revelar credenciales. Para un error de certificado, conserva la categoría y el contexto del nombre de host esperado, ocultando nombres privados cuando haga falta.

Revisa el texto real antes de compartirlo. Elimina el userinfo de la URL del proxy, Proxy-Authorization, el Authorization del destino, Cookie, Set-Cookie, valores privados de consulta y cuerpos de solicitud. Una cookie de sesión o un token bearer puede conceder acceso sin parecer una contraseña. El enmascaramiento de las herramientas varía según la versión y el modo de salida; un registro detallado y una traza completa no tienen por qué ocultar lo mismo.

Usa marcadores como REDACTED_PROXY_PASSWORD y mantén visibles los nombres de cabecera, la estructura de la URL y los errores numéricos. No borres todo el intercambio que rodea el fallo. Comparte puntos de acceso privados y detalles de red solo en el canal de soporte adecuado.

Si una solicitud mínima a un destino inocuo o un servicio que controlas reproduce el problema, inclúyela en vez de una traza con datos empresariales. Si el error ocurre solo con el destino original, indícalo: cambiar el destino cambia lo que demuestra la reproducción. Para un proxy HTTP, una solicitud curl con tiempo acotado puede servir como ejemplo mínimo.