Подключение прокси в программах и на сервере: переменные, код и службы

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

Дальше идут рабочие куски для оболочки, curl и wget, Python, Node.js, PHP, Java, контейнеров и служб, а следом поля посредника в парсерах и антидетект-браузерах и проверка на сервере, куда реально уходят пакеты. Всё проверяется одной командой, и порядок написан так, чтобы после каждого шага у администратора был ответ на вопрос «работает или нет».

Что нужно собрать до настройки

Перед правкой конфигов на руках должны быть четыре вещи: адрес, порт, протокол и способ доступа. Адрес с портом берём из списка в кабинете. Протокол выбираем под софт: HTTP и HTTPS понимают браузеры и почти все библиотеки, SOCKS4 и SOCKS5 нужны программам, которые ходят по произвольным портам и держат сокеты сами. Способ доступа определяет, будет ли в строке пара логина с паролем.

Способов доступа два. Первый: в кабинете указан адрес машины, с которой идут запросы, и тогда строка выглядит как протокол://адрес:порт без учётных данных. Второй: берём формат IP:PORT:LOGIN:PASS, и пара приезжает внутрь строки подключения. Разбор того, чем эти режимы отличаются по механике проверки права, лежит в материале про два способа доступа к прокси, здесь мы работаем с готовой строкой.

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

Переменные окружения на Linux и в Windows

Переменные окружения покрывают самый широкий слой софта: их читают curl, wget, apt, pip, npm, composer, большинство библиотек на Python и Go. Один экспорт закрывает десяток программ сразу.

# доступ по привязанному адресу машины
export http_proxy="http://193.42.118.26:8000"
export https_proxy="http://193.42.118.26:8000"
export no_proxy="localhost,127.0.0.1,10.0.0.0/8,.internal"

# доступ по логину и паролю
export http_proxy="http://prx7412:[email protected]:8000"
export https_proxy="http://prx7412:[email protected]:8000"

# то же самое по SOCKS5, имена разрешает посредник
export all_proxy="socks5h://prx7412:[email protected]:8000"

Три подробности, которые экономят вечер разбора. Регистр имён важен: curl читает http_proxy только в нижнем регистре, зато https_proxy и HTTPS_PROXY подхватывает одинаково, а часть библиотек смотрит исключительно на верхний. Мы держим оба написания, если в парке смешанный софт. Переменная no_proxy спасает от того, чтобы внутренние адреса ходили наружу через посредника: базу, брокер очередей и локальные API туда вносим сразу. Пароль со служебными символами кодируется по правилам адресной строки, символ @ внутри пароля превращается в %40, двоеточие в %3A, иначе разбор строки развалится на первом же запросе.

Чтобы переменные пережили перезапуск оболочки, кладём их в файл. Для одного пользователя это ~/.bashrc либо ~/.profile, для всей машины удобнее отдельный файл в каталоге профиля.

sudo tee /etc/profile.d/proxy.sh >/dev/null <<'EOF'
export http_proxy="http://prx7412:[email protected]:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,::1"
EOF
sudo chmod 0644 /etc/profile.d/proxy.sh

В Windows логика та же, меняются команды. Переменная текущей сессии PowerShell живёт до закрытия окна, setx пишет её в профиль пользователя и подхватывается новыми процессами, netsh winhttp правит настройку для служб и системных компонентов, которые ходят через WinHTTP.

# только текущая сессия
$env:HTTPS_PROXY = "http://prx7412:[email protected]:8000"

# постоянно для пользователя, действует в новых окнах
setx HTTPS_PROXY "http://prx7412:[email protected]:8000"

# для служб и системных компонентов
netsh winhttp set proxy 193.42.118.26:8000 "localhost;127.0.0.1;*.local"
netsh winhttp show proxy
netsh winhttp reset proxy

Типовая ошибка на Windows выглядит так: администратор выполнил setx и тут же проверяет в том же окне, а переменная там пустая. Открываем новую консоль, проверка проходит. Сама по себе netsh winhttp не влияет на браузеры и на программы с собственными сетевыми стеками, для них поле посредника ищем внутри интерфейса.

curl и wget: первая проверка руками

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

# один запрос через посредника, ответ покажет выходной адрес
curl -x http://193.42.118.26:8000 https://ifconfig.me

