Системный прокси или TUN? Шесть реальных ситуаций, по одному ответу на каждую

Предыдущая статья объясняла, как работает TUN. Эта отвечает на один вопрос: в вашей ситуации что включать?

Сначала таблица.

Теперь обоснования.

1. Повседневный сёрфинг

Одного системного прокси достаточно.

Chrome, Edge и Firefox следуют системному прокси по умолчанию, так что один переключатель закрывает всё. TUN здесь ничего не добавляет и стоит вам лишнего процессорного времени плюс отдельного слоя обработки DNS.

2. Steam, Battle.net или Epic качают медленно

TUN обязателен.

Загрузчики игровых платформ работают с сокетами напрямую и полностью игнорируют системный прокси. Симптом характерный: страница магазина Steam открывается нормально (эта часть прошла через прокси), а загрузка ползёт на десятках КБ (загрузчик через прокси не пошёл и до сих пор бьётся за исходный международный маршрут).

3. Консольные инструменты зависают

git clone встал на 0%, npm install крутится, docker pull уходит в таймаут — ни один из них не читает системный прокси.

Два пути.

Путь А: включить TUN. Сделали один раз — и работает любой консольный инструмент.

Путь Б: задать переменные окружения. Легче, виртуальный адаптер не нужен:

# PowerShell (текущая сессия)
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"

# Отдельно для Git (постоянно)
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

# npm
npm config set proxy http://127.0.0.1:7897
npm config set https-proxy http://127.0.0.1:7897

Docker — особый случай: 127.0.0.1 внутри контейнера означает сам контейнер, а не хост. Используйте host.docker.internal либо просто включите TUN — последнее заметно проще.

4. Стриминг (Netflix, Disney+, HBO)

Системного прокси достаточно; TUN не нужен.

И веб-плееры, и десктопные приложения следуют системному прокси. А вот разблокируется ли контент, определяет совсем другое:

5. Сетевые игры

Включайте TUN, но держите ожидания в рамках.

Играм нужен UDP, системный прокси UDP не обрабатывает, так что TUN — единственный вариант. Но:

• Узел должен действительно пересылать UDP — многие дешёвые узлы этого не делают либо ограничивают
• Лишний хоп по определению добавляет задержку, если только ваш узел не сидит на выделенной линии IPLC/IEPL
• Некоторые античиты реагируют на виртуальные адаптеры

6. Ноутбук, которым управляет работодатель

С TUN будьте осторожны.

На корпоративных машинах обычно стоит EDR, VPN-клиент или доменная политика. TUN создаёт виртуальный адаптер и переписывает маршруты, что обычно даёт три вида проблем:

1. Конфликт с корпоративным VPN за маршруты и потеря доступа к внутренним ресурсам
2. Пометка и отправка отчёта от EDR о подозрительном сетевом поведении
3. Конфликт с настройкой прокси, навязанной доменной политикой

Если он вам всё-таки нужен:

• Пользуйтесь только системным прокси, без TUN
• Явно пометьте внутренние домены и диапазоны IP как DIRECT в правилах
• Сначала уточните у IT, разрешено ли это

Во что реально обходятся три сочетания

Разрыв невелик — современные машины его не заметят. Настоящая разница в сложности поведения: с работающим TUN у любой сетевой проблемы появляется ещё один слой, который надо исключить.

Средний вариант: только TUN, системный прокси выключен

Если вам нужны и игры, и браузер, попробуйте:

• TUN включён
• Системный прокси выключен

Тогда всё идёт одним путём, поведение однородно, диагностика проще. Плата за это — софт, явно написанный под «использовать системный прокси», может повести себя иначе, а расширения браузера, задающие собственный прокси (SwitchyOmega и подобные), способны обойти TUN.

Коротко

Если сомневаетесь — начните с системного прокси и добавляйте недостающее: отлаживать это куда проще, чем включать всё сразу.

Дальше: как работает режим TUN и раздача прокси по локальной сети.