Dálle ao soporte o paso que fallou e o erro exacto, en vez de dicir só «o proxy non funciona». Un informe breve pode seguir 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:

Describe a fase como conexión ao proxy, autenticación do proxy, establecemento do túnel, TLS do destino ou resposta HTTP final. Por exemplo, «proxy HTTP no porto 8080; TCP conectado; CONNECT devolveu 407; aínda sen TLS do destino» identifica o problema sen revelar credenciais. Para un erro de certificado, conserva a categoría e o contexto do nome de host esperado, ocultando nomes privados cando faga falta.

Revisa o texto real antes de compartilo. Elimina o userinfo do URL do proxy, Proxy-Authorization, o Authorization do destino, Cookie, Set-Cookie, valores privados da consulta e corpos das peticións. Unha cookie de sesión ou token bearer pode dar acceso sen parecer un contrasinal. O enmascaramento das ferramentas varía coa versión e o modo de saída; un rexistro detallado e unha traza completa non teñen por que ocultar igual.

Usa marcadores como REDACTED_PROXY_PASSWORD mantendo visibles os nomes das cabeceiras, a estrutura do URL e os erros numéricos. Non borres todo o intercambio arredor do fallo. Comparte puntos de acceso privados e detalles de rede só na canle de soporte apropiada.

Se unha petición mínima a un destino inocuo ou servizo que controlas reproduce o problema, inclúea no canto dunha traza con datos de negocio. Se o erro só ocorre co destino orixinal, indícao: cambiar o destino modifica o que demostra a reprodución. Para un proxy HTTP, unha petición curl con tempo limitado pode dar un exemplo mínimo.

Artigos relacionados