Короткий ответ: один флаг. curl -x "http://host:port" "https://example.com" направляет запрос через прокси, так что целевой сервер видит IP прокси, а не ваш. Флаг -x (или --proxy), это вся функциональность. Всё остальное в этой статье, это вариации: как добавить учётные данные, как переключить протокол, как задать прокси для всей сессии в оболочке и как убедиться, что настройка действительно сработала.

Если вы уже знаете, что такое прокси-сервер, и хотите сразу получить готовые команды для копирования, переходите к таблице синтаксиса ниже. В примерах используются 127.0.0.1 и очевидные заполнители, чтобы вы могли подставить свои хост, порт и учётные данные без лишних догадок.

Один флаг, который всё решает: -x

cURL направляет трафик через прокси, когда вы передаёте -x (краткая форма) или --proxy (длинная форма). Они идентичны; выбирайте ту, что лучше читается в ваших скриптах. Значение, это URL: схема, необязательные учётные данные, хост и порт.

bash
# Route one request through an HTTP proxy
curl -x "http://127.0.0.1:8080" "https://example.com"

# Same request, long-form flag
curl --proxy "http://127.0.0.1:8080" "https://example.com"

Схема перед хостом прокси (http://, https://, socks5://) указывает cURL, как общаться с прокси, а не что загружать. Обычный прокси http:// без проблем загружает URL по https://: cURL открывает туннель CONNECT через него и запускает TLS от конца до конца, так что прокси никогда не видит ваши зашифрованные байты. Это различие часто вызывает путаницу, и стоит один раз прочитать о HTTP против HTTPS прокси, если это не очевидно.

Добавление аутентификации прокси

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

Первый способ, вставить имя пользователя и пароль прямо в URL прокси, перед хостом, разделив их двоеточием и завершив символом @:

bash
# Credentials inline in the proxy URL
curl -x "http://user:[email protected]:8080" "https://example.com"

# Credentials in a separate flag (keeps them out of the URL)
curl -x "http://127.0.0.1:8080" -U "user:pass" "https://example.com"

Форма -U (или --proxy-user) заслуживает того, чтобы стать привычкой: она не включает пароль в URL, который, как правило, утекает в историю оболочки и логи. Если ваше имя пользователя или пароль содержат специальные символы (@, :, /), закодируйте их в URL, иначе cURL неправильно определит начало хоста. Например, буквальный символ @ в пароле становится %40.

HTTP, HTTPS и SOCKS в одном месте

Прокси SOCKS работают так же; меняется только схема. SOCKS находится уровнем ниже HTTP и пересылает сырой TCP, поэтому поддерживает любой протокол, но не может читать или переписывать ваши запросы. Используйте socks5h:// вместо socks5://, если хотите, чтобы прокси разрешал DNS (тогда ваша машина никогда не раскрывает имя хоста, которое ищет); буква h означает "hostname resolution on the proxy." Для более глубокого понимания компромисса читайте что такое SOCKS5 прокси.

Goal Флаг и значение
HTTP proxy -x "http://host:port"
HTTPS proxy -x "https://host:port"
SOCKS5 proxy -x "socks5://host:port"
SOCKS5, DNS через proxy -x "socks5h://host:port"
Аутентификация proxy, встроенная -x "http://user:pass@host:port"
Аутентификация proxy, отдельная -U "user:pass"
Обход proxy для хоста --noproxy "example.com"

Существует также отдельный флаг --socks5--socks4), принимающий простой host:port без схемы. Он эквивалентен -x "socks5://..." и существует в основном для читаемости, когда скрипт оперирует несколькими типами прокси одновременно.

http_proxy vs HTTP_PROXY is not a typo

cURL читает как строчную, так и прописную форму переменных окружения, с одной исторической особенностью: он учитывает строчную http_proxy, но из соображений безопасности, только прописную HTTPS_PROXY и остальные. Причина в том, что HTTP_PROXY конфликтует с CGI-заголовком (в некоторых серверных средах Proxy: становится HTTP_PROXY), поэтому cURL намеренно игнорирует прописную форму HTTP в CGI-контексте. Если есть сомнения, используйте строчную для HTTP, и вы избежите этого класса неожиданных проблем.

Настройка прокси для всей оболочки через переменные окружения

Указывать -x в каждой команде утомительно. Экспортируйте прокси один раз, и каждый вызов cURL в этой сессии оболочки будет использовать его, как и большинство других утилит командной строки, уважающих эти переменные (wget, git, менеджеры пакетов и другие).

bash
# Apply to every request in this shell session
export http_proxy="http://user:[email protected]:8080"
export https_proxy="http://user:[email protected]:8080"

# Skip the proxy for these hosts, comma-separated
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Stop using the proxy
unset http_proxy https_proxy

