Огляд тіла невдалої відповіді 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. Зберігайте статус і тіло діагностики разом з їхнім конкретним проксі та ціллю.

Схожі статті