Проверка HTTP-прокси с помощью curl

Проверьте соединение с прокси, HTTPS-туннель, статус ответа и правила обхода с ограниченным по времени тестом curl, не меняя глобальные настройки устройства.

Замените 127.0.0.1:8080 адресом сервиса или конечной точкой из списка HTTP-прокси и выполните эту команду для безвредного HTTPS-ресурса:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Адрес обратной петли обозначает слушающий порт на вашем компьютере. Команда явно выбирает этот прокси, очищает список обхода curl для данного вызова и отводит пять секунд на установление соединения и пятнадцать секунд всего. Настройки прокси браузера и системы она не меняет.

Используйте настоящий исполняемый файл curl, если оболочка назначила curl псевдонимом другой программы; curl --version позволяет определить сборку. Если сам слушающий порт требует TLS, используйте схему URL прокси из его документации.

Читайте четыре результата, а не один признак успеха

  1. Соединение с выбранным прокси: адрес и порт доступны.
  2. CONNECT принят: прокси открыл туннель к HTTPS-ресурсу.
  3. Сертификат целевого сервера проверен: TLS завершён с предусмотренными проверками доверия.
  4. Ответ целевого сервера получен: изучите статус и содержимое, чтобы понять, получен ли результат, нужный приложению.

Даже через работающий туннель целевой сервер может вернуть 403 или 429. curl также может завершиться успешно после получения HTTP-ответа с ошибкой, поэтому записывайте и статус ответа, и результат ошибки curl. Одного TCP-соединения или успешного CONNECT недостаточно.

Краткий результат для повторных сравнений

В Unix-подобной оболочке можно отбросить тело ответа и вывести статус туннеля, статус целевого сервера, адрес другой стороны соединения и затраченное время:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{http_connect} peer=%{remote_ip} total=%{time_total}\n' https://example.com/

http_connect описывает ответ на создание туннеля; http_code — окончательный HTTP-ответ. remote_ip — другая сторона соединения curl, а не независимое измерение выходного адреса прокси. В других системах замените /dev/null или сохраните тело ответа.

Если тест не удался, найдите неудавшийся этап установки соединения или передачи и сравните тот же ресурс с прямым подключением там, где такой маршрут разрешён:

curl --noproxy '*' --connect-timeout 5 --max-time 15 --verbose https://example.com/

--noproxy '*' обходит прокси. Ошибка проверки сертификата на обоих маршрутах указывает на общую проблему доверия; успешное прямое подключение при отклонённом CONNECT — на аутентификацию или политику прокси. Перед передачей подробного вывода другим людям просмотрите его: он может содержать идентифицирующие сведения.

Сохраните конечную точку, цель и временную метку вместе с результатом. Это фиксирует, что сработало для данного запроса; будущая доступность, конфиденциальность и производительность под нагрузкой требуют отдельных подтверждений.

Похожие статьи