cURL работает примерно на 20 миллиардах установок по всему миру — он по умолчанию встроен в macOS, большинство дистрибутивов Linux и Windows 10/11. И всё же, если спросить десять разработчиков, как правильно направить запрос cURL через прокси, вы услышите десять немного разных ответов, и половина из них сломается в тот момент, когда в дело вступят авторизация или SOCKS.
Именно этот пробел я и хочу закрыть. Большинство руководств показывают одну команду, говорят, что она работает, и на этом заканчивают. Они не объясняют, как проверить, что прокси действительно что-то делает (спойлер: иногда — ничего), и уж точно не разбирают коды ошибок, которые появляются в тот же миг, как ваша конфигурация хоть немного отклоняется от идеального сценария. В этом гайде мы разберём всё по полной — HTTP/HTTPS-прокси, SOCKS4/SOCKS5/socks5h, переменные окружения (и их довольно коварные нюансы), нормальную таблицу диагностики и то, что делать, когда cURL и прокси уже просто не справляются.
Что такое cURL и зачем использовать его через прокси?
cURL — это командная утилита для передачи данных по URL и обратно. И всё: без графического интерфейса, без лишних украшений, просто программа, которая умеет работать с HTTP, HTTPS, FTP и ещё несколькими протоколами. Самый простой запуск выглядит так:
curl https://example.com
Эта команда получает страницу и выводит сырой HTML в терминал. Полезно само по себе, но главная причина, по которой разработчики и технически продвинутые бизнес-пользователи берутся за cURL, — это тестирование API, сбор данных, проверка контента с геоограничениями и запуск запросов в CI/CD-пайплайнах.
Прокси стоит между вашим компьютером и целевым сервером и пересылает запрос от вашего имени. На стороне сервера виден IP прокси, а не ваш. Это важно по целому ряду легитимных причин: проверить, как сайт выглядит из другой страны, обойти лимиты при QA-тестировании или направить трафик через обязательный корпоративный шлюз. cURL поддерживает весь набор популярных прокси-протоколов — HTTP, HTTPS, SOCKS4 и SOCKS5 — а флаги, которые вы будете видеть снова и снова, это -x / --proxy (адрес прокси), -v (подробный вывод, ваш лучший друг при отладке) и -k (пропуск проверки SSL, который вне тестов лучше вообще не использовать).
Небольшое уточнение перед тем как идти дальше: этот материал про сетевую механику работы cURL через прокси. Он не даёт разрешения игнорировать условия использования сайта или политики безопасности вашей организации. Прокси меняет маршрут трафика — но не меняет то, что разрешено законом или правилами.
Перед началом
Сложность: от начального до среднего уровня
Время: около 15 минут на базовые примеры
Что понадобится:
- Установленный cURL (проверьте через
curl --version— на macOS, Linux и Windows 10/11 он, скорее всего, уже есть) - Данные прокси от провайдера: хост, порт, протокол (HTTP/HTTPS/SOCKS), а также логин и пароль, если они нужны
- Терминал (Terminal на macOS, любой shell в Linux, PowerShell или CMD в Windows)
Если cURL по какой-то причине не установлен, всё решается одной командой: brew install curl на macOS через Homebrew, sudo apt install curl на Debian/Ubuntu или sudo yum install curl на RHEL/CentOS. В Windows он входит в состав системы начиная с Windows 10 build 17063.
Далее я буду использовать шаблонные значения — proxy.example:8080 для адреса прокси и user:pwd для учётных данных. Подставьте свои реальные данные, но никогда не вставляйте настоящие пароли в историю shell, скриншоты или сообщения в Slack. Мне доводилось видеть в Slack больше утёкших прокси-паролей, чем хотелось бы.
Как использовать cURL с HTTP- или HTTPS-прокси
Это самый распространённый вариант, и именно его вы будете использовать в большинстве задач с прокси.
Использование флага -x / --proxy
Базовый синтаксис выглядит так:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x и --proxy делают одно и то же — выбирайте тот вариант, который легче запомнить. Поскольку HTTP — это протокол прокси по умолчанию в cURL, технически можно убрать префикс http:// и написать просто proxy.example:8080. Но я всё равно советую указывать его явно: через полгода вы сами себе скажете спасибо за эту ясность.
Обязательно заключайте весь URL в двойные кавычки. Если в пароле есть символ @, # или &, строка без кавычек может быть испорчена оболочкой ещё до того, как cURL её увидит.
Подключение через HTTPS-прокси
Некоторые провайдеры шифруют не только трафик от прокси к целевому сайту, но и само соединение до прокси. Это не то же самое, что обращение к HTTPS-сайту: протокол прокси и протокол целевого ресурса — независимые вещи. Указать это можно так:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Если здесь появляется ошибка сертификата, не спешите просто добавить -k и двигаться дальше. Этот флаг полностью отключает проверку SSL-сертификатов, что допустимо для пятиминутного локального теста, но очень плохая идея для чего-либо, связанного с production или реальными пользовательскими данными. Если вы работаете с корпоративным прокси, который перехватывает TLS (схема MITM, типичная для корпоративной среды), правильное решение — импорт CA-сертификата прокси, а не отключение проверки.
Авторизация через --proxy-user
Можно вынести логин и пароль в отдельный флаг, вместо того чтобы запихивать их в URL:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Обратите внимание: заглавная -U — это не то же самое, что авторизация на целевом сайте (-u / --user, в нижнем регистре). Перепутать их очень легко, и тогда вы рискуете отправить пароль от прокси не туда, куда нужно. Для корпоративных сред, где вместо Basic используется NTLM или Digest, добавьте --proxy-ntlm или --proxy-digest вместе с --proxy-user.
Как использовать cURL с SOCKS-прокси: SOCKS4, SOCKS5 и socks5h
SOCKS-прокси работают на более низком уровне, чем HTTP-прокси — им не важно, какой именно протокол вы туннелируете. Поэтому они удобны для трафика не только HTTP, для цепочек Tor и для всего, что связано с приватностью. Большинство конкурирующих гайдов ограничиваются одной командой и идут дальше. Это ошибка, потому что различия между SOCKS4, SOCKS5 и socks5h:// действительно имеют значение.
| Функция | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| Поддержка TCP | Да | Да | Да |
| Поддержка UDP | Нет | Да | Да |
| Аутентификация | Нет | Да | Да |
| Удалённое разрешение DNS | Нет | Нет (локальный DNS) | Да (DNS резолвит прокси) |
| Совместимость с Tor | Нет | Рискованно (утечка DNS) | Да |
Строка про DNS — это то место, на котором люди чаще всего попадаются. При использовании socks5:// ваше устройство само определяет IP домена до передачи соединения прокси — то есть ваш локальный DNS-резолвер, а значит и провайдер, видит, к какому домену вы обращаетесь, даже если сам HTTP-трафик идёт через прокси. socks5h:// решает эту проблему: разрешением имени занимается сам прокси, и локально не утечёт ничего о целевом адресе. Именно поэтому документация Tor настаивает на socks5h:// — обычный socks5:// сводит на нет значительную часть анонимности, которую Tor должен обеспечивать.
Вот как выглядят все варианты в cURL:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
Если у вас нет особой причины поступать иначе, по умолчанию выбирайте socks5h://. Это ничего не стоит, но убирает утечку, которую вы иначе могли бы даже не заметить.
Как задать прокси через переменные окружения и не попасть в ловушки
Каждый раз прописывать -x надоедает очень быстро. Переменные окружения позволяют задать прокси один раз на сессию shell, а все последующие вызовы cURL будут использовать его автоматически — в документации cURL указаны http_proxy, HTTPS_PROXY, ALL_PROXY и NO_PROXY как поддерживаемый набор.
Основы
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
Вот момент, на котором люди постоянно спотыкаются: имя переменной относится к протоколу целевого URL, а не к протоколу самого прокси. То есть http_proxy управляет запросами к URL с http://, а HTTPS_PROXY — запросами к URL с https://. При этом оба могут указывать на один и тот же HTTP-прокси-сервер — и это совершенно нормально.
Исключения через NO_PROXY
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Значения перечисляются через запятую, а точка в начале .internal.example работает как маска для любых поддоменов. NO_PROXY перекрывает всё остальное — даже если -x явно указан в командной строке, совпадение в NO_PROXY приведёт к обходу прокси для этого запроса.
Подводные камни, на которые люди реально попадаются
- Забыть
export. Если просто написатьhttp_proxy=http://...безexport, переменная останется только в текущем shell и для cURL как дочернего процесса будет полностью невидима. По моему опыту, это самая частая причина обращений в духе «прокси не работает». - Чувствительность к регистру. cURL сначала проверяет именно
http_proxyв нижнем регистре и отдаёт ему приоритет, если есть оба варианта. Некоторые другие инструменты читают только верхний регистр. Если вы ищете, почему переменная «не подхватывается», проверьте, нет ли дубля с другим регистром. - Ловушка с alias в PowerShell. В PowerShell 5.1 команда
curl— это вовсе не cURL, аInvoke-WebRequest, совершенно другой инструмент с другими флагами. Если на Windows ваш-xвыдаёт странные ошибки, явно вызывайтеcurl.exe, чтобы убедиться, что запускается именно cURL. - Разница синтаксиса в Windows. В CMD используется
set http_proxy=...; в PowerShell —$env:http_proxy = "...". Если перепутать эти варианты между сессиями терминала, можно очень легко потерять полдня. - Устаревшие переменные.
unset http_proxyиunset https_proxyубирают старую конфигурацию, которая тихо направляет все запросы через нерабочий прокси и из-за этого ломается.
Для быстрого переключения пара алиасов в .bashrc реально экономит время:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
Как заставить cURL всегда использовать прокси (через config-файл)
Если вы в 95% случаев работаете через корпоративный прокси, файл .curlrc (в Unix-подобных системах в домашней директории) или _curlrc (в Windows, в папке app-data) задаёт постоянное значение по умолчанию без переменных окружения:
proxy="http://proxy.example:8080"
Если для одного запроса нужно пропустить прокси, --noproxy "*" переопределит настройку только для этого запуска. Приоритет обычно такой: флаг в командной строке > переменная окружения > config-файл, поэтому -x в командной строке всегда победит при конфликте.
Важное предупреждение: не храните пароль в открытом виде в .curlrc, если файл может синхронизироваться, попадать в бэкап или случайно оказаться в репозитории. Для CI-пайплайнов лучше использовать secret manager вашей платформы и передавать учётные данные как скрытые переменные окружения.
Как проверить, что прокси действительно работает
Это тот раздел, который почти все остальные статьи пропускают, а он экономит больше всего времени на отладку. Настроить прокси и предположить, что он действительно маршрутизирует трафик, — это классический способ потратить часы на поиск проблемы в scraper’е, который на самом деле вообще не использовал прокси.
Способ 1: сравнить внешний IP
Выполните один и тот же запрос на определение IP дважды — один раз напрямую, второй через прокси, и сравните результат:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Если оба запроса возвращают один и тот же IP, значит прокси ничего не меняет. Проверьте синтаксис флагов, переменные окружения или не сработал ли NO_PROXY на ваш адрес.
Способ 2: посмотреть verbose-вывод
Добавьте -v к любому запросу через прокси — и cURL покажет весь обмен:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Ищите строку вроде * Connected to proxy.example (xx.xx.xx.xx) port 8080, затем > CONNECT httpbin.org:443 HTTP/1.1 и в конце < HTTP/1.1 200 Connection established. Эта последовательность — подключение к прокси, затем туннель CONNECT к целевому серверу — и есть работа HTTP CONNECT method, именно так и должно быть, когда HTTPS-цель проходит через HTTP-прокси. Если строки CONNECT нет, значит флаг прокси не применился. И ещё важное предупреждение: включайте -v только во время активной отладки и обязательно редактируйте вывод перед тем, как куда-то его отправлять — verbose-режим может показать прокси-логин и пароль в открытом виде.
Способ 3: сравнение файлов «до и после»
Если вам важна геопроверка, сохраните оба ответа в файлы и сравните их:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
Если тела ответа (или заголовки, если речь о геоограниченном контенте) различаются, у вас есть наглядное подтверждение, что прокси действительно меняет маршрут трафика — быстрый и почти безболезненный способ снять сомнения перед дальнейшей диагностикой.
Типичные ошибки cURL при работе с прокси и как их устранять
Большинство руководств здесь только отмахиваются и один раз упоминают -k. Этой теме нужна нормальная справочная таблица.
| Ошибка | Вероятная причина | Исправление |
|---|---|---|
curl: (7) Failed to connect | Неверный хост/порт прокси или прокси недоступен | Проверьте адрес; протестируйте соединение напрямую через telnet host port или nc -zv host port |
407 Proxy Authentication Required | Отсутствуют или неверны учётные данные прокси | Добавьте --proxy-user user:pass; проверьте, не требуется ли NTLM/Digest/Negotiate вместо Basic |
curl: (56) Recv failure: Connection reset by peer | Прокси разорвал соединение во время передачи | Проверьте стабильность прокси у провайдера; если это TLS-terminating proxy, убедитесь, что сертификаты обрабатываются корректно, а не отключайте проверку принудительно |
curl: (28) Connection timed out | Блокировка фаерволом, устаревший прокси или неверный порт | Выполните env | grep -i proxy, чтобы найти оставшиеся переменные; удалите устаревшие; проверьте прямой запрос, чтобы локализовать причину |
| Ошибка проверки сертификата | Недоверенный или перехватывающий сертификат прокси | Получите правильную цепочку CA и используйте --proxy-cacert; не отключайте проверку вне разового диагностического теста |
Универсальный первый шаг для любой из этих проблем — добавить -v. Это покажет, на каком именно этапе ломается соединение — DNS, TCP-подключение, TLS-handshake или обмен авторизацией с прокси — вместо того чтобы гадать по трёхзначному коду ошибки.
Для корпоративных прокси отдельно существуют --proxy-ntlm и --proxy-negotiate, которые покрывают схемы аутентификации Windows-доменов. А вот что cURL действительно не умеет нативно: PAC-файлы (Proxy Auto-Config), которые некоторые компании используют для динамического выбора прокси. Если у вас именно такой случай, придётся вручную извлечь реальный хост и порт прокси — обычно это можно посмотреть в сетевых настройках браузера, потому что встроенного парсера PAC в cURL нет.
Когда cURL + прокси уже недостаточно
cURL с прокси отлично справляется со статическим HTML, REST API и простыми загрузками данных — пожалуй, лучше почти ничего и не бывает. Но он начинает буксовать там, где современный веб любит ставить защиту: SPA на JavaScript, антибот-системы вроде Cloudflare или Akamai и CAPTCHA-барьеры. Если направить cURL на React- или Vue-приложение за такой защитой, вы получите в ответ пустой <div id="root"></div> — формально запрос успешный, по сути данные бесполезны. Это не баг cURL. Он просто не браузер, и никогда им не был.
Если вы уже умеете запускать cURL из терминала и упёрлись в этот потолок, следующий логичный шаг — не переходить на полностью другой стек, а добавить слой, который сам займётся рендерингом и структурированием. Именно эту задачу и закрывают инструменты для разработчиков от Thunderbit.
| Сценарий | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| Статическая HTML-страница | Работает идеально | Работает, ещё и отдаёт структурированные данные |
| SPA на JS | Получаете пустой/частичный HTML | renderMode: "full" обрабатывает JS |
| Антибот / CAPTCHA | Блокируется | Встроенная обработка |
| Структурированный вывод данных | Сырой HTML — нужно парсить самому | JSON по вашей схеме |
| Пакетная обработка (100+ URL) | Ручной цикл + собственный rate limiting | POST /batch/extract |
Open API от Thunderbit предоставляет endpoint /extract, который возвращает JSON по заданной схеме прямо со страниц с тяжёлым JS, а также endpoint /distill для чистого преобразования в Markdown — оба доступны из того же терминала, где вы уже запускаете команды cURL. Есть также MCP-сервер для AI-ассистентов вроде Claude или Cursor и CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json), если вам удобнее работать полностью из скриптов. Всё это не заменяет cURL там, где cURL хорош, — оно просто подхватывает задачу там, где cURL структурно уже не может идти дальше. Если хотите шире посмотреть, где AI-assisted extraction вписывается по сравнению с написанием собственного scraper-логики, наши материалы по AI web scraping и по лучшим AI web scrapers разбирают это подробнее, а статья о web scraping без кода станет хорошей отправной точкой, если вы смотрите на задачу с бизнес-стороны, а не со стороны инженерии.
Итоги
Настроить корректную работу cURL и прокси несложно, когда вы знаете, где на самом деле возникают сбои — и оказывается, почти никогда не виноват сам прокси. Забытый export. Путаница между -u и -U. Использование socks5:// вместо socks5h://. Запуск псевдокоманды curl в PowerShell вместо curl.exe. Каждая из этих ошибок даёт сбивающее с толку, слишком общее сообщение, которое на самом деле никак не связано с провайдером прокси.
Привычка, которая экономит больше всего времени: сначала проверьте, потом уже отлаживайте. Сделайте IP-check, взгляните на вывод -v, убедитесь, что прокси вообще находится в цепочке запроса, прежде чем искать проблему где-то дальше по пути. А если целевой сайт начинает отдавать JavaScript вместо чистого HTML, это уже не задача для cURL с дополнительными флагами — это сигнал взять инструмент, предназначенный для рендеринга, например API Thunderbit, у которого есть бесплатный тариф, если хотите сами увидеть разницу между JSON на выходе и сырым HTML.
Частые вопросы
Использует ли cURL прокси по умолчанию?
Нет. Если вы не задали переменные окружения http_proxy / HTTPS_PROXY и не настроили файл .curlrc, cURL подключается к целевому ресурсу напрямую, без прокси.
Как заставить cURL не использовать прокси только для одного запроса?
Добавьте --noproxy "*" к конкретной команде. Чтобы отключить его во всей текущей сессии shell, выполните unset http_proxy && unset https_proxy.
Можно ли использовать cURL с rotating proxies?
Да — если провайдер даёт rotating gateway (одну точку входа, которая назначает новый IP на каждый запрос), просто укажите этот адрес в -x, как любой другой прокси. Для более сложной логики ротации при работе с JS-рендеренными сайтами API-слой вроде Thunderbit берёт на себя ротацию и антибот-часть, так что вам не придётся вручную писать retry-логику.
Почему socks5:// “палит” мои DNS-запросы, а socks5h:// — нет?
При socks5:// ваше локальное устройство сначала само определяет IP целевого хоста, а уже потом отправляет запрос на прокси — из-за этого DNS-резолвер провайдера видит домен, который вы открываете. socks5h:// переносит разрешение имени на сам прокси, и локально о целевом адресе ничего не видно.
Законно ли использовать cURL через прокси? Сам по себе прокси в большинстве юрисдикций использовать законно. Важно то, что именно вы с ним делаете — всегда соблюдайте условия использования целевого сайта, robots.txt там, где это применимо, и любые требования закона о защите данных. Этот материал описывает только техническую сторону, а не юридическое разрешение на любой конкретный сценарий.
Подробнее
