Изучение тела неудачного ответа CONNECT прокси с помощью curl

Прокси, отклоняющий 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. Сохраняйте статус и тело диагностики вместе с их конкретным прокси и целью.