Прокси включён в системном трее, а целевой сайт внутри отдельной программы всё равно видит настоящий адрес — типичная жалоба, когда прокси настраивался как в браузере, без учёта того, что приложение читает сетевые настройки иначе. Разберём три уровня, на которых работает прокси, какие программы обходят системный туннель, как заметить утечку и когда одного общего туннеля на все приложения недостаточно.
Три уровня: браузер, приложение, система
Прокси в браузере настраивается через сам браузер или расширение и действует только на трафик, который браузер отправляет сам — вкладки, встроенные загрузки, иногда расширения с отдельным доступом к сети. На соседнюю программу эта настройка не распространяется вообще.
Прокси на уровне приложения — это поле для адреса и порта внутри самой программы: антидетект-браузер, торрент-клиент, менеджер аккаунтов. Такой прокси действует только для этой программы и не требует системного туннеля, но работает лишь если разработчик вообще предусмотрел это поле.
Системный туннель — это изменение таблицы маршрутизации на уровне операционной системы или отдельный TUN-адаптер: он перехватывает исходящие соединения всех программ разом, независимо от того, поддерживает ли конкретное приложение прокси-настройки в принципе. Но и здесь есть нюанс: часть программ читает системный прокси через одну библиотеку сетевого стека, часть — через другую, а часть игнорирует и то и другое.
Какие приложения игнорируют системные настройки
Фоновые службы автообновления почти всегда обращаются к серверу обновлений напрямую по зашитому адресу, минуя и системный прокси, и туннель. То же самое касается некоторых игровых клиентов, эмуляторов и части программ, собранных на собственном сетевом стеке, а не на стандартных системных библиотеках — они попросту не читают ни переменные окружения, ни настройки трея.
Консольные утилиты и скрипты обычно требуют явного указания прокси в конфиге или переменной окружения — системный туннель их перехватит, но точечная настройка через параметры программы этого не сделает. Антидетект-браузеры и инструменты мультиаккаунтинга обычно устроены иначе: у них есть собственное поле прокси на профиль, и это плюс, а не проблема — подробный порядок настройки разобран в статье прокси для антидетект-браузера пошагово.
Утечки в обход туннеля и как их заметить
DNS-утечка — самая частая: приложение резолвит домен через системный DNS-сервер, минуя туннель, и по запросу к резолверу видно провайдера и реальную сеть, даже если сами данные потом идут через прокси. IPv6-утечка возникает, когда туннель настроен только на IPv4-трафик, а у приложения есть отдельный IPv6-маршрут — соединение уходит напрямую, разница между версиями протокола и её последствия для прокси разобраны в статье IPv4 против IPv6 на практике.
Отдельная категория — фоновые процессы и телеметрия внутри самой программы: интерфейс использует заданный прокси, а служебные соединения приложения идут напрямую. Заметить утечку можно только через журнал сетевого монитора или файрвола: если в списке исходящих соединений есть адреса, отличные от IP прокси, часть трафика идёт в обход.
Как проверить, что трафик реально идёт через прокси
Проверка через браузер ничего не говорит о том, что видит отдельное приложение — сервис определения IP нужно открывать именно внутри проверяемой программы, если это возможно, или смотреть, какой адрес видит целевой сайт, к которому программа обращается. Второй способ — список исходящих соединений в диспетчере задач или файрволе: любое соединение, идущее не на адрес и порт прокси, означает обход.
Надёжнее всего использовать выделенный порт с уникальной сессией: если адрес, который видит целевой сервис, не совпадает с тем, что должен отдавать этот порт, утечка очевидна сразу, без дополнительных сервисов проверки. Общие метрики качества канала для такой проверки разобраны в статье как проверить качество прокси.
Когда нужен отдельный порт на приложение
Один общий системный туннель с одним адресом не подходит, если одновременно запущено несколько изолированных профилей или программ, каждой из которых нужен собственный IP — это тот же принцип, что и при работе с несколькими антидетект-профилями. Локальный прокси-менеджер решает это привязкой отдельного локального порта к своему адресу для каждого приложения, так что все программы работают параллельно и не пересекаются по IP.
Для автоматизации с ротацией адресов по расписанию или по запросу тот же принцип работает через API: каждому сценарию — свой порт с собственным управлением сессией, без завязки на системный туннель целиком. Порядок настройки ротации через API — в статье как настроить ротацию IP по API.
Частые вопросы
Чем системный туннель отличается от прокси в браузере?
Прокси в браузере действует только на трафик самого браузера. Системный туннель меняет маршрутизацию на уровне операционной системы и по умолчанию перехватывает исходящие соединения всех программ — но только тех, что не используют собственный сетевой стек в обход системного.
Как понять, что конкретное приложение не использует заданный прокси?
Через журнал сетевого монитора или файрвола: если видны соединения на адреса, отличные от адреса и порта прокси, часть трафика программы идёт напрямую. Второй способ — сравнить IP, который видит сама программа или целевой сайт, с ожидаемым адресом прокси.
Нужно ли перезапускать приложение после смены прокси?
Часто да. Многие программы читают прокси-настройки один раз при старте — из системных параметров, конфига или переменной окружения — и не подхватывают изменения на лету. Пока приложение не перезапущено, оно может продолжать работать по старому маршруту.
Выделенные адреса и отдельные порты под каждое приложение или профиль — в разделе прокси. Там же можно подобрать канал под конкретную задачу: от системного туннеля на все программы до точечного порта на одно приложение.