Vad en proxyfelrapport bör innehålla

Ge support det misslyckade steget och det exakta felet, inte bara ”proxyn fungerar inte”. En kort rapport kan använda den här strukturen:

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 steget som proxyanslutning, proxyautentisering, tunnelupprättande, destinationens TLS eller slutligt HTTP-svar. Till exempel visar ”HTTP-proxy på port 8080; TCP ansluten; CONNECT returnerade 407; ännu ingen destinations-TLS” problemet utan att avslöja inloggning. Vid ett certifikatfel behåller du kategorin och sammanhanget för det förväntade värdnamnet och döljer privata namn vid behov.

Granska den faktiska texten före delning. Ta bort proxy-URL:ens userinfo, Proxy-Authorization, destinationens Authorization, Cookie, Set-Cookie, privata frågevärden och förfrågningskroppar. En sessionscookie eller bearer-token kan ge tillgång utan att likna ett lösenord. Verktygets maskering kan variera med version och utmatningsläge; en detaljerad logg och en fullständig spårning behöver inte dölja likadant.

Använd markörer som REDACTED_PROXY_PASSWORD men låt headernamn, URL-struktur och numeriska fel vara synliga. Radera inte hela utbytet runt felet. Dela privata ändpunkter och nätverksdetaljer bara i lämplig supportkanal.

Om en minimal förfrågan till en harmlös destination eller en tjänst du kontrollerar återskapar problemet, bifoga den i stället för en spårning med affärsdata. Om felet bara sker med ursprungsmålet, säg det: ett annat mål ändrar vad reproduktionen fastställer. För en HTTP-proxy kan en tidsbegränsad curl-förfrågan ge ett minimalt exempel.