Оба значения http_proxy и https_proxy принимают одинаковое значение: схема, это протокол, используемый cURL для подключения к прокси, а имя переменной определяет, к каким целевым URL оно применяется. NO_PROXY, это механизм исключений: любой хост из списка подключается напрямую. Ведущая точка (.internal.example.com) соответствует всем поддоменам, а NO_PROXY="*" полностью отключает прокси без удаления остальных переменных.

Закрепление прокси через .curlrc

Переменные окружения исчезают вместе с оболочкой. Чтобы cURL всегда использовал прокси, добавьте его в файл конфигурации cURL. В Linux и macOS это ~/.curlrc; в Windows, _curlrc в каталоге %APPDATA%.

bash
# ~/.curlrc  (Linux / macOS)
proxy = "http://user:[email protected]:8080"
proxy-user = "user:pass"

Теперь каждая команда cURL будет проходить через прокси без каких-либо флагов. У этого удобства есть обратная сторона: легко забыть о файле и потом час разбираться, почему одна машина ведёт себя иначе, чем другая. Если запрос ведёт себя неожиданно, проверьте ~/.curlrc в первую очередь. Чтобы обойти его для одного вызова, передайте --noproxy "*" или запустите с -q, что говорит cURL игнорировать файл конфигурации полностью.

Обход прокси для отдельных запросов

Когда прокси задан глобально (через переменную окружения или .curlrc), иногда нужно, чтобы один запрос шёл напрямую: например, внутренняя проверка работоспособности или локальный сервис. --noproxy решает это для конкретной команды:

bash
# Ignore the proxy entirely for this one request
curl --noproxy "*" "http://localhost:3000/health"

# Bypass only for one domain, proxy stays on for the rest
curl --noproxy "internal.example.com" "http://internal.example.com/api"

Проверка, что прокси действительно работает

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

bash
# Your real IP, no proxy
curl "https://httpbin.org/ip"

# The IP seen through the proxy: should differ
curl -x "http://user:[email protected]:8080" "https://httpbin.org/ip"

# Add -v to watch the CONNECT handshake and headers
curl -v -x "http://user:[email protected]:8080" "https://httpbin.org/ip"

Флаг подробного вывода (-v), это настоящий инструмент диагностики. Он показывает подключение к прокси, строку CONNECT для HTTPS-целей, ответ прокси и финальный исходящий запрос, что позволяет точно определить место поломки, когда что-то идёт не так.

Частые ошибки прокси в cURL и как их читать

Большинство сбоев прокси укладываются в несколько узнаваемых шаблонов. Чтение сообщения об ошибке, а не слепые повторные попытки, экономит реальное время.

Что вы видите Что обычно означает
Failed to connect to ... port ... Неверный хост или порт, либо прокси недоступен. Проверьте адрес и доступность порта.
Proxy CONNECT aborted / 407 Аутентификация требуется или отклонена. Проверьте учётные данные и закодируйте специальные символы в URL.
SSL certificate problem Проверка TLS не прошла для целевого ресурса, а не для прокси. Исправьте доверенное хранилище, а не отключайте проверки в продакшене.
Could not resolve proxy Неверное имя хоста прокси или DNS не работает до отправки любого запроса.
Received HTTP code 403 / 429 Прокси подключился нормально; целевой ресурс заблокировал или ограничил выходной IP. Решение, другой IP или ротирующий пул.

Последняя строка наиболее важна для скрапинга. 403 или 429 означает, что ваша команда cURL идеальна: целевой ресурс просто не доверяет IP, с которого вы пришли. Никакой флаг это не исправит; вам нужен лучший или ротирующий IP. Если вы продолжаете сталкиваться с этим, как скрапить без блокировок и коды ошибок статуса прокси рассматривают проблему глубже, чем одна команда.

Относительно SSL: у cURL есть флаг -k (--insecure), который пропускает верификацию сертификата. Он приемлем для тестирования на локальном стенде и представляет реальную опасность для всего, что вам важно, поскольку отключает именно ту проверку, которая обнаруживает атаку посредника. Считайте его инструментом отладки, но не настройкой по умолчанию.

От одного прокси к ротационному пулу

Всё вышесказанное работает с одним прокси. Как только вы начинаете скрапить в больших объёмах, один IP становится узким местом: целевой ресурс ограничивает его, затем блокирует, и вы снова вручную меняете адреса. Обычный следующий шаг, список прокси для самостоятельной ротации, что означает написание логики ротации, повторных попыток и проверки работоспособности вручную. Читайте как использовать ротирующие прокси для такого подхода.

Другой вариант, поставить один эндпоинт перед всем пулом и позволить ему ротировать за вас. Ваша команда cURL вообще не меняется; вы просто указываете -x на шлюз вместо одного хоста, и для каждого запроса на выходе выбирается свежий IP.

