Агляд цела адказу няўдалага proxy CONNECT з дапамогай curl

Адпраўце карэктна сфарміраваны дыягнастычны CONNECT непасрэдна на HTTP-проксі і захавайце загалоўкі і цела памылкі HTTP асобна.

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

curl --proxy '' --http1.1 --max-time 10 \
  --request CONNECT \
  --request-target service.example:443 \
  --header 'Host: service.example:443' \
  --dump-header tunnel.headers \
  --output tunnel.body \
  http://proxy.example:8080/

Канчатковы URL адрасуе слухач проксі. Для дазволенага параўнання публічных проксі спіс HTTP-проксі дае кандыдатаў для гэтага URL слухача. --request падае токен метаду; --request-target падае паўнамоцтвы CONNECT. Іх падзел дае CONNECT service.example:443 HTTP/1.1.

Пустая опцыя проксі перашкаджае curl накіроўваць гэтую дыягностыку праз іншы ўспадкаваны проксі. Каманда наўмысна не ўжывае --fail, каб HTTP-дакумент памылкі захаваўся.

Спроба без аўтэнтыфікацыі можа спыніцца на 407, не дайшоўшы да збою, які даследуецца. Выкарыстоўвайце належную схему аўтэнтыфікацыі проксі, калі ўзнаўляеце аўтэнтыфікаваны запыт.

Гэта для агляду адказаў з памылкамі. Калі проксі вяртае 2xx, злучэнне становіцца тунелем, а не звычайнай перадачай цела HTTP. Гэтая дыягностыка з уласным метадам не пачынае TLS-абмен пункта прызначэння і можа дасягнуць свайго ліміту часу на прынятым адкрытым тунелі.

Для фактычнага HTTPS-запыту выкарыстоўвайце звычайны паток запыту --proxy. Захоўвайце статус і цела дыягностыкі разам з іх канкрэтным проксі і мэтай.

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