Що включити до звіту про помилку проксі

Повідомте підтримці етап збою й точну помилку, а не лише «проксі не працює». Короткий звіт може мати таку структуру:

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 з обмеженим часом може бути мінімальним прикладом.