Клиент присылает скриншот: прокси в браузере прописан, статус зелёный, расширение довольно урчит. А сайт всё равно здоровается по-русски и показывает цены в рублях. Полдня он менял значения в полях, пока не выяснилось: трафик шёл напрямую, а зелёный статус расширение рисовало по факту заполненных полей.
Знакомая история. Проверка прокси на ПК почти никогда не сводится к одной галочке, потому что решают три независимых слоя: операционная система, конкретное приложение и сам сервер на той стороне. Каждый живёт своей жизнью, и настройка одного ничего не говорит о двух других.
Сначала разберитесь, где именно вы ищете прокси
В Windows два разных механизма, и они не синхронизированы. Первый - WinINET, его настройки видят Chrome, Edge, Internet Explorer и часть десктопных программ. Второй - WinHTTP, отдельный стек для служб и системных компонентов. Плюс есть приложения, которые вообще не смотрят в систему: Firefox со своей вкладкой настроек, Telegram, торренты, скрипты на Python.
Отсюда типичный сценарий: человек прописал прокси в браузере через расширение, открыл сайт, увидел другую страну и успокоился. А потом его парсер на requests стучится напрямую с домашнего IP, потому что переменные окружения никто не выставлял. Каждый слой проверяется отдельно, и ниже ровно про это.
Команда netsh winhttp show proxy показывает не то, что вы думаете
Запускаете терминал от имени администратора, вводите netsh winhttp show proxy и получаете «Прямой доступ (нет прокси-сервера)». При этом браузер спокойно работает через узел. Человек лезет искать ошибку в прокси, хотя ошибся с инструментом измерения.
netsh отдаёт только настройки WinHTTP. Браузеры на Chromium туда не ходят, они берут параметры из пользовательского раздела системы. Зато эта команда показывает другое: ходит ли через узел системный трафик вроде обновлений, служебных запросов и фоновых агентов. Ждёте, что в корпоративной сети все службы пойдут через ваш узел, а netsh говорит «прямой доступ»? Значит половина трафика идёт мимо.
Рядом живёт ещё одна проверка, о которой забывают. netsh winhttp show proxy молчит про PAC-файл, а именно в нём часто зашита вся логика. Видите в ответе путь к скрипту настройки - откройте файл. Там может лежать список правил, где ваш домен идёт напрямую, а всё остальное через узел.
В параметрах Windows важны три переключателя, а не один
Пуск, Параметры, Сеть и Интернет, Прокси. На экране три блока, и каждый умеет перекрывать остальные. Первый - автоматическое определение параметров, тот самый WPAD, который ищет конфигурацию в локальной сети. Второй - скрипт настройки, куда вставляют адрес PAC-файла. Третий - ручная настройка с адресом и портом.
Практика: если включено автоматическое определение, а в сети есть DHCP-сервер, отдающий адрес конфигурации, ручные поля тихо игнорируются. Отсюда и берутся жалобы «настройки правильные, а не работает». Снимите галочку автоопределения, перезапустите браузер, проверьте снова.
В ручном режиме не забудьте про кнопку «Дополнительно». Там живут исключения и переключатель «Не использовать прокси для локальных адресов». Частая история: человек проверяет узел на локальном стенде, а система честно пускает запросы к localhost напрямую. И он делает вывод, что узел мёртв.
Браузер решает сам, и это ломает всю картину
Chrome и Edge смотрят в системные настройки, но у них есть своя дверца: chrome://settings/system и edge://settings/system, кнопка открытия параметров прокси компьютера. Проверять надо именно там, потому что расширения стоят отдельным этажом и перекрывают всё.
Расширение с надписью «Proxy» в панели задач может показывать подключение и при этом не работать. Минимум три сценария, когда статус зелёный, а трафик идёт напрямую: кончился оплаченный период на стороне сервиса, истёк токен авторизации, узел отвалился, а расширение не перепроверило соединение. Отключите все сетевые расширения и проверьте по новой. Заработало без них - виноват не прокси.
Firefox стоит особняком: Настройки, Основные, в самом низу Настройки сети, кнопка «Настроить». Там же режим «Использовать системные настройки прокси», ручная настройка и автоматическая по URL. Пользователи часто держат Firefox на системных настройках, а потом удивляются, почему в одном браузере гео одно, а в другом другое.
Онлайн-чекер отвечает на главный вопрос: идёт ли трафик через узел
Самая быстрая проверка вообще без настроек. Открываете whatismyipaddress.com или iplocation.net, записываете внешний IP и город. Отключаете прокси, обновляете страницу, смотрите снова. Адреса разные - трафик идёт через узел. Адрес совпал - не идёт, что бы вам ни говорили настройки.
Дальше картину уточняет proxycheck.io. Ваш адрес и порт он не покажет, зато скажет, числится ли IP в базах прокси и VPN, какой у него уровень риска и как давно он засветился. Для маркетплейсов, аналитики и рекламных кабинетов это важнее геолокации: чистый адрес из Нидерландов и адрес из тех же Нидерландов, но в двадцати чёрных списках, ведут себя совершенно по-разному.
Чего эти сервисы не умеют: показать адрес и порт вашего прокси. И не должны. Они видят только то, что до них дошло. Трафик завёрнут в цепочку из двух узлов - вы увидите выходной, а не тот, который прописали в системе.
Проверка конкретного сервера занимает 5-10 секунд и говорит больше, чем все остальные тесты
Второй тип проверки - чекер самого прокси. В поля вводите адрес, порт, при наличии логин и пароль. Многие сервисы принимают ввод по маске одной строкой через разделитель, это удобно, когда узлов десяток. Ответ приходит за 5-10 секунд, и в нём есть всё, что нужно для решения.
Смотрите на четыре вещи. Первое: живой или мёртвый, то есть поднимается ли TCP-соединение. Второе: протокол, который реально отвечает, HTTP, HTTPS или SOCKS5, потому что заявленный и фактический часто расходятся. Третье: уровень анонимности. Прозрачный прокси подставляет ваш настоящий адрес в заголовки, и вся работа с ним теряет смысл, даже если формально он «работает». Четвёртое: время отклика и то, резолвит ли узел DNS сам или сливает запросы наружу.
Отдельная ценность - проверка перед покупкой партии. Гоняете список через чекер, отбрасываете мёртвые и прозрачные, и только потом платите. Каталог прокси https://3seller.com/proxy удобен тем, что по каждому серверу видно тип, страну и срок аренды. Вы не покупаете кота в мешке, а сверяете заявленное с фактическим после первого же теста.
Утечки DNS, WebRTC и IPv6 рушат даже правильно настроенный прокси
Прокси работает, IP подменён, а сайт всё равно определяет ваш город. Классика. Причин три, и все три видны на browserleaks или whoer за один заход.
DNS. Если узел не резолвит имена сам, запросы уходят к провайдеру, и это видно по DNS-серверу в отчёте. Лечится либо удалённым резолвингом на стороне сервера, либо выбором SOCKS5, который тянет DNS через туннель.
WebRTC. Chrome умеет отдавать локальные и публичные адреса через отдельный канал, мимо прокси. В отчёте появляется ваш настоящий IP рядом с подменённым, и вот это уже провал. Отключается в настройках браузера или расширением, но проверять надо каждый раз после обновления.
IPv6. Прокси настроен на IPv4, а сайт доступен по IPv6, и браузер спокойно идёт напрямую. Пока такие сайты редки, но аналитические панели и CDN уже отдают IPv6 охотно. Не готовы возиться - отключите IPv6 в свойствах сетевого адаптера на время работы.
Скорость и стабильность: что мерить, а не что показывает спидтест
Задержка до узла - первое, что стоит смотреть. Пинг 15-30 мс до европейского сервера это норма, 200 мс и выше означает, что вы будете ждать загрузки каждой страницы. Проверяется обычным ping по адресу узла, без всякой магии.
Пропускная способность важна для загрузки файлов и видео, но для парсинга и работы с API она вторична. Там решает стабильность: сделайте 15-20 запросов подряд к одному и тому же адресу и посмотрите на разброс. Если один запрос из пяти падает по таймауту, никакая скорость не спасёт. Дешёвые публичные узлы ведут себя именно так: первый запрос бодрый, десятый уже висит.
Быстрая проверка из терминала без всяких настроек системы: curl с явным указанием прокси в командной строке. Он покажет и код ответа, и время, и то, что узел вообще отвечает. Удобно сравнивать два сервера между собой, не трогая параметры Windows.
SOCKS5 и MTProto: что именно вы проверяете с точки зрения архитектуры
SOCKS5 работает ниже уровня HTTP и просто туннелирует TCP-соединения. Ему всё равно, что внутри: HTTPS, SSH, игровой трафик. Заголовки он не переупаковывает, поэтому даёт меньшую задержку и меньше точек отказа. Авторизация по логину и паролю, поддержка UDP-ассоциаций для голоса и стриминга. Для парсинга, сбора цен и работы с API это самый предсказуемый вариант: узел не вмешивается в содержимое, не ломает подписи и не добавляет свои заголовки.
HTTP-прокси, наоборот, разбирает запрос и умеет кэшировать, фильтровать и логировать. В корпоративном контуре это плюс, в высоконагруженном сборе данных минус: лишняя обработка добавляет миллисекунды, а на тысячах запросов это часы.
MTProto это протокол Telegram со своим уровнем шифрования. Прокси-сервер тут видит только поток байтов и не может заглянуть внутрь, поэтому проверять его нужно иначе: не содержимым, а фактом установления соединения и стабильностью под нагрузкой. Секрет и порт задаются в клиенте, и если хоть один символ неверный, соединение просто не поднимется без внятной ошибки.
Пошагово в приложениях: куда нажимать
Telegram на десктопе: Настройки, Продвинутые настройки, Тип соединения, Прокси, кнопка «Добавить прокси». Выбираете тип, вводите сервер, порт, при необходимости логин, пароль и секрет для MTProto. Сохраняете и включаете переключателем. Проверка простая: в списке чатов появляется значок соединения, а в самом низу экрана настроек видна строка о том, что соединение установлено. Нет статуса через 10 секунд - креды или порт неверные, других вариантов почти не бывает.
Telegram на телефоне: Настройки, Данные и память, Прокси, добавить новое подключение. Логика та же. Держите в голове, что мобильный клиент может жить в другой сети, чем компьютер, и вести себя иначе.
WhatsApp: Настройки, Хранилище и данные, Прокси, включить «Использовать прокси», ввести адрес и порт. Этот параметр влияет на звонки, и проверять его надо звонком, а не текстовым сообщением, иначе выводы будут ложными.
Зачем это в обычной жизни: защита трафика в публичном Wi-Fi кафе или аэропорта, подключение к корпоративному узлу для доступа к внутренним ресурсам, работа с собственным VPS, когда нужно, чтобы исходящие запросы выглядели с адреса сервера. Сценарий один: указали параметры в приложении, убедились, что соединение установилось, и проверили чекером, что внешний адрес действительно изменился.
Грабли, на которые наступают почти все
Первый и главный: доверять статусу в интерфейсе. Любая зелёная надпись означает лишь то, что программа смогла записать настройки в конфиг. Реальное соединение проверяется только запросом наружу.
Второй: ошибка 407 Proxy Authentication Required. Это не про сеть и не про скорость, а про то, что логин с паролем не приняты. На Reddit в тредах по прокси-менеджерам всплывает неочевидный нюанс: чаще всего виновата кодировка спецсимволов в пароле. Решётка, собака или двоеточие ломают строку подключения, и клиент отправляет обрезанные данные. Меняйте пароль на алфавитно-цифровой и проверяйте снова.
Третий: публичные бесплатные узлы. Живут часами, половина уже в чёрных списках, капча вылезает на каждом втором сайте. Для разовой проверки «а как оно вообще работает» сойдёт, для работы нет. Срок жизни такого узла обычно меньше, чем время, которое вы потратите на его поиск.
Четвёртый: рассинхрон данных о вас. Прокси подменяет IP, но браузер продолжает отдавать московское время, русский язык интерфейса и разрешение экрана ноутбука. Часть сайтов склеивает это в один профиль и делает выводы, которые вам не понравятся. Если работа серьёзная, проверяйте не только адрес, но и часовой пояс, локаль и отпечаток браузера.
Короткий чек-лист перед началом работы
- Убедиться, что в системе реально прописан нужный узел, а не включено автоопределение.
- Прогнать адрес и порт через чекер и посмотреть тип, анонимность и время отклика.
- Сравнить внешний IP до и после включения, через сервис проверки адреса.
- Проверить утечки DNS, WebRTC и IPv6 на отдельной странице.
- Сделать 15-20 запросов подряд и посмотреть, не сыпется ли соединение.
- Повторить всё в том приложении, где реально будете работать, а не только в браузере.
Порядок именно такой. Пропустите третий пункт и сразу побежите к четвёртому - потратите полчаса на поиск утечки, которой нет. Или, наоборот, не заметите её и потом будете ловить странные ошибки на сайте.
Если возиться с десятком серверов вручную надоело, посмотрите каталог https://3seller.com/proxy. Там есть фильтры по стране и типу, по каждому узлу указан срок аренды. Можно взять один на пробу, прогнать по чек-листу выше и уже потом решать про пакет. Проверка занимает пять минут, зато дальше вы работаете с тем, что действительно отвечает, а не с зелёной галочкой, которая врёт.