Включил VPN - прокси умер через десять секунд
Настроил прокси, всё летает, задержка минимальная. Включаешь VPN для работы или потому что сидишь в кафе на публичном Wi-Fi. Через десять секунд прокси отвечает таймаутом. Отключаешь VPN - снова живой.
Магии здесь нет. Два тоннеля дерутся за один сетевой стек. Я видел этот сценарий десятки раз: у маркетологов с парсерами, у сисадминов с корпоративными узлами, у фрилансеров из кофеен.
Прокси и VPN решают разные задачи, но лезут в одни и те же настройки операционной системы. Когда два инструмента пишут в один конфиг, кто-то проигрывает. Обычно тот, который настроили раньше.
Два тоннеля в один сетевой интерфейс не помещаются
VPN при подключении создаёт виртуальный интерфейс: TUN на Linux и macOS, TAP или Wintun на Windows. Первое, что делает клиент после поднятия интерфейса, - переписывает маршрут по умолчанию на себя. Трафик, который раньше шёл напрямую к прокси-серверу, теперь уходит в тоннель. Дальше два варианта.
Первый: прокси-сервер доступен через тоннель, и трафик до него идёт в двойной обёртке. Пакет заворачивается в SOCKS5, потом в шифрованный тоннель, на выходе распаковывается, а внутри ещё один слой. Скорость падает в полтора-два раза. Часть провайдеров прокси такие соединения просто отбивает по таймауту рукопожатия.
Второй вариант хуже. Маршрут до прокси уходит в тоннель, но сам прокси-сервер не принимает соединения из подсети VPN. Клиент стучится, ответа нет, соединение висит. В браузере ты видишь стандартную ошибку прокси, хотя узел полностью рабочий.
Проверяется в две команды. На Windows: route print, смотришь, куда указывает маршрут 0.0.0.0. На macOS и Linux: netstat -rn или ip route. Если дефолт ушёл на адрес тоннеля из приватного диапазона, значит VPN забрал всё, включая дорогу до прокси.
DNS резолвится не тем сервером, и прокси «не отвечает»
Классика, которую ловят единицы. VPN-клиент при подключении подсовывает свои DNS-серверы. Они живут внутри изолированного сегмента тоннеля и прекрасно резолвят имена, пока ты в этом тоннеле. А прокси-клиент, который работает вне тоннеля или в split-tunnel режиме, получает от системы именно эти адреса. И не может до них достучаться.
Итог: вводишь адрес прокси по имени, а не по IP, и получаешь ошибку резолвинга. На глаз это выглядит как «прокси перестал работать при включении VPN», хотя проблема вообще не в прокси.
Лечится принудительной установкой DNS на физическом интерфейсе. Windows: Панель управления, Сеть и Интернет, Центр управления сетями, Изменение параметров адаптера. Правой кнопкой по основному адаптеру, Свойства, Протокол Интернета версии 4, Свойства, и прописываешь свой DNS вручную. macOS: Системные настройки, Сеть, активное подключение, Дополнительно, DNS. Добавляешь адрес первым в списке.
Второй трюк: в большинстве клиентов VPN есть галочка вида «Использовать DNS только внутри тоннеля». Выключишь её - DNS утекает наружу и продолжает работать для остальных приложений.
MTU и фрагментация: почему SOCKS5 живёт, а MTProto умирает
Самая недооценённая причина. VPN-тоннель уменьшает полезный размер пакета. Стандартные 1500 байт ужимаются до 1420 или даже 1380, потому что часть места занимает заголовок инкапсуляции. Параметр не подстроен - крупные пакеты фрагментируются, а некоторые узлы фрагменты просто отбрасывают.
Почему страдает именно MTProto? Он держит постоянное соединение и гоняет пакеты с крупными полезными нагрузками. При неправильном MTU рукопожатие проходит, а на передаче файла или первом длинном сообщении соединение умирает. В Telegram видишь вечное «соединение» и никаких объяснений. В обсуждениях на Reddit сетевые инженеры отмечают ту же закономерность: половина «мёртвых» MTProto-узлов оживает после подбора MTU.
SOCKS5 терпеливее: он работает поверх TCP, и стек сам разруливает пересборку. Но при MTU ниже 1300 начинаются просадки по скорости, которые легко списать на «плохой прокси».
Что делать: в настройках VPN-клиента найди параметр MTU. Выставь 1400 и проверь. Стабильно - оставляй. На Linux MTU правится напрямую: ip link set dev tun0 mtu 1400. На роутере с OpenWrt то же самое в настройках интерфейса.
Kill switch душит всё, что не прошло через тоннель
Kill switch задуман как страховка: тоннель падает - весь трафик блокируется, чтобы ничего не утекло в открытом виде. Логика железная. Проблема в том, что kill switch не различает утёкший трафик и твой прокси-клиент, который по определению работает мимо тоннеля.
На Windows это правила фильтрации в WFP или настройки TAP-адаптера. В момент включения VPN применяется набор правил, который блокирует все исходящие соединения, кроме тех, что идут в тоннель. Прокси-клиент получает отказ на уровне ядра. В логах это выглядит как мгновенный connection refused.
На macOS та же история через pf, на Linux через iptables и nftables. Правило вида «блокировать всё, что не на tun0» рубит прокси-соединение без предупреждений. Типичная жалоба на форумах: «включил защиту - отвалился парсер». Это оно.
Решение: добавить исключение для адреса прокси-сервера в настройках kill switch. Опция есть в большинстве нормальных клиентов. Второй путь - отключить kill switch на время работы с прокси, но тогда страховки нет. Красивее первое: защита остаётся, прокси живёт.
Антивирус и файрвол видят подозрительный локальный порт
Многие прокси-клиенты поднимают локальный слушатель на loopback-адресе и перенаправляют трафик приложений через него. Антивирусы и корпоративные EDR такие слушатели не любят. Пока VPN выключен, правило либо не срабатывает, либо разрешено по старой памяти. После включения VPN сетевой профиль меняется с частного на публичный, и файрвол применяет другой набор правил.
В Windows это видно сразу: при первом подключении к новой сети выскакивает окошко с выбором профиля. Нажал «Нет» случайно или политика домена ставит профиль «Общедоступная» - локальные соединения начинают резаться.
Проверка простая. Открой настройки брандмауэра, раздел «Разрешить взаимодействие с приложением», найди свой прокси-клиент и убедись, что галочки стоят и для частных, и для общедоступных сетей. На macOS то же самое: Настройки, Сеть, Файрвол, Параметры, список приложений.
Отдельная история - антивирусы с функцией защиты сетевых подключений. Они пропускают весь трафик через свой фильтр. Поверх VPN-тоннеля двойная инспекция иногда ломает рукопожатие SOCKS5. Подозреваешь этот сценарий - отключи веб-щит на десять минут и проверь.
Два расширения в браузере конфликтуют за один сокет
Самая частая причина в бытовых сценариях. Стоит расширение для прокси и расширение для VPN. Оба лезут в настройки прокси браузера. Кто последний записал, тот и прав. При этом интерфейс обоих показывает «подключено», а трафик рвётся.
Chrome и Chromium-база: Настройки, Система, Открыть настройки прокси компьютера. Там видно, что реально прописано. Firefox держит собственную историю: Настройки, Основные, Настройки сети, Параметры подключения. Он может игнорировать системные настройки, и тогда получается полный раздрай.
Правило простое: одно расширение для сетевых настроек. Остальные выключи и проверь, вернулась ли работоспособность. Если да, включай по одному и смотри, на каком ломается.
Telegram и WhatsApp: где именно ломается интерфейс
В Telegram прокси настраивается отдельно от системных настроек, и это спасает. Открой Настройки, Данные и память, Прокси, Добавить прокси. Выбери тип MTProto или SOCKS5, вбей сервер, порт и секрет. Ниже есть переключатель «Использовать прокси для вызовов» - его лучше выключить, иначе голосовые звонки разваливаются при включённом VPN.
Отвалился прокси в Telegram после включения VPN - проверь три вещи по порядку. Первое: не стоит ли в системе глобальный режим VPN, который заворачивает всё. Второе: доходит ли до сервера ping, то есть живой ли маршрут. Третье: не сменился ли твой внешний адрес на выход VPN, который сервер прокси не принимает по своим правилам.
В WhatsApp путь такой: Настройки, Хранилище и данные, Прокси, Использовать прокси. Включаешь, вводишь адрес и порт. WhatsApp поверх прокси чувствителен к MTU и к качеству канала. При включённом VPN сначала подними MTU, потом уже жалуйся на прокси.
Чем архитектурно отличаются SOCKS5 и MTProto в этой связке
Понимание архитектуры экономит часы диагностики. SOCKS5 работает на пятом уровне модели OSI, это прокси-протокол без встроенного шифрования. Он пересылает TCP и UDP-сессии, а шифрование оставляет приложению. Схема предсказуемая: маршрут есть - соединение будет. Отсюда правило: SOCKS5 страдает от сетевых проблем, но не от программных конфликтов.
MTProto устроен иначе. Прикладной протокол со своей обфускацией и собственным рукопожатием, заточенный под мобильные сети с потерями. Держит долгоживущее соединение, чувствителен к задержке и к потере пакетов. Поверх VPN он начинает бороться за приоритет и за размер окна. Отсюда типичный симптом: соединение устанавливается, но через минуту рассыпается.
Для парсинга и работы с API бери SOCKS5. Для мобильных сценариев с нестабильной сетью MTProto выигрывает, но только при нормально настроенных MTU и DNS. Мешать оба протокола в одном приложении смысла нет.
Корпоративный сценарий: свой VPS и split tunneling
Прокси поднят на собственном VPS, а VPN нужен для доступа к корпоративной сети. Конфликт решается разделением маршрутов. Трафик до корпоративных подсетей идёт в тоннель, всё остальное, включая прокси, идёт напрямую через основной шлюз.
В OpenVPN это директива route-nopull в конфиге клиента плюс ручное добавление нужных маршрутов. В WireGuard проще: в секции AllowedIPs перечисляешь только корпоративные подсети, а не 0.0.0.0/0. Документация WireGuard прямо предупреждает: дефолтный маршрут на всё заворачивает весь трафик в тоннель. Именно на этом спотыкаются новички, скопировав конфиг из гайда.
Для защиты трафика в публичном Wi-Fi хватает полного тоннеля, но тогда прокси-сервер должен быть доступен изнутри VPN-подсети. Проверяется просто. Подключись к VPN и попробуй достучаться до прокси-сервера по его адресу вне прокси-протокола, обычным запросом. Нет ответа - маршрут не тот, и настройки прокси тут не помогут.
Как локализовать причину за пятнадцать минут
Порядок, который я использую сам. Он отсекает девяносто процентов случаев. Не перескакивай через шаги: каждый следующий имеет смысл только после успешного предыдущего.
- Выключи VPN полностью. Проверь прокси. Работает - проблема в связке, а не в самом прокси.
- Включи VPN и посмотри таблицу маршрутов. Дефолт ушёл в тоннель, а прокси-сервер не входит в разрешённые подсети - причина найдена.
- Проверь DNS на основном интерфейсе. Там адреса из тоннеля, а split tunneling включён - резолвинг сломан.
- Снизь MTU до 1400 и повтори тест. Особенно если соединение устанавливается, но рвётся на передаче данных.
- Отключи kill switch на минуту. Вернулась работоспособность - добавь исключение для адреса прокси.
- Выключи все расширения для прокси и VPN в браузере, кроме одного. Проверь системные настройки прокси в браузере.
- Проверь правила файрвола и антивирус. Смени профиль сети с публичного на частный, если это домашняя сеть.
После всех семи шагов прокси всё ещё не отвечает - вопрос уже не в VPN. Скорее всего, узел недоступен, исчерпан лимит соединений или сменились правила на стороне сервера. Тогда дорога одна: проверять сам узел и брать новый.
Что делать, если стабильность важнее экономии
Половина проблем, которые годами лечат настройками, решается сменой поставщика. Публичные бесплатные узлы живут недолго: их перегружают, они уходят в бан, у них плавают задержки. В связке с VPN такой узел падает первым, потому что у него нет запаса по качеству канала.
Для рабочих задач я держу под рукой каталог прокси с фильтрами по стране, типу и назначению. Там есть SOCKS5 для парсинга и API, есть резидентские под задачи, где нужен живой IP, есть отдельные пулы под конкретные гео. Удобно тем, что можно взять один узел под тест, прогнать его в связке с твоим VPN и уже потом решать, нужен ли пакет.
Практический совет: под VPN-связку бери узлы с запасом по каналу и статичным IP. Динамические пулы в тоннеле ведут себя непредсказуемо: смена адреса на выходе ломает уже установленные сессии. Статичный адрес снимает эту проблему полностью.
Три шага вместо перебора галочек
Прокси не ломается от VPN магическим образом. Ломается маршрутизация, DNS, MTU или правила фильтрации. Найди, какой из четырёх слоёв рвётся у тебя, и почини именно его.
Дальше поступи так. Сначала зафиксируй рабочую конфигурацию без VPN и сохрани её скриншотом настроек. Потом включай VPN и меняй ровно один параметр за раз, начиная с MTU и DNS. И третье: под рабочую связку держи отдельный статичный узел, а не публичный, который падает от любого чиха.