Какво да включите в доклад за грешка на прокси

Дайте на поддръжката неуспешната стъпка и точната грешка, а не само „проксито не работи“. Кратък доклад може да следва тази структура:

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:

Опишете етапа като свързване с проксито, удостоверяване, установяване на тунел, TLS на целта или окончателен HTTP отговор. Например „HTTP прокси на порт 8080; TCP свързан; CONNECT върна 407; още няма TLS на целта“ посочва проблема, без да разкрива данни за вход. За грешка в сертификат запазете категорията и контекста на очакваното име на хост, скривайки лични имена при нужда.

Прегледайте действителния текст преди споделяне. Премахнете userinfo от прокси URL, Proxy-Authorization, Authorization на целта, Cookie, Set-Cookie, лични стойности на параметри и тела на заявки. Сесийна бисквитка или bearer токен може да дава достъп, без да прилича на парола. Маскирането на инструментите зависи от версията и режима на извеждане; подробен журнал и пълна трасировка не непременно скриват по един начин.

Използвайте маркери като REDACTED_PROXY_PASSWORD, като оставяте видими имената на заглавките, структурата на URL и числовите грешки. Не изтривайте целия обмен около грешката. Споделяйте частни крайни точки и мрежови подробности само в подходящия канал за поддръжка.

Ако минимална заявка към безобидна цел или услуга под ваш контрол възпроизвежда проблема, приложете нея вместо трасировка с бизнес данни. Ако грешката е само при първоначалната цел, кажете го: промяната на целта променя какво доказва възпроизвеждането. За HTTP прокси curl заявка с ограничено време може да бъде минимален пример.