Подключение прокси и символ @, который ломает всю строку

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

Чаще всего ломается мелочь. Последний раз я потерял на этом 40 минут: пароль от прокси содержал символ @, программа делила строку не там и стучалась на несуществующий хост. В логе при этом было одно слово «недоступен». Ниже порядок, при котором такие вещи не случаются.

Подключение прокси: что происходит в сети

Без прокси программа открывает соединение прямо с сайтом, и сайт видит ваш IP. С прокси первое соединение идёт на его адрес и порт. Это и есть подключение к прокси в узком смысле, и ошибки вида «не удаётся подключиться к прокси-серверу» случаются именно на этом шаге, до всякого сайта.

Дальше всё зависит от протокола. HTTP-прокси получает от программы запрос целиком. Для сайтов на https программа отправляет команду CONNECT с именем хоста и портом 443, прокси открывает туннель, и внутри него идёт шифрованный трафик, в который сервер не заглядывает. Логин и пароль передаются заголовком Proxy-Authorization. Протоколы HTTP и HTTPS с примерами разобраны там же, где можно купить прокси https.

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

Как записать строку: 5 форматов одного прокси

Один и тот же прокси разные программы ждут в разной записи. Вот пять вариантов, которые встречаются постоянно:

• IP:ПОРТ для авторизации по IP, когда логин не нужен.

• IP:ПОРТ:ЛОГИН:ПАРОЛЬ в таком виде часто выдают списки. Парсеры и антидетект-браузеры обычно понимают его напрямую.

• ЛОГИН:ПАРОЛЬ@IP:ПОРТ ждут curl, A-Parser и многие чекеры.

• http://ЛОГИН:ПАРОЛЬ@IP:ПОРТ нужен скриптам, библиотекам и переменным окружения.

• socks5h://ЛОГИН:ПАРОЛЬ@IP:ПОРТ то же самое для SOCKS5, имена сайтов резолвит сам прокси.

Переводить список из формата с двоеточиями в формат с @ руками не надо. На Linux и macOS хватает одной строки:

sed -E 's/^([^:]+):([^:]+):([^:]+):(.+)$/\3:\4@\1:\2/' proxies.txt > converted.txt

В PowerShell то же самое делает замена по регулярному выражению:

(Get-Content proxies.txt) -replace '^([^:]+):([^:]+):([^:]+):(.+)$','$3:$4@$1:$2' | Set-Content converted.txt

Теперь про символ из заголовка. В записях с @ и со схемой пароль стоит внутри адреса, и служебные символы в нём ломают разбор. Их кодируют: @ превращается в %40, двоеточие в %3A, решётка в %23, косая черта в %2F, знак процента в %25. В формате с двоеточиями проблема другая: двоеточие внутри пароля сдвигает поля, и программа принимает кусок пароля за логин. Если пароль задаёте сами, обходитесь буквами и цифрами. Длина защищает лучше спецсимволов.

Где задаётся прокси: система, браузер, программа

Система

В Windows путь такой: Параметры, раздел «Сеть и Интернет», пункт «Прокси-сервер». В блоке ручной настройки включите «Использовать прокси-сервер» (в Windows 11 через кнопку «Настроить»), впишите адрес и порт, сохраните. Полей для логина и пароля здесь нет. Когда прокси потребует авторизацию, браузер сам покажет окно ввода. SOCKS5 в этом окне задать нельзя. Пошагово со всеми флажками это разобрано в статье про настройку прокси в Windows.

Системные настройки слушают Edge, Chrome, Яндекс Браузер и часть программ. Firefox тоже берёт их по умолчанию, пока в нём не включена своя настройка. Многие службы Windows ходят через отдельный механизм WinHTTP и ручные настройки из Параметров не видят. Скопировать их туда можно командой из консоли администратора:

netsh winhttp import proxy source=ie
netsh winhttp show proxy

Первая команда переносит ручные настройки, вторая показывает, что получилось. Сбросить обратно на прямое соединение можно через netsh winhttp reset proxy.

В macOS прокси живёт в разделе Системные настройки, Сеть, затем нужное подключение, кнопка «Подробнее» и вкладка «Прокси». Там есть отдельные строки для веб-прокси HTTP, HTTPS и SOCKS.

Браузер

