Was in einen Proxy-Fehlerbericht gehört

Nennen Sie dem Support den fehlgeschlagenen Schritt und den genauen Fehler, statt nur „der Proxy funktioniert nicht“. Ein kurzer Bericht kann so aufgebaut sein:

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:

Beschreiben Sie die Phase als Proxyverbindung, Proxyauthentifizierung, Tunnelaufbau, Ziel-TLS oder abschließende HTTP-Antwort. Zum Beispiel grenzt „HTTP-Proxy auf Port 8080; TCP verbunden; CONNECT lieferte 407; noch kein Ziel-TLS“ das Problem ein, ohne Anmeldedaten offenzulegen. Bei einem Zertifikatsfehler behalten Sie Kategorie und Kontext des erwarteten Hostnamens bei; private Namen schwärzen Sie bei Bedarf.

Prüfen Sie den tatsächlichen Text vor dem Teilen. Entfernen Sie userinfo aus der Proxy-URL, Proxy-Authorization, das Authorization des Ziels, Cookie, Set-Cookie, private Abfragewerte und Anfragekörper. Ein Sitzungscookie oder Bearer-Token kann Zugriff gewähren, ohne wie ein Passwort auszusehen. Die Maskierung eines Werkzeugs kann je nach Version und Ausgabemodus abweichen; ausführliches Log und vollständiger Trace müssen nicht gleich schwärzen.

Verwenden Sie Markierungen wie REDACTED_PROXY_PASSWORD und lassen Sie dabei Headernamen, URL-Struktur und numerische Fehler sichtbar. Löschen Sie nicht den gesamten Austausch um einen Fehler herum. Private Endpunkte und Netzwerkdetails teilen Sie nur im geeigneten Supportkanal.

Reproduziert eine minimale Anfrage an ein unbedenkliches Ziel oder einen selbst kontrollierten Dienst das Problem, fügen Sie diese statt eines Traces mit Geschäftsdaten bei. Tritt der Fehler nur beim ursprünglichen Ziel auf, sagen Sie das: Ein anderes Ziel ändert, was die Reproduktion belegt. Für einen HTTP-Proxy kann eine zeitlich begrenzte curl-Anfrage als Minimalbeispiel dienen.