TUIC подключен, но нет интернета: DNS и маршрутизация

Почему TUIC подключен, но интернет не работает

Протокол TUIC (Tunnel with UDP-based Instant Connection) использует QUIC в качестве транспорта, что обеспечивает высокую скорость и стабильность. Однако после успешного подключения клиент часто сталкивается с тем, что браузер выдаёт ошибки, сайты не открываются, хотя «подключение активно». Это типичная ситуация, и в 90% случаев причина кроется в неправильной настройке DNS или маршрутизации, а не в самом TUIC.

Дело в том, что TUIC — это лишь транспортная прослойка (аналог V2Ray/Shadowsocks). Он не выполняет функции резолвера и не определяет, какие адреса идут через туннель. Эти вопросы решает клиентское приложение, например sing-box, Clash Meta, NEKO или другой фронтенд. Если клиент неправильно маршрутизирует трафик или не отправляет DNS-запросы в туннель, возникает ситуация, когда виртуальный адаптер TUN поднят, но интернет недоступен.

Быстрая диагностика: что уже работает?

Перед тем как углубляться в настройки, выполните несколько простых шагов, чтобы понять, где именно возникает проблема.

• Проверьте, видит ли клиент сервер: ping -c 3 ваш_сервер или tcping server_ip 443. Если пинги не проходят, возможно, сервер недоступен или блокируется порт.
• Попробуйте подключиться к серверу через IP-адрес вместо домена. Если так работает, проблема в DNS.
• Включите режим «global» или «прямое подключение» в клиенте. Если сайты открываются, значит, проблема именно в маршрутизации.
• Проверьте, работает ли UDP: используйте nc -u server_ip 443. TUIC работает поверх QUIC, поэтому без UDP нет соединения.

Если первые три пункта указывают на нормальное соединение, а интернета нет, переходите к DNS.

Настройка DNS в TUIC-клиентах

TUIC сам по себе не обрабатывает DNS — это задача клиента. Однако большинство современных клиентов используют TUN-режим, который перехватывает весь трафик, включая DNS-запросы. Если TUN-режим включён, но DNS не настроен, система будет использовать системный DNS (обычно от провайдера), и запросы будут идти в обход туннеля. В результате сайты не резолвятся, хотя само соединение активно.

Рекомендуется настроить DNS-сервер внутри туннеля. В sing-box конфигурация выглядит так:

{"dns": {"servers": [{"tag": "TUIC-DNS", "address": "https://8.8.8.8/dns-query", "detour": "proxy"}, {"tag": "local", "address": "223.5.5.5", "detour": "direct"}], "strategy": "prefer_ipv4", "final": "TUIC-DNS"}}

В этом примере все DNS-запросы идут через прокси (detour: "proxy"), а для прямых соединений используется локальный DNS. Обратите внимание: адрес 8.8.8.8 не заблокирован в некоторых странах, но если ваш провайдер блокирует DoH, используйте https://cloudflare-dns.com/dns-query или другие доступные эндпоинты.

После изменения конфигурации обязательно перезапустите клиент. В интерфейсе sing-box или Clash Meta проверьте, что DNS-сервер активен.

Маршрутизация: какие правила пакетов блокируют доступ?

Даже если DNS настроен, трафик может не пойти через туннель из-за неправильных правил маршрутизации. Например, many клиентов по умолчанию оставляют частные подсети (192.168.0.0/16, 10.0.0.0/8) в direct. Если ваш сайт резолвится в такой IP (например, локальный сервер), он не пойдёт через TUIC. Но чаще всего проблема в том, что весь трафик должен идти в proxy, а правило final указывает на direct.

Проверьте раздел route в sing-box:

{"route": {"rules": [{"protocol": "dns", "action": "sniff"}, {"ip_cidr": ["192.168.0.0/16", "10.0.0.0/8"], "outbound": "direct"}], "final": "proxy"}}

Здесь ключевое — "final": "proxy". Весь трафик, не подлежащий прямым правилам, идёт через TUIC. Если у вас стоит direct, все несовпадающие пакеты выйдут напрямую, и интернет работать не будет.

Настройки сервера и сетевые условия

Часто проблема в сервере. TUIC требует, чтобы UDP-порт был открыт и не блокировался. QUIC использует UDP, поэтому многие файрволы и провайдеры могут его ограничивать. Убедитесь, что на сервере разрешён входящий UDP-трафик на порт TUIC (обычно 443). Проверьте с помощью iptables -L или ufw status.

Также важно, чтобы на сервере не было двойного NAT или блокировки QUIC от DPI. Некоторые интернет-провайдеры блокируют non-HTTP/3 QUIC. Используйте TLS-сертификат, который выглядит как обычный HTTPS, чтобы снизить детектирование. TUIC поддерживает TSL 1.3, и если сертификат валиден, это повышает вероятность, что трафик будет маскирован под обычный QUIC.

Проверьте версию TUIC на сервере: устаревшая версия может иметь проблемы совместимости с клиентом. Загляните в репозиторий TUIC GitHub для актуальной информации.

Частые ошибки и как их исправить

Соберём распространённые причины, из-за которых TUIC подключен, но нет интернета.

• Отключён UDP-проброс на сервере — проверьте правила файрвола, разрешите входящий UDP. Используйте nc -zulv для теста.
• Неправильный DNS-сервер в конфиге клиента — укажите доступный DNS, который не блокируется провайдером. Лучше всего DoH или DoT.
• Маршрутизация в обход туннеля — правило final должно быть proxy, а системные DNS исключены из правил.
• Конфликт TUN и DNS — если не включён TUN, клиент может не перехватывать DNS. Включите TUN и разрешите перехват.
• Несовместимый TLS-сертификат — используйте сертификат от Let's Encrypt, а не самоподписанный, особенно для маскировки.
• Ошибка в параметрах UUID/password — проверьте, что UUID и пароль совпадают на клиенте и сервере. Неверные данные приведут к отключению ещё на этапе рукопожатия, но иногда клиент сообщает об успехе из-за кэша.

Если после всех проверок интернет так и не появился, соберите логи клиента и сервера. Oбратите внимание на строки, содержащие dns или route. Систематическое логирование помогает быстро локализовать проблему.

Заключение

Когда TUIC подключен, но нет интернета, в первую очередь проверяйте DNS и маршрутизацию. Убедитесь, что DNS-запросы идут через прокси, а не через системный резолвер, и что правило маршрутизации отправляет трафик в TUIC. Также следите за состоянием UDP-канала и актуальностью версий TUIC. Помните: TUIC — лишь транспорт, поэтому вся логика сетевого уровня сосредоточена в клиенте.