Crawlbase Smart AI Proxy

Smart AI Proxy, это один эндпоинт, на который вы указываете cURL: он ротирует запросы через большой пул резидентских, дата-центровых и мобильных адресов и повторяет попытки при блокировках, так что тот же флаг -x, который вы уже знаете, получает свежий доверенный IP при каждом вызове вместо заблокированного. Сначала протестируйте на реальной цели через бесплатный тариф.

bash
# Same -x flag, pointed at a rotating gateway.
# Your token is the proxy username; password is empty.
curl -x "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012" -k \
     "https://httpbin.org/ip"

Это единственное изменение в вашем рабочем процессе: шлюз меняет выходной IP на сервере, пока ваша команда остаётся обычным вызовом cURL. Если цель также требует настоящего браузера или повторных попыток на стороне сервера, управляемый запрос вроде Crawling API принимает URL и возвращает готовый результат, а не просто чистый IP. Для настройки любого из них достаточно прочитать документацию API.

Итоги

Ключевые выводы

  • Один флаг делает всё. curl -x "scheme://host:port" URL направляет трафик через прокси; --proxy, это тот же флаг в полной записи.
  • Схема выбирает протокол к прокси, а не к цели. Прокси http:// всё равно загружает HTTPS через туннель CONNECT; socks5h:// разрешает DNS на стороне прокси.
  • Держите учётные данные вне URL. Предпочитайте -U "user:pass" встроенным данным и кодируйте специальные символы.
  • Задайте один раз через переменные окружения или .curlrc. http_proxy/https_proxy действуют для сессии; ~/.curlrc делает настройку постоянной; NO_PROXY и --noproxy, механизмы исключений.
  • Проверьте, затем читайте ошибки. Выведите свой IP через прокси и используйте -v; 403/429, это заблокированный IP, а не сломанная команда, и именно здесь ротирующий пул оправдывает себя.

Часто задаваемые вопросы

Как использовать прокси с cURL?

Передайте флаг -x (или --proxy) с URL прокси: curl -x "http://host:port" "https://example.com". Добавьте учётные данные прямо в URL как http://user:pass@host:port или, предпочтительно, отдельным флагом -U "user:pass". Схема в URL прокси (http, https, socks5) определяет, как cURL общается с прокси, а не что он загружает.

Как добавить имя пользователя и пароль к прокси в cURL?

Либо встройте их в URL прокси перед хостом (-x "http://user:pass@host:port"), либо укажите отдельно через -U "user:pass". Отдельный флаг не включает пароль в историю оболочки. Закодируйте все специальные символы в учётных данных: например, буквальный @ становится %40, чтобы cURL правильно определил хост.

Как задать прокси через переменные окружения?

Экспортируйте http_proxy и https_proxy с URL прокси, и cURL (плюс большинство других утилит командной строки) будет использовать их для каждого запроса в этой оболочке. Используйте NO_PROXY, чтобы перечислить хосты, которые должны подключаться напрямую, и unset http_proxy https_proxy, чтобы отключить. Предпочитайте строчную http_proxy, чтобы избежать конфликта с прописной формой, связанного с CGI.

Может ли cURL работать через SOCKS5-прокси?

Да. Используйте -x "socks5://host:port" или отдельный флаг --socks5 "host:port". Чтобы прокси разрешал DNS (и ваша машина никогда не раскрывала имя хоста), используйте socks5h:// вместо этого. SOCKS пересылает сырой TCP, поэтому поддерживает любой протокол, но не может читать или переписывать запросы так, как HTTP-прокси.

Как заставить cURL всегда использовать прокси?

Добавьте строку proxy = "http://host:port" в файл конфигурации cURL: ~/.curlrc на Linux и macOS или _curlrc в %APPDATA% на Windows. Каждая команда cURL будет проходить через него без флагов. Чтобы пропустить конфигурацию для одного вызова, передайте -q или используйте --noproxy "*", чтобы обойти прокси только для этого запроса.

Почему мой прокси возвращает ошибки 403 или 429?

Эти коды приходят от целевого ресурса, а не от cURL или прокси, что означает: соединение работало, но выходной IP был заблокирован или ограничен. Один IP прокси быстро помечается под нагрузкой. Решение, другой или ротирующий IP: управляйте пулом самостоятельно или укажите cURL на ротирующий шлюз, который меняет выходной IP для каждого запроса.

Начать создавать

Обходите любой сайт в масштабе, без борьбы с инфраструктурой.

Crawlbase берёт на себя прокси, отпечатки и CAPTCHA, чтобы ваша команда выпускала конвейеры данных вместо поддержки обвязки краулинга. 1 000 запросов бесплатно, без карты.

Самообслуживание · Звонок отдела продаж не требуется · Доступны корпоративные объёмы краулинга