Hvad en proxyfejlrapport bør indeholde

Giv support det fejlede trin og den præcise fejl frem for blot „proxyen virker ikke“. En kort rapport kan bruge denne struktur:

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:

Beskriv stadiet som proxyforbindelse, proxygodkendelse, tunneloprettelse, destinationens TLS eller endeligt HTTP-svar. Eksempelvis viser „HTTP-proxy på port 8080; TCP forbundet; CONNECT returnerede 407; endnu ingen destination-TLS“ problemet uden at afsløre loginoplysninger. Ved en certifikatfejl bevares kategorien og konteksten for det forventede værtsnavn, mens private navne skjules efter behov.

Gennemgå den faktiske tekst før deling. Fjern proxy-URL’ens userinfo, Proxy-Authorization, destinationens Authorization, Cookie, Set-Cookie, private forespørgselsværdier og indholdet af forespørgsler. En sessionscookie eller bearer-token kan give adgang uden at ligne en adgangskode. Værktøjets maskering kan variere efter version og outputtilstand; en detaljeret log og et fuldt spor behøver ikke at skjule ens.

Brug markører som REDACTED_PROXY_PASSWORD, mens headernavne, URL-struktur og numeriske fejl fortsat er synlige. Slet ikke hele udvekslingen omkring fejlen. Del kun private endepunkter og netværksdetaljer i den passende supportkanal.

Hvis en minimal forespørgsel til en harmløs destination eller en tjeneste, du styrer, genskaber problemet, så vedlæg den frem for et spor med forretningsdata. Hvis fejlen kun opstår med det oprindelige mål, så sig det: et andet mål ændrer, hvad reproduktionen fastslår. For en HTTP-proxy kan en tidsbegrænset curl-forespørgsel give et minimalt eksempel.