Что включить в отчёт об ошибке прокси

Сообщите поддержке этап сбоя и точную ошибку, а не только «прокси не работает». Короткий отчёт можно построить так:

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, частные значения параметров и тела запросов. Сеансовый cookie или bearer-токен может давать доступ, не будучи похожим на пароль. Маскирование инструментов зависит от версии и режима вывода; подробный журнал и полная трассировка не обязаны скрывать данные одинаково.

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

Если минимальный запрос к безобидной цели или подконтрольному вам сервису воспроизводит проблему, приложите его вместо трассировки с рабочими данными. Если ошибка возникает только с исходной целью, скажите об этом: смена цели меняет то, что доказывает воспроизведение. Для HTTP-прокси запрос curl с ограниченным временем может стать минимальным примером.