Диалог с нейросетью выглядит как обычная веб-страница, но ведёт себя совершенно иначе. Обычный сайт — это десятки коротких запросов: загрузились картинки, стили, скрипты, соединения закрылись. Ответ языковой модели приходит одним потоком, который держится открытым минутами, и данные в нём идут редкими короткими порциями — по мере того как модель генерирует текст.

Для сети это нагрузка непривычного вида. И ломается она в местах, где обычный сёрфинг проблем не создаёт.

Как ответ доходит до экрана

Почти все чат-интерфейсы используют Server-Sent Events: браузер открывает одно HTTP-соединение и держит его, а сервер дописывает в него куски текста по мере готовности. Реже применяются веб-сокеты — суть та же.

Ключевое свойство: соединение долгое и почти пустое. Между двумя порциями текста может пройти несколько секунд, а если модель «думает» перед ответом — то и десятки секунд полной тишины при формально живом соединении.

Именно эта тишина и создаёт проблемы.

Причина первая: тайм-аут NAT

Каждый роутер по пути держит таблицу трансляции адресов. Запись в ней живёт, пока по соединению идёт трафик, и удаляется по тайм-ауту простоя. Для UDP этот тайм-аут обычно 30–60 секунд, у мобильных операторов бывает и меньше.

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

Лечится это регулярными служебными пакетами. В WireGuard за них отвечает параметр:

[Peer]
PersistentKeepalive = 25

Двадцать пять секунд выбраны не случайно — это заведомо меньше самого короткого распространённого тайм-аута. Пакет крошечный, батарею почти не расходует, а запись в таблице NAT держит живой. Если в конфиге этой строки нет, для долгих сессий её стоит добавить.

Причина вторая: MTU

Туннель добавляет к каждому пакету собственные заголовки. У WireGuard это 60 байт для IPv4: 20 на IP, 8 на UDP, 32 на сам протокол. Если внутри туннеля остался стандартный размер 1500, итоговый пакет в него не влезает — и должен быть фрагментирован или отброшен.

В теории есть механизм обнаружения MTU по пути. На практике он часто не работает: промежуточные узлы молча выбрасывают служебные ICMP-сообщения, и получается «чёрная дыра» — мелкие пакеты проходят, крупные исчезают без следа.

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

Значение 1280 байт — безопасный ориентир: это минимальный MTU, гарантированный для IPv6, и его обязан пропускать любой маршрут в интернете. Потеря пропускной способности от такого запаса измеряется процентами, а зависших запросов не остаётся.

Причина третья: UDP не везде равноправен

WireGuard работает поверх UDP и другого транспорта не предусматривает. Обычно это преимущество — меньше накладных расходов, выше скорость. Но часть мобильных сетей и корпоративных фильтров обращается с UDP хуже, чем с TCP: режет полосу, повышает потери под нагрузкой, а иногда пропускает только известные порты вроде DNS.

Короткому запросу это почти не мешает — потерянный пакет переспросят. Долгому потоку мешает заметно: рост потерь растягивает ответ и повышает шанс, что соединение оборвётся целиком.

Что с этим делать

Порядок действий, от простого к сложному:

  1. Проверить PersistentKeepalive. Нет строки — добавить 25. Самая частая причина обрывов «в тишине».
  2. Снизить MTU. Начать с 1280. Если после этого зависания прекратились — дело было в нём, и можно осторожно поднимать значение, ища предел.
  3. Сменить транспорт. Если сеть плохо обращается с UDP, никакая настройка внутри WireGuard это не исправит — ограничение снаружи.

Третий пункт и есть аргумент в пользу стека Xray с VLESS и XHTTP для такой нагрузки. Транспорт XHTTP работает поверх обычных HTTP-запросов по TCP, то есть ровно поверх того, для чего долгие соединения и придумывались: механизмы удержания сессии, повторной передачи и восстановления встроены в сам протокол, а не надстроены сверху.

Для фильтрующего оборудования поток выглядит как обращение к обычному сайту по HTTPS. Значит, он не попадает под правила, которые применяются к неопознанному UDP, — и ведёт себя стабильнее там, где WireGuard начинает терять пакеты.

Плата за это — накладные расходы TCP и чуть более высокая задержка. Для скачивания файлов и видео разница в пользу WireGuard. Для долгого диалога с моделью, где важна не пиковая скорость, а непрерывность, — в пользу VLESS.

Отдельно про региональные ограничения

Многие ИИ-сервисы ограничивают работу по регионам на своей стороне: смотрят, откуда пришёл запрос, и отказывают, если страна не в списке поддерживаемых. Это решение самого сервиса, а не сетевой фильтр.

Отсюда два практических следствия. Первое: важен не только сам факт подключения, но и стабильность адреса — сервисы с авторизацией нервно реагируют, когда сессия скачет между странами, и просят подтвердить вход заново. Второе: постоянный выходной узел в одном регионе удобнее, чем автоматическое переключение между локациями.

Коротко

Долгий поток данных — отдельный класс нагрузки, и обычные настройки под него не рассчитаны. Три вещи закрывают большинство обрывов: PersistentKeepalive против тайм-аутов NAT, сниженный MTU против «чёрных дыр» фрагментации и переход на TCP-транспорт там, где сеть плохо обращается с UDP. Первые две — правка двух строк в конфиге, третья — смена протокола.