Почему в v2RayN режим TUN не работает при использовании пресета «Russia»? 

При включении TUN-режима появляются ошибки — и в режиме set system proxy, и в режиме clear system proxy. Нейросеть предполагает, что проблема, скорее всего, в DNS. <br/> Вот текущие значения: <br/> Domestic DNS: 1.1.1.1 (поставил по рекомендации нейросети) <br/> Remote DNS: <a href="https://cloudflare-dns.com/dns-query" rel="nofollow">https://cloudflare-dns.com/dns-query</a> (читал, что Cloudflare надежен) <br/> Bootstrap DNS: не уверен, что это такое, стоит 77.88.8.8 <br/> Всё остальное в этой вкладке выключено и пусто. <br/> FakeIP включён. <br/> ==================================================== <br/> +0300 2026-04-06 23:22:54 ERROR [3847187123 2ms] connection: open connection to 149.154.167.255:443 using outbound/direct[direct]: dial tcp 149.154.167.255:443: connectex: The requested address is not valid in its context. <br/> +0300 2026-04-06 23:22:54 ERROR [1802317908 1ms] connection: open connection to 149.154.167.51:80 using outbound/direct[direct]: dial tcp 149.154.167.51:80: connectex: The requested address is not valid in its context. <br/> +0300 2026-04-06 23:22:54 ERROR [1329141017 1ms] connection: open connection to 149.154.167.41:80 using outbound/direct[direct]: dial tcp 149.154.167.41:80: connectex: The requested address is not valid in its context. <br/> +0300 2026-04-06 23:22:54 ERROR [1536288486 2ms] connection: open connection to 149.154.167.41:443 using outbound/direct[direct]: dial tcp 149.154.167.41:443: connectex: The requested address is not valid in its context. <br/> +0300 2026-04-06 23:22:54 ERROR [3313997047 2ms] connection: open connection to 149.154.167.255:80 using outbound/direct[direct]: dial tcp 149.154.167.255:80: connectex: The re
  • 7 апреля 2026 г. 15:01
Ответы на вопрос 1 
Коротко — причина видимо не в самом TUN, а в том, как разрешаются/маршрутизируются адреса при включённом TUN и FakeIP. Судя по логам, v2ray пытается открыть соединения к «неправильным» адресам (например 149.154.167.255 — это broadcast‑адрес в /24) и Windows возвращает ошибку “The requested address is not valid in its context”. Такое поведение обычно даёт одна из двух причин:

- DNS вернул некорректные/неожиданные A‑записи (включая .255 и т.п.), либо
- при включённом TUN пакеты/маршруты перенаправляются так, что исходящий интерфейс/локальный IP не подходит для этих подключений (исходный IP не привязан к интерфейсу, петля маршрутизации через TUN и т.п.).

Что проверить и как исправить (шаги по приоритету)

1) Быстрая проверка DNS
- Включите временно FakeIP = Off и снова включите TUN — если проблема уходит, дело в FakeIP / DNS.  
- Прогоните разрешение проблемных доменов вручную в CMD:
  - nslookup api.telegram.org 1.1.1.1
  - nslookup api.telegram.org 8.8.8.8
  Посмотрите, не возвращаются ли IP вида *.255 или явно неверные адреса.

2) Bootstrap + Remote DNS
- Remote DNS = https://cloudflare-dns.com/dns-query — корректно, но v2ray сначала должен разрешить cloudflare-dns.com. Для этого используется Bootstrap DNS. Если Bootstrap недоступен/неправильный — DoH не заработает.
- Рекомендация: поставьте Bootstrap DNS в 1.1.1.1 (или 8.8.8.8). Или ещё лучше — укажите Remote DNS через IP: https://1.1.1.1/dns-query и Bootstrap = 1.1.1.1, тогда нет необходимости резолвить hostname DoH.
- Можно временно заменить Remote DNS на простой UDP резолвер 1.1.1.1:53 и Bootstrap оставить пустым, чтобы исключить DoH как причину.

3) Маршруты / TUN‑поведение
- Откройте cmd (от имени администратора) и выполните route print. Посмотрите, не попали ли нужные сети в маршрут на TUN‑адаптер. Если TUN перехватывает исходящие пакеты и v2ray при direct outbound пытается соединяться через тот же TUN, получится петля/ошибка.
- Если вы используете пресет «Russia», он может пометить определённые диапазоны как direct. Убедитесь, что direct‑соединения идут через реальный сетевой адаптер, а не через TUN. В настройках v2RayN посмотрите опции TUN — есть параметры «redirect gateway» / «use default route» / исключения для локалки — попробуйте их переключить.

4) Логи и заполнение ошибок
- В логах видно outbound/direct[direct] — значит пакет классифицировался как direct, и v2ray пытался напрямую соединиться. Если target = *.255 — это явный сигнал, что резолвинг дал некорректный адрес (см. пункт 1).
- Сделайте тесты после правок и пришлите новые логи, если не получится.

5) Практические рекомендуемые настройки (пробные)
- FakeIP: off (проверка). Если после этого всё работает — причина в FakeIP/DNS.
- Remote DNS: https://1.1.1.1/dns-query
- Bootstrap DNS: 1.1.1.1
- Domestic DNS: можно оставить пустым или 1.1.1.1
- Если хотите UDP DNS: Remote DNS = 1.1.1.1:53, Bootstrap пустой.
- Перезапустите v2ray/v2RayN с правами администратора.

Если после этих действий остаётся проблема — пришлите:
- Вывод route print (cmd),
- Результат nslookup api.telegram.org 1.1.1.1 и nslookup ... 8.8.8.8,
- Полный фрагмент логов v2ray (несколько строк до и после ошибок),
- Версию v2Ray core и v2RayN.

По логике первых признаков: начните с исправления bootstrap → remote DoH (использовать IP) и временного отключения FakeIP — это чаще всего решает появление «странных» IP (включая .255) и ошибки connectex.
Похожие вопросы
    Показать ещё