SI sing-box Wiki Получить доступ
Быстрый старт Обновление Обновлено 6 мин Linux, Windows, macOS

sing-box 1.15: миграция TUN stack без потери подключения

Что меняет будущий TUN stack в sing-box 1.15, как проверить конфигурацию на тестовом устройстве и не потерять рабочий профиль.

sing-box1.15TUNalpha
Маршрут трафика через TUN и отдельный путь возврата к рабочей конфигурации
Проверка TUN-стека требует сохранённого пути отката.
Содержание
КороткоНа дату проверки 1.15 доступна как alpha, не как стабильный релиз. В новой ветке собственный стек sing-tun используется при отсутствии поля stack; меняйте его только в копии конфигурации и с планом отката.

Сначала проверьте канал релиза

На дату обновления статьи в официальном списке релизов 1.15 отмечена как alpha. Руководство Migration уже описывает изменение для будущей 1.15, но это не рекомендация переводить рабочий роутер или основной компьютер на предварительную сборку. Для production-подключения сначала дождитесь стабильного релиза и совместимости своего клиента.

Что происходит с полем stack

Раньше TUN-конфигурация могла выбирать stack со значениями system, gvisor или mixed. Согласно официальной Migration, с 1.15 sing-tun имеет собственный TCP/IP stack, который используется, если поле stack удалено. Само поле помечено deprecated в 1.15 и запланировано к удалению в 1.17. Удаление поля не равнозначно удалению TUN inbound или пересозданию профиля.

Не смешивайте это изменение с auto_route, auto_redirect, DNS-перехватом и исключениями интерфейсов: они определяют путь трафика и требуют отдельной проверки.

Безопасный тест на отдельном устройстве

Отдельное тестовое устройство и сетевые проверки перед миграцией TUN
Тестируйте новую ветку на отдельном устройстве и проверяйте восстановление сети.
  1. Сохраните файл JSON и работающий бинарник; запишите текущую версию клиента и core.
  2. На тестовом устройстве создайте копию конфигурации и удалите только stack в объекте type: tun.
  3. Проверьте копию соответствующим бинарником через sing-box check -c /path/to/config.json.
  4. Запустите TUN, затем проверьте DNS, локальную сеть, IPv4/IPv6 и одно приложение, которому требуется доступ.
  5. Остановите тест, убедитесь, что обычная сеть и системный DNS восстановились.

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

Когда откатываться

Откат нужен, если новый core не запускается, DNS уходит не тем путём, ломается доступ к локальной сети или после отключения клиента не восстанавливается системная сеть. Верните сохранённые бинарник и конфиг вместе, перезапустите сервис и проверьте обычный маршрут. Для удалённого роутера планируйте проверку с доступом к консоли, а не только через тот же туннель.

Проверено на практике

  • Дата проверки: 2026-09-29
  • Среда: Сверено с официальной Migration и GitHub Releases; локальный TUN не запускался
  • Версии: 1.15.0-alpha; стабильная 1.14.x

Мини-чеклист

  • Проверить, что 1.15 всё ещё alpha или стала stable
  • Тестировать копию конфига не на основном устройстве
  • Удалить только TUN stack, не менять одновременно DNS и route
  • Проверить восстановление сети после остановки
  • Хранить вместе старые бинарник и JSON

Частые ошибки

  • Считать раздел Migration подтверждением стабильного релиза
  • Менять stack, DNS и маршруты одновременно
  • Тестировать удалённый роутер без независимого доступа

Источники и документация

FAQ

Можно ли уже обновить рабочий сервер до 1.15?

На дату проверки опубликованы alpha-релизы; сначала сверяйте актуальный статус и тестируйте на отдельном устройстве.

Нужно ли удалять весь TUN inbound?

Нет. Руководство описывает удаление поля stack, а не всего TUN inbound.

Хотите перейти сразу к рабочему доступу?

Если сценарий уже ясен и не хочется проходить все шаги вручную, оформите доступ и проверьте подключение на своем устройстве.

Получить доступ

Дальше по теме

Связанные статьи