Co zamieścić w raporcie błędu proxy

Podaj wsparciu etap niepowodzenia i dokładny błąd, zamiast tylko „proxy nie działa”. Krótki raport może mieć taką 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:

Opisz etap jako połączenie z proxy, uwierzytelnienie proxy, zestawianie tunelu, TLS celu lub końcową odpowiedź HTTP. Na przykład „proxy HTTP na porcie 8080; TCP połączone; CONNECT zwrócił 407; TLS celu jeszcze nie było” wskazuje problem bez ujawniania danych logowania. Dla błędu certyfikatu zachowaj kategorię i kontekst oczekiwanej nazwy hosta, ukrywając prywatne nazwy w razie potrzeby.

Przed udostępnieniem przejrzyj rzeczywisty tekst. Usuń userinfo z URL proxy, Proxy-Authorization, Authorization celu, Cookie, Set-Cookie, prywatne wartości zapytań i treści żądań. Ciasteczko sesji lub token bearer może dawać dostęp, nie przypominając hasła. Maskowanie narzędzia może zależeć od wersji i trybu wyjścia; szczegółowy log i pełny ślad nie muszą maskować jednakowo.

Używaj oznaczeń takich jak REDACTED_PROXY_PASSWORD, pozostawiając widoczne nazwy nagłówków, strukturę URL i błędy liczbowe. Nie usuwaj całej wymiany wokół awarii. Prywatne punkty końcowe i szczegóły sieci udostępniaj tylko w odpowiednim kanale wsparcia.

Jeśli minimalne żądanie do nieszkodliwego celu lub kontrolowanej usługi odtwarza problem, dołącz je zamiast śladu z danymi biznesowymi. Jeśli błąd występuje tylko dla oryginalnego celu, powiedz o tym: zmiana celu zmienia to, co wykazuje reprodukcja. Dla proxy HTTP żądanie curl z limitem czasu może być minimalnym przykładem.