Chrome, Edge и Яндекс Браузер своих настроек прокси не держат и берут системные. Отдельный прокси для Chrome задают ключом запуска, и тут есть ловушка: если Chrome уже открыт с тем же профилем, новый запуск просто откроет окно в старом процессе, и ключ будет проигнорирован. Поэтому профиль указывают свой:

chrome.exe --user-data-dir="C:\chrome-proxy" --proxy-server="http://IP:ПОРТ"

Логин и пароль в этом ключе Chrome игнорирует. Для SOCKS5 авторизации в нём нет совсем. Значит, для Chrome с ключом подходит авторизация по IP или HTTP-прокси с окном ввода пароля. Firefox живёт отдельно: в его настройках сети есть ручной режим с полями для HTTP-прокси и узла SOCKS v5 и галочка, которая отправляет DNS-запросы через прокси.

Программа

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

export https_proxy="http://ЛОГИН:ПАРОЛЬ@IP:ПОРТ"
export http_proxy="$https_proxy"
export no_proxy="localhost,127.0.0.1"

У curl тут своя особенность: переменную http_proxy он читает только строчными буквами. В Windows постоянную переменную задаёт команда setx HTTPS_PROXY "http://ЛОГИН:ПАРОЛЬ@IP:ПОРТ", и действует она только на окна консоли, открытые после неё. Уже запущенные ничего не узнают. Отсюда частая жалоба «прокси не подхватился».

Пароль в переменной окружения видят все программы этого пользователя, и он легко попадает в логи и историю команд. Для общего сервера это весомый довод в пользу авторизации по IP. В Python-библиотеке requests прокси передают словарём, и здесь живёт самая частая ошибка новичков:

proxies = {
    "http": "http://ЛОГИН:ПАРОЛЬ@IP:ПОРТ",
    "https": "http://ЛОГИН:ПАРОЛЬ@IP:ПОРТ",  # схема прокси http и для https-сайтов
}
requests.get("https://api.ipify.org", proxies=proxies, timeout=15)

Ключ словаря описывает сайт, значение описывает сам прокси. Большинство прокси говорят с клиентом по обычному http даже тогда, когда сайт на https, поэтому запись "https": "https://..." приводит к ошибке TLS-рукопожатия с прокси, который TLS не ждёт.

Авторизация: по IP или по логину и паролю

Способов два, и выбор между ними решает больше, чем кажется.

По IP. Вы привязываете в кабинете свой внешний адрес, и прокси пускает всё, что приходит с него. Строка короткая, без пароля. Это самый надёжный вариант для мест, где полей для пароля нет: Параметры Windows, Chrome с ключом запуска, SOCKS5 в браузере. Слабое место одно. Домашний провайдер может ночью выдать вам новый адрес, привязка перестанет совпадать, и утром всё отвалится с ошибкой 407 или тишиной. Каждую новую машину тоже надо привязывать отдельно.

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

По логину и паролю. Работает с любой сети и любого устройства, пароль едет вместе со строкой. Требует, чтобы программа умела передавать учётные данные, и аккуратности со спецсимволами.

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

Как убедиться, что прокси подключён

Откройте через ту же программу или тот же браузер любую страницу, которая показывает ваш IP. Результатов три. Адрес прокси значит, что всё работает. Ваш собственный адрес говорит, что программа не видит настройку и прокси надо задать уровнем ниже, прямо в ней. Страница не открылась вовсе? Ошибка в адресе, порте или авторизации, и первым делом скопируйте строку заново из кабинета, потому что лишний пробел или перепутанная цифра порта встречаются чаще любых сложных причин. Для системного прокси в Windows есть нюанс: curl.exe системные настройки не читает и пойдёт напрямую, поэтому проверяйте браузером или указывайте прокси в curl явно ключом -x. Полный набор команд с разбором ответов собран в статье как проверить прокси.

Один прокси для системы, браузера и программ

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

Проще купить ipv4 с доступом, который подходит везде: у WinGate адреса работают по HTTP, HTTPS и SOCKS5, авторизация доступна и по IP, и строкой IP:PORT:LOGIN:PASS. Адрес меняется автоматически на каждый запрос, трафик безлимитный, потоков до 5000. Где нет полей для пароля, привязываете IP, где они есть, вставляете строку.

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