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

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

Падобныя артыкулы