O que incluir em um relatório de erro de proxy

Informe ao suporte a etapa que falhou e o erro exato, em vez de dizer apenas “o proxy não funciona”. Um relatório curto pode usar esta estrutura:

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:

Descreva a etapa como conexão ao proxy, autenticação do proxy, criação do túnel, TLS do destino ou resposta HTTP final. Por exemplo, “proxy HTTP na porta 8080; TCP conectado; CONNECT retornou 407; ainda sem TLS do destino” identifica o problema sem expor credenciais. Para um erro de certificado, mantenha a categoria e o contexto do nome de host esperado, ocultando nomes privados quando necessário.

Revise o texto real antes de compartilhar. Remova o userinfo da URL do proxy, Proxy-Authorization, o Authorization do destino, Cookie, Set-Cookie, valores privados de consulta e corpos de requisição. Um cookie de sessão ou token bearer pode dar acesso sem parecer uma senha. O mascaramento das ferramentas varia por versão e modo de saída; um log detalhado e um rastreamento completo podem ocultar informações de maneiras diferentes.

Use marcadores como REDACTED_PROXY_PASSWORD mantendo visíveis nomes de cabeçalhos, estrutura da URL e erros numéricos. Não apague toda a troca de mensagens ao redor da falha. Compartilhe endpoints privados e detalhes de rede apenas no canal de suporte adequado.

Se uma requisição mínima a um destino inofensivo ou serviço que você controla reproduzir o problema, inclua-a em vez de um rastreamento com dados de negócio. Se o erro só acontece com o destino original, diga isso: trocar o destino altera o que a reprodução comprova. Para um proxy HTTP, uma requisição curl com tempo limitado pode fornecer um exemplo mínimo.