Вчера звонит знакомый. Купил прокси под парсинг маркетплейса, вписал цифры в настройки Windows, открывает сайт проверки IP, а там его домашний город. Полчаса переписки, и выясняется: галочку он включил, но в поле «Порт» вставил всю строку целиком, вместе с логином и паролем. Бывает. Дальше по порядку: где в системе живёт эта настройка, что именно вписывать, чем SOCKS5 отличается от HTTP и почему прокси вроде бы включён, а трафик всё равно идёт напрямую.
Windows прячет прокси в трёх кликах, но не там, где его ищут
Половина людей лезет в «Панель управления», потом в «Свойства обозревателя», потом куда-то ещё. В Windows 10 и 11 путь одинаковый и короткий. Жмёте Win+I (или «Пуск» и шестерёнку) и попадаете в «Параметры». Дальше «Сеть и Интернет», в списке пункт «Прокси». Вы на месте.
Там три блока. «Автоматическое определение параметров» система включает по умолчанию, и он пытается найти скрипт конфигурации (PAC-файл) в сети. «Скрипт настройки» нужен тем, кому админ выдал ссылку на этот файл. «Настройка прокси вручную» - это наш случай в девяти из десяти.
Момент, на котором спотыкаются: если настраиваете сервер руками, галочку «Автоматическое определение параметров» лучше снять. Иначе Windows продолжает искать PAC-скрипт через WPAD. При криво настроенном DHCP в локальной сети она может подхватить чужой конфиг. Пять секунд экономии, зато потом не будете гадать, почему настройки «сами слетели».
Ручной режим: два поля, одна галочка и одна проверка
В блоке ручной настройки включаете тумблер «Использовать прокси-сервер» и заполняете два поля. В «Адрес» идёт IP или доменное имя узла, в «Порт» только цифры, без двоеточий и пробелов. Провайдер выдаёт эти два значения в личном кабинете, обычно в формате «адрес:порт». Копировать надо по отдельности, а не строкой. Именно на этом шаге половина людей вставляет в поле порта логин с паролем.
Ниже чекбокс «Не использовать прокси-сервер для локальных адресов». Оставьте его включённым. Тогда сетевой принтер, шара на NAS и внутренние адреса локальной сети идут напрямую, а не через внешний узел. У меня был случай: человек выключил эту опцию и полдня не мог понять, почему перестал открываться корпоративный портал.
Короткий чек-лист по интерфейсу, если делаете впервые:
- Win+I → «Сеть и Интернет» → «Прокси».
- Выключить «Автоматическое определение параметров».
- Включить «Использовать прокси-сервер».
- Вписать адрес и порт из кабинета провайдера.
- Оставить галочку «Не использовать прокси для локальных адресов».
- Нажать «Сохранить» в Windows 11 или «ОК» в Windows 10.
Настройка применяется мгновенно, перезагрузка не нужна. Браузер перезапускать тоже не обязательно, хотя вкладки иногда кешируют соединение - лучше открыть новую.
Проверка, которая показывает правду, а не самоуспокоение
Самая частая ошибка после настройки: человек видит, что интернет работает, и решает, что прокси тоже работает. Интернет и так работал. Проверять надо не наличие связи, а подмену адреса.
Откройте любой сервис определения IP, запомните город и провайдера. Включите прокси, обновите страницу с очисткой кеша (Ctrl+F5) и сравните. Город и провайдер сменились на заявленные в кабинете - всё хорошо. Остались прежними - трафик идёт мимо. Причин обычно три: не та вкладка настроек, опечатка в порту или включённый VPN, который перехватывает маршрут раньше системного прокси.
Отдельно проверьте DNS. Утечка DNS - это когда запросы к сайтам уходят через вашего домашнего провайдера, а сам трафик идёт через прокси. Для аналитики и геозависимых выдач это критично: сайт может отдать региональную версию по DNS, а не по IP. Смотрите через сервисы проверки DNS-утечек.
Команда inetcpl.cpl: старый диалог, который умеет больше
Тот же прокси настраивается через свойства обозревателя, и иногда это удобнее. Win+R, вводите inetcpl.cpl, Enter. Открывается окно «Свойства: Интернет». Вкладка «Подключения», кнопка «Настройка сети». Здесь та же галочка и те же поля, что в «Параметрах»: это буквально один реестровый ключ, просто две оболочки.
Нюанс, ради которого сюда стоит зайти. Кнопка «Дополнительно» открывает расширенный диалог с разными узлами под разные протоколы: HTTP, HTTPS, FTP и SOCKS. В повседневной работе нужно редко, а в парсинге или тестировании рекламы очень даже. Обычный сёрфинг гоните через один узел, POST-запросы к нужному сервису - через другой, с другой геолокацией.
Там же поле «Исключения». Через точку с запятой перечисляете адреса и маски, которые должны идти напрямую: внутренние домены компании, тестовые стенды, локальные сервисы на самом компьютере. Синтаксис простой, но народ регулярно ломает себе доступ к staging-серверу: тот резолвится во внутренний адрес и лезет через внешний прокси.
SOCKS5 против HTTP: разница в архитектуре, а не в скорости
В поле «Порт» вы вписываете число, но за этим числом стоит протокол. Их путают чаще, чем хотелось бы. Если провайдер выдал SOCKS5, а вы вписали его в системные настройки Windows как обычный прокси, работать может, а может и нет: системный клиент по умолчанию говорит на HTTP.
HTTP-прокси работает на уровне приложения. Он читает заголовки, понимает метод запроса, умеет кешировать ответы и подставлять свои заголовки. Удобно, но видит больше, чем нужно, и на каждое HTTPS-соединение требует отдельного CONNECT-туннеля. Отсюда лишние хендшейки и заметная прибавка к задержке, особенно если узел далеко.
SOCKS5 работает на транспортном уровне. Содержимое он не разбирает, просто туннелирует TCP-соединения, а при необходимости и UDP. Заголовки, куки и тело запроса остаются зашифрованными внутри TLS. Для парсинга и работы с API это предпочтительный вариант: меньше оверхеда, стабильнее соединения, DNS-запрос резолвится на стороне узла, а не у вас.
По задержке разница на глаз небольшая, десятки миллисекунд. При тысяче параллельных запросов она превращается в минуты. Гоняете сбор данных или проверяете выдачу по регионам - берите SOCKS5 с удалённым резолвом DNS. Задача бытовая, посмотреть сайт с другого гео - хватит HTTP.
Для тех, кому нужны узлы под конкретный протокол и конкретную страну, есть каталог прокси с фильтрами по типу, гео и протоколу. Удобно тем, что не надо держать в голове соответствие портов - всё подписано.
Системный прокси не равно прокси в браузере
Windows-настройка действует на всё, что использует системный стек WinHTTP и WinINET. Chrome и Edge по умолчанию берут настройки оттуда, поэтому после включения галочки в «Параметрах» сразу идут через прокси. Firefox живёт своей жизнью и слушает систему только если явно попросить.
В Firefox это «Настройки», раздел «Основные», самый низ, «Настройки сети» и кнопка «Настроить». Там ручной режим, отдельные поля для HTTP, SSL и SOCKS-хоста, и чекбокс «Проксировать DNS при использовании SOCKS5». Последний пункт ставить обязательно. Иначе запросы к DNS уйдут мимо туннеля, и вы получите эффект «IP поменялся, а сайт отдаёт мой регион».
Смысл разделять браузер и систему простой. Нужен прокси для одной задачи, скажем, для проверки рекламных объявлений в другом гео - незачем гнать через него весь трафик машины, включая корпоративную почту и мессенджеры. Отдельный профиль в браузере со своими настройками решает это чище и быстрее.
Мессенджеры: где именно живёт настройка
Telegram Desktop держит собственный раздел с прокси, независимый от системного. «Настройки», «Продвинутые настройки», «Тип подключения», «Прокси», «Добавить прокси». Выбираете тип, вводите хост, порт, при необходимости логин и пароль, сохраняете и включаете переключателем. Приложение само проверит соединение и покажет пинг.
Поддерживается не только SOCKS5 и HTTP, но и MTProto, фирменный протокол мессенджера. Он заточен под мобильные сети: короткие пакеты, минимум лишних рукопожатий, устойчивость к переподключениям. Для публичного Wi-Fi в отеле или аэропорту MTProto через собственный узел даёт предсказуемый результат. А вот через случайный HTTP-прокси из открытого списка лучше не ходить: логин с паролем уходят в открытом виде.
WhatsApp Desktop отдельной настройки не имеет. Это приложение на Chromium, оно наследует системный прокси Windows. Настроили в «Параметрах», перезапустили клиент - всё подхватилось. Не подхватилось - проверьте, не запущен ли параллельно VPN: он перехватывает маршрут раньше.
Тонкая маршрутизация: когда прокси нужен только одной программе
Гнать через внешний узел весь системный трафик часто вредно. Ломается корпоративный VPN, отваливается 1С, тормозит обновление системы. В таких случаях берут клиенты с правилами маршрутизации: добавляете правило, указываете в нём .exe-файл программы через «Обзор», выбираете действие, то есть нужный прокси из списка, и сохраняете.
Логика простая: остальной трафик идёт напрямую. Так удобно разделять парсер на Python и рабочий браузер или два мессенджера через два разных узла. Плюс такие клиенты обычно сами подставляют логин с паролем, и вводить их руками в каждом приложении не надо.
Когда системный прокси реально нужен
Первый сценарий - публичный Wi-Fi. Кафе, коворкинг, аэропорт. Свой узел на VPS с шифрованием даёт предсказуемый канал: трафик идёт через вашу машину, а не через оборудование точки доступа, и логины не гуляют по открытой сети.
Второй - корпоративный шлюз. Компания поднимает выходной узел, и весь офисный трафик идёт через него. На каждой машине прописывается один и тот же адрес и порт, а логика доступа и логирования живёт на стороне шлюза.
Третий - задачи с геопривязкой. Проверить, как выглядит выдача в другом городе, посмотреть цены на маркетплейсе глазами покупателя из конкретного региона, протестировать объявление. Здесь важен не факт прокси, а его происхождение. Датацентровый адрес крупные сервисы распознают быстро, резидентный или мобильный выглядит правдоподобнее. На Reddit в тредах по сбору данных это обсуждают постоянно: люди меняют софт, а проблема оказывается в типе узла.
Четвёртый - собственный сервер. Поднимаете узел на VPS, открываете порт, ставите авторизацию, получаете личный канал с известной географией. Работы на полчаса, зато потом не зависите от чужих лимитов.
Пять ошибок, которые я вижу чаще всего
- Логин и пароль вставляют в поле адреса. Так не работает: авторизация вводится в отдельном окне при первом подключении, в расширенных настройках или в самом приложении.
- Путают протоколы. Провайдер выдал SOCKS5, а человек вписал узел в системный HTTP-клиент и удивляется тишине в ответ.
- Забывают про исключения. Корпоративный портал, локальный NAS и внутренние сервисы начинают ходить через внешний узел и, разумеется, не открываются.
- Оставляют включённым автопоиск скрипта. Система параллельно ищет PAC-файл и иногда находит не тот.
- Не проверяют DNS. IP поменялся, а запросы к доменам уходят через домашнего провайдера, и вся геопривязка летит в трубу.
Есть и шестая, менее очевидная. Люди покупают прокси и не проверяют, живой ли он, до того как прописать его в систему. Нормальный провайдер даёт тестовый запрос или пробный период - потратьте на это две минуты. Мёртвый узел в системных настройках выглядит как «интернет пропал», и вы будете искать проблему в драйверах сетевой карты.
Где брать цифры и как не переплатить
В личном кабинете провайдера вы получаете строку: адрес, порт, логин, пароль, протокол, гео. Иногда там же есть готовая ссылка на список для автоподстановки. Я советую вбивать руками, чтобы понимать, что именно у вас настроено. И сверяйте протокол: в кабинете SOCKS5, а в системе настроен HTTP - чуда не случится.
По типам узлов расклад такой. Датацентровые быстрые и дешёвые, но легко детектируются крупными площадками. Резидентные выглядят как обычные домашние подключения, их берут для проверки выдач, цен и рекламы; стоят дороже и работают медленнее. Мобильные самые «живые» с точки зрения сайта, но и самые дорогие, их берут точечно под конкретную задачу.
При выборе смотрите на три вещи: география совпадает с задачей, лимит одновременных потоков покрывает нагрузку, ротация адресов предсказуемая. Платите за месяц и упираетесь в лимит потоков на второй день - это не прокси плохие, это тариф не тот.
Подобрать под конкретную задачу можно в каталоге прокси: там фильтры по стране, типу, протоколу и объёму, так что перебирать вслепую не придётся.
Что сделать прямо сейчас
Откройте Win+I, дойдите до «Прокси», снимите автопоиск, включите ручной режим, впишите адрес и порт по отдельности. Сохраните. Новая вкладка, проверка IP и DNS. Город сменился и утечек нет - всё готово, можно работать.
Не сменился - вернитесь и проверьте три вещи по очереди: правильный ли порт для вашего протокола, не перехватывает ли маршрут VPN, не осталась ли включённой автоматическая настройка. В девяти случаях из десяти причина в одном из этих трёх пунктов, а не в провайдере.
И запишите исходные настройки до включения. Через месяц, когда понадобится вернуть всё как было, скажете себе спасибо.