Как проверить влияние http_proxy, HTTPS_PROXY и NO_PROXY на curl

Если curl не открывает сайт, хотя браузер работает, сначала проверьте, куда уходит запрос. Утилита может наследовать прокси из окружения: тогда тайм-аут или отказ относится к этому маршруту и ещё не доказывает падение сайта.

Чтобы проверить влияние proxy-переменных, сравните один публичный URL с обычным окружением и с явным отключением прокси для одного вызова. Затем найдите настройку, которая выбрала маршрут: переменную протокола, ALL_PROXY или исключение NO_PROXY.

1. Зафиксируйте условия запуска

Запишите URL со схемой HTTP или HTTPS, время, текст ошибки и версию из curl --version. Сравнивайте безопасный GET-запрос без авторизации; повторять оплату или создание заказа для такой проверки не нужно.

Важно, где выполняется команда: в терминале, cron, контейнере или службе. Если сбоит фоновое задание, успешный запуск с ноутбука не воспроизводит его окружение. Даже на одном сервере процессы могут получить разные настройки.

2. Проверьте, какая переменная подходит к URL

В документации curl о proxy-переменных описаны такие правила:

• Для URL с http:// используется http_proxy. Вариант HTTP_PROXY curl намеренно не принимает.
• Для https:// подходит https_proxy или HTTPS_PROXY. При одновременном задании вариантов с разным регистром предпочтение получает нижний.
• all_proxy или ALL_PROXY задаёт общий прокси, но настройка конкретного протокола имеет приоритет.
• no_proxy или NO_PROXY содержит исключения — имена через запятую. Единственная звёздочка отключает прокси для всех адресов.

Имя HTTPS_PROXY относится к схеме целевого URL. Значение при этом может начинаться с http://: это HTTP-прокси, через который устанавливается HTTPS-туннель.

Не выводите всё окружение в общий лог: адрес прокси может содержать учётные данные. Для отчёта достаточно отметить наличие нужных переменных и выбранный маршрут; значения проверяет ответственный специалист локально.

3. Сравните два вызова без изменения настроек

Примеры ниже предназначены для Unix-подобной оболочки. Замените example.com на публичный адрес проверяемой страницы.

curl -q -sS -o /dev/null --connect-timeout 10 --max-time 20 \
  -w 'HTTP=%{http_code} peer=%{remote_ip}\n' https://example.com/

curl -q --noproxy '*' -sS -o /dev/null \
  --connect-timeout 10 --max-time 20 \
  -w 'HTTP=%{http_code} peer=%{remote_ip}\n' https://example.com/

В обоих вызовах -q стоит первым параметром и исключает стандартный файл конфигурации curl. Окружение в первом вызове сохраняется, а во втором --noproxy '*' отключает настроенный прокси для этого запроса. Звёздочку нужно оставить в кавычках. Параметры описаны в руководстве curl.

Если исходная команда перестала сбоить уже после добавления -q, отдельно проверьте настройки стандартного конфигурационного файла. Пока нельзя приписывать проблему переменным окружения.

Прямой тест выполняйте только при разрешённом прямом выходе. Он не отключает VPN и прозрачные сетевые посредники. Если сеть требует обязательный прокси, неудача второго вызова ожидаема и ничего не говорит о доступности сайта извне.

Как прочитать результат

• Обычный вызов не проходит, прямой проходит. Исследуйте выбранный прокси, его доступность и правила. Это сужает область поиска, но ещё не устанавливает причину.
• Обычный проходит, прямой нет. Возможны обязательный прокси, различия DNS или сетевого доступа. Не удаляйте рабочую настройку.
• Оба не проходят. Сравните этап и текст отказа; причина может быть общей или различаться для двух путей.
• Оба проходят, задание падает. Повторите сравнение в контексте задания и проверьте его параметры запуска.

Поле peer показывает адрес непосредственного соединения: при прокси это может быть адрес посредника, а не сайта. Значение HTTP=000 не является ответом HTTP 000 — код ответа не получен; нужен текст ошибки curl. Ответ 200 также стоит сверить с ожидаемым содержимым страницы.

4. Найдите ошибку в исключениях и окружении задания

Если один домен идёт через прокси, а другой напрямую, проверьте NO_PROXY. Запись .example.com охватывает соответствующие поддомены; туда не нужно вставлять полный URL с путём. Проверьте оба регистра переменной: оставшееся no_proxy может объяснить, почему изменение NO_PROXY не подействовало.

Для отдельного теста --noproxy '' убирает исключения окружения, а --proxy позволяет явно задать согласованный прокси. Не вставляйте пароль в команду или историю оболочки. Если получен 407, продолжите по инструкции проверки авторизации на прокси.

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

Когда диагностику можно закончить

Проверка завершена, когда понятен выбранный маршрут и исходное задание получает ожидаемый ответ без временных диагностических флагов. Если всё исправлено одной настройкой, дополнительное вмешательство в DNS или сертификат сайта не требуется.

Внешний мониторинг Web-Puls даёт независимое наблюдение за публичным сайтом, но не проверяет proxy-переменные вашего cron или контейнера. Если маршрут остаётся неясным, отправьте заявку на диагностику: приложите публичный URL, время, контекст запуска и результаты двух проверок без секретов. По ним можно согласовать предмет и объём работ.