# пара логина с паролем внутри ключа
curl -x http://prx7412:[email protected]:8000 https://ifconfig.me

# пара вынесена отдельным ключом, удобно когда в пароле служебные символы
curl -x 193.42.118.26:8000 --proxy-user 'prx7412:k29fbt' https://ifconfig.me

# SOCKS5 с разрешением имён на стороне выхода
curl --proxy socks5h://prx7412:[email protected]:8000 https://ifconfig.me

# код ответа и время целиком, без тела страницы
curl -x http://193.42.118.26:8000 -sS -o /dev/null \
  -w "code=%{http_code} connect=%{time_connect} total=%{time_total}\n" \
  https://example.com

Ключ -x принимает и схему socks5://, и socks5h://. Разница в том, кто разрешает имя узла: в первом случае это делает локальная машина, во втором посредник. Для работы с целевыми сайтами берём вариант с буквой h, тогда наружу с машины не уходит ни одного запроса к системе имён, и картина по выходному адресу получается цельной.

У wget своя логика: ключа для посредника у него нет, настройка приезжает через переменные или через ключ -e, который на лету дописывает строку конфигурации.

wget -e use_proxy=yes -e http_proxy=193.42.118.26:8000 \
     -e https_proxy=193.42.118.26:8000 -O - https://ifconfig.me

wget --proxy-user=prx7412 --proxy-password=k29fbt \
     -O catalog.html https://example.com/catalog

Постоянные настройки удобнее держать в файлах ~/.curlrc и ~/.wgetrc. В первом строка вида proxy = "http://193.42.118.26:8000", во втором use_proxy = on вместе с адресами. Файлы с паролями закрываем правами chmod 600, доступ к ним нужен только своему пользователю.

Python: requests, httpx и вариант для SOCKS5

Библиотека requests читает переменные окружения автоматически, поэтому иногда после export в коде править нечего. Явное указание надёжнее: конфиг не зависит от того, из какой оболочки запустили скрипт.

import requests

PROXY = "http://prx7412:[email protected]:8000"
proxies = {"http": PROXY, "https": PROXY}

r = requests.get("https://ifconfig.me/ip", proxies=proxies, timeout=15)
print(r.status_code, r.text.strip())

Для серии запросов берём сессию: соединение до посредника переиспользуется, и прогон на несколько тысяч страниц идёт заметно ровнее.

import requests

s = requests.Session()
s.proxies.update({
    "http":  "http://prx7412:[email protected]:8000",
    "https": "http://prx7412:[email protected]:8000",
})
s.trust_env = False          # игнорировать переменные окружения
s.headers["User-Agent"] = "collector/1.4"

for url in urls:
    try:
        resp = s.get(url, timeout=(5, 20))
        print(resp.status_code, len(resp.content), url)
    except requests.exceptions.ProxyError as e:
        print("proxy", e)
    except requests.exceptions.ReadTimeout:
        print("timeout", url)

Флаг trust_env = False снимает частый источник путаницы, когда в окружении остался старый экспорт и скрипт ходит совсем не туда, куда написано в коде. Отдельно разводим два исключения: ProxyError говорит про доступ к посреднику, ReadTimeout про целевой сайт.

Клиент httpx устроен иначе. Посредник задаётся параметром при создании клиента, а раздельная настройка по схемам делается через mounts.

import httpx

with httpx.Client(proxy="http://prx7412:[email protected]:8000",
                  timeout=httpx.Timeout(20.0, connect=5.0)) as c:
    print(c.get("https://ifconfig.me/ip").text)

# раздельно по схемам
transport_http = httpx.HTTPTransport(proxy="http://193.42.118.26:8000")
client = httpx.Client(mounts={"http://": transport_http,
                              "https://": transport_http})

Для SOCKS5 обеим библиотекам нужна дополнительная зависимость. Ставим её один раз, дальше меняется только схема в строке.

pip install "requests[socks]" "httpx[socks]"

SOCKS = "socks5h://prx7412:[email protected]:8000"
proxies = {"http": SOCKS, "https": SOCKS}          # requests
client = httpx.Client(proxy=SOCKS)                  # httpx

Асинхронный aiohttp понимает только HTTP-посредника через параметр proxy у запроса, для сокетного режима ему нужен пакет aiohttp-socks и коннектор ProxyConnector.from_url(...). Тем, кто пишет сборщики на сокетах и упирается в произвольные порты, ближе прокси SOCKS5 для программ и скриптов: протокол пропускает и TCP-соединения, и запросы к системе имён.

Node.js, PHP и Java: три среды и три подхода

В Node.js встроенный fetch сам по себе посредника не видит, ему нужен диспетчер из undici. Схема рабочая и короткая: создаём агент, ставим его глобально, дальше весь исходящий трафик процесса идёт через посредника.

import { ProxyAgent, setGlobalDispatcher } from 'undici';

const agent = new ProxyAgent('http://prx7412:[email protected]:8000');
setGlobalDispatcher(agent);

const r = await fetch('https://ifconfig.me/ip');
console.log(r.status, await r.text());

Для axios и старого http.request берём внешний агент. Важная тонкость: у axios есть собственное поле proxy, и для адресов по HTTPS оно ломает туннель CONNECT, поэтому его выключаем и оставляем работать агент.

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');

const agent = new HttpsProxyAgent('http://prx7412:[email protected]:8000');

const res = await axios.get('https://example.com/api/items', {
  httpsAgent: agent,
  proxy: false,
  timeout: 20000,
});
console.log(res.status);

Puppeteer и Playwright принимают посредника при запуске браузера: --proxy-server=http://193.42.118.26:8000 в аргументах либо объект proxy с полями server, username, password. Пара логина с паролем передаётся отдельно, внутрь строки её класть не нужно.

В PHP посредник живёт в опциях cURL. Пишем адрес, тип и пару, дальше запрос идёт как обычно.

<?php
$ch = curl_init('https://ifconfig.me/ip');
curl_setopt_array($ch, [
    CURLOPT_PROXY          => '193.42.118.26',
    CURLOPT_PROXYPORT      => 8000,
    CURLOPT_PROXYTYPE      => CURLPROXY_HTTP,
    CURLOPT_PROXYUSERPWD   => 'prx7412:k29fbt',
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_CONNECTTIMEOUT => 5,
    CURLOPT_TIMEOUT        => 25,
]);
$body = curl_exec($ch);
if ($body === false) {
    echo 'curl error ', curl_errno($ch), ': ', curl_error($ch), PHP_EOL;
}
curl_close($ch);
echo $body;

Для сокетного режима меняем одну строку: CURLPROXY_SOCKS5_HOSTNAME вместо CURLPROXY_HTTP, и разрешение имён уезжает на сторону выхода. Guzzle принимает готовую строку в опции proxy, там же можно задать исключения ключом no. Функции вроде file_get_contents работают через контекст потока с полем proxy и флагом request_fulluri, включённым в true.

Java читает посредника из системных свойств. Их задают ключами при запуске либо через System.setProperty до первого сетевого вызова.

java -Dhttp.proxyHost=193.42.118.26 -Dhttp.proxyPort=8000 \
     -Dhttps.proxyHost=193.42.118.26 -Dhttps.proxyPort=8000 \
     -Dhttp.nonProxyHosts="localhost|127.0.0.1|*.internal" \
     -Djdk.http.auth.tunneling.disabledSchemes="" \
     -jar collector.jar

Свойство jdk.http.auth.tunneling.disabledSchemes с пустым значением возвращает базовую проверку пары логина с паролем внутри туннеля CONNECT: по умолчанию среда её отключает, и запрос отваливается с отказом доступа. Сама пара подставляется через Authenticator.setDefault(...). Сокетный режим включается свойствами socksProxyHost и socksProxyPort, они действуют на весь процесс сразу.

Docker и systemd: посредник для контейнера и для службы

Контейнер собственных настроек не наследует, переменные передаются явно. При запуске одиночного контейнера это ключи -e, в описании сервиса это блок environment.

docker run --rm \
  -e HTTP_PROXY="http://prx7412:[email protected]:8000" \
  -e HTTPS_PROXY="http://prx7412:[email protected]:8000" \
  -e NO_PROXY="localhost,127.0.0.1,db,redis,.internal" \
  parser:latest python run.py

services:
  worker:
    image: parser:latest
    environment:
      HTTP_PROXY: "http://prx7412:[email protected]:8000"
      HTTPS_PROXY: "http://prx7412:[email protected]:8000"
      NO_PROXY: "localhost,127.0.0.1,db,redis"
    depends_on:
      - db

Три вещи ломаются здесь чаще остального. Первая: имена соседних контейнеров забыли внести в NO_PROXY, и обращение к базе тоже поехало наружу через посредника, где его никто не ждёт. Вторая: адрес 127.0.0.1 внутри контейнера означает сам контейнер, поэтому локальный туннель на узле доступен по имени host.docker.internal либо через запуск с сетью узла. Третья: во время сборки образа переменные окружения запуска не действуют, для этапа сборки они передаются ключами --build-arg HTTP_PROXY=..., и это отдельная настройка. Отдельно живут скачивания самого демона: чтобы docker pull ходил через посредника, настройка кладётся в конфигурацию клиента или в дополнение к юниту демона.

Служба под systemd получает переменные из юнита. Прямые строки Environment= подходят для адреса без пары логина, учётные данные аккуратнее вынести в отдельный файл с правами 600, потому что содержимое юнита видно любому пользователю через systemctl show.

[Unit]
Description=Price collector
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=collector
WorkingDirectory=/opt/collector
Environment=no_proxy=localhost,127.0.0.1,::1
EnvironmentFile=/etc/collector/proxy.env
ExecStart=/usr/bin/python3 /opt/collector/run.py
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

# файл с учётными данными, читает только root
sudo install -m 600 /dev/null /etc/collector/proxy.env
sudo tee /etc/collector/proxy.env >/dev/null <<'EOF'
http_proxy=http://prx7412:[email protected]:8000
https_proxy=http://prx7412:[email protected]:8000
EOF

sudo systemctl daemon-reload
sudo systemctl restart collector
systemctl show -p Environment collector.service

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

Служба работает без человека за консолью, и это меняет требования к доступу. Ручной запуск можно поправить на ходу, а демон, который стартует ночью по таймеру, обязан подниматься с рабочими настройками с первой попытки. Поэтому под круглосуточные задачи мы берём серверные прокси для постоянной нагрузки и держим учётные данные в одном файле окружения на весь парк узлов: конфигурация раскатывается системой управления, и при добавлении нового сервера правится ровно одна строка. Проверить результат помогает вывод systemctl show -p Environment, он показывает окружение процесса ровно в том виде, в каком его получила служба.

Парсеры и антидетект-браузеры: где лежит поле посредника

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

A-Parser забирает список ссылкой и обновляет его сам по расписанию, поэтому в кабинете достаточно один раз скопировать адрес выдачи и вставить его в настройки чекера. Дальше программа держит актуальный набор строк без ручных движений. Потоки в задании ставим ниже лимита пакета, потому что чекер тоже занимает соединения. Готовые настройки под потоковые прогоны собраны на странице про прокси для A-Parser и массовых прогонов.

Key Collector берёт список во вкладке сети и умеет проверять его до запуска. Полезная привычка: прогонять проверку перед каждым большим съёмом, тогда неотвечающие строки отсекаются заранее и статистика по прогону не смазывается.

ZennoPoster работает на двух уровнях. Общий список живёт в менеджере и раздаётся всем проектам, а внутри проекта посредник ставится кубиком и меняется по ходу шаблона, если логика требует нового адреса на каждой итерации. Строка принимается в привычном виде со схемой впереди.

Антидетект-браузеры хранят посредника в карточке профиля вместе с отпечатком. Один профиль ходит через один адрес, поля заполняются раздельно, рядом обычно есть кнопка проверки, которая показывает выходной адрес до запуска браузера. Для работы с несколькими кабинетами берём прокси под антидетект-браузеры и профили, а сами адреса раздаём по профилям из списка кабинета.

Программа посредника не понимает: локальный туннель

Часть софта сетевых настроек вообще не имеет. Старая утилита, самописный демон, закрытый клиент поставщика. Здесь работает обходной путь: поднимаем на машине локальный слушатель, который принимает соединения на 127.0.0.1 и уводит их вверх на наш адрес из пула. Программа ходит на собственный узел и ничего про посредника не знает.

# приём HTTP на 3128 и SOCKS на 1080, наверх уходит SOCKS5
gost -L=http://127.0.0.1:3128 -L=socks5://127.0.0.1:1080 \
     -F=socks5://prx7412:[email protected]:8000

# то же самое через 3proxy, конфиг /etc/3proxy/tunnel.cfg
nserver 1.1.1.1
auth none
allow * 127.0.0.1
parent 1000 socks5 193.42.118.26 8000 prx7412 k29fbt
proxy -p3128 -i127.0.0.1
socks -p1080 -i127.0.0.1

Ключ -i127.0.0.1 здесь обязателен: слушатель поднимается только на локальном интерфейсе и снаружи недоступен. После запуска в настройках программы указываем 127.0.0.1:3128, и трафик уходит через пул.

Второй приём для Linux это перехват вызовов сокетов. Утилита proxychains подменяет системные функции у запускаемого процесса и заворачивает соединения в посредника.

# /etc/proxychains.conf
strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 193.42.118.26 8000 prx7412 k29fbt

proxychains4 -f /etc/proxychains.conf /opt/legacy/collector --run daily

У перехвата есть граница: он работает через подмену библиотеки, поэтому статически собранные программы и часть исполняемых файлов на Go идут мимо него напрямую. Проверяется это одной командой с наблюдением за трафиком, и если соединения видны в обход посредника, переходим на вариант с локальным слушателем: он работает на уровне адреса и порта и от способа сборки программы не зависит. В Windows ту же задачу закрывают перехватчики уровня приложения, где правило задаётся именем исполняемого файла.

Проверка на сервере: куда реально уходят запросы

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

# соединения процесса к порту посредника
ss -tnp state established '( dst = 193.42.118.26 )'

# что открыл конкретный процесс
sudo lsof -p "$(pgrep -f collector.py)" -i -n -P

# трафик к посреднику виден, встречный трафик мимо него отсутствует
sudo tcpdump -ni eth0 'host 193.42.118.26 and port 8000' -c 20
sudo tcpdump -ni eth0 'tcp port 443 and not host 193.42.118.26' -c 20

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

Сверку выходного адреса удобно оформить маленьким сценарием и запускать его до прогона.

#!/usr/bin/env bash
set -u
PROXY="http://prx7412:[email protected]:8000"

direct=$(curl -s --max-time 10 https://ifconfig.me)
viaprx=$(curl -s --max-time 15 -x "$PROXY" https://ifconfig.me)

echo "напрямую: $direct"
echo "через пул: $viaprx"
[ "$direct" != "$viaprx" ] && echo "OK, выходной адрес отличается" || echo "ВНИМАНИЕ, адрес совпал"

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

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

Для машин, где программ несколько и часть из них ходит по паре логина с паролем, а часть по привязке, порядок такой: сначала сверяем список программ и их способ доступа, затем правим окружение, затем перезапускаем службы. Смешивать два способа в одном процессе не нужно, доступ по учётным данным работает откуда угодно и снимает вопрос совсем. Список в формате IP:PORT:LOGIN:PASS выдаётся в кабинете там же, где оформляется доступ по HTTP и HTTPS.

Частые вопросы

В каком формате выдаётся список прокси?

Форматов два: IP:PORT для работы с привязанным адресом машины и IP:PORT:LOGIN:PASS для доступа по учётным данным. Забрать список можно ссылкой или файлом, оба варианта лежат в кабинете. Список обновляется в режиме реального времени, поэтому программам, которые умеют подтягивать его сами, отдаём ссылку.

Чем проверять прокси перед прогоном?

Мы рекомендуем чекер от Zennolab, у него есть демонстрационная версия. Он проходит список пачкой и показывает отвечающие строки, время отклика и тип. Для одиночной проверки хватает запроса через curl на сервис, который возвращает выходной адрес.

Есть ли лимиты по потокам?

У каждого пакета свой лимит: стандартные дают до 1000 потоков, корпоративный до 3000. Пакеты по потокам не складываются, и при двух привязанных адресах общее число потоков делится пополам. Аккаунты с подозрительно высокой активностью ставятся на паузу до выяснения, это защищает пул в интересах всех клиентов.

Как подключиться к прокси после покупки?

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

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