Быстрый старт Обновление Обновлено 7 мин Linux, macOS, Windows

sing-box 1.14: что изменилось и как подготовить конфиг к обновлению

Перед обновлением sing-box до 1.14 проверьте DNS-правила, кэш и сертификаты, сохраните рабочий конфиг и только затем переключайте сервис.

sing-box1.14миграцияDNS
Схема проверки конфигурации перед обновлением sing-box 1.14 и сохранения отката
Проверяйте новую конфигурацию отдельно от рабочей и сохраняйте путь отката.
Содержание
КороткоСначала сохраните старый бинарник и конфиг. В 1.14 особенно проверьте несовместимые сочетания старых DNS-фильтров с новыми правилами, а также устаревшие поля кэша.

Что проверить до обновления

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

В официальном руководстве 1.14 перечислены разные изменения. Не нужно механически применять каждый пункт к любому конфигу: ищите в своём JSON только реально используемые поля.

DNS-правила: сначала ищите несовместимые сочетания

DNS-запрос проходит оценку ответа перед выбором локального или удалённого резолвера
Адресные DNS-правила нужно сопоставить с оценкой ответа, прежде чем менять маршрут.

В 1.14 старые фильтры адресов в DNS-правилах нельзя бездумно сочетать с новыми возможностями вроде evaluate, match_response и ip_version. Если правила зависят от ответа DNS или GeoIP rule-set, сопоставьте их с разделом «Migrate address filter fields to response matching» официальной миграции. Ошибка здесь проявляется ещё при старте конфигурации; простое удаление одного условия может поменять маршрутизацию и не считается исправлением.

Точно так же проверьте query_type: после изменения поведения старое условие может применяться и к внутреннему разрешению домена. Сравните ожидаемый путь DNS-запроса до и после обновления.

Кэш и сертификаты

Если в dns есть independent_cache, в 1.14 это устаревшее поле; руководство предлагает его убрать. Для experimental.cache_file.store_rdrc предусмотрена замена на store_dns. Не меняйте кэш и DNS-правила одновременно: сначала получите валидный конфиг, затем проверяйте поведение запросов.

В конфигурациях с inline ACME есть отдельная миграция на certificate provider. Это касается только тех, кто действительно выпускает сертификат через sing-box; обычному клиентскому профилю без ACME такой блок добавлять не надо.

Порядок проверки и отката

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

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

Что не нужно смешивать

Миграция 1.14 не означает автоматический переход на будущий TUN stack из 1.15. Это отдельное изменение, которое пока нужно рассматривать только в контексте версии и релизного канала. Если основная проблема — работа TUN или запуск на роутере, переходите к соответствующему узкому руководству.

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

  • Дата проверки: 2026-09-29
  • Среда: Сопоставлено с официальной Migration 1.14 и списком релизов; запуск на устройствах читателей не проверялся
  • Версии: 1.14.x

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

  • Сохранить бинарник, JSON и рабочие логи
  • Найти реально используемые устаревшие поля
  • Проверить копию JSON новой версией core
  • Проверить DNS и маршрут после запуска
  • Подготовить откат бинарника и JSON вместе

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

  • Механически переписывать весь конфиг по списку миграций
  • Удалять DNS-условия, не проверив изменение маршрута
  • Считать успешный check доказательством работающего подключения

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

FAQ

Нужно ли менять все DNS-правила при переходе на 1.14?

Нет. Меняют только применимые поля и несовместимые сочетания из официальной Migration; остальные правила сначала проверяют как есть.

Почему старый конфиг перестал запускаться?

Откройте текст ошибки новой версии core и найдите соответствующий пункт Migration. Часто причина в устаревшем поле или несовместимом DNS-правиле.

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

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

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

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

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