Миграция DNS в sing-box: поля, bootstrap и откат

Миграция DNS в sing-box должна сохранить разрешение имён и маршрутизацию при замене схемы серверов. Здесь один UDP-bootstrap и один HTTPS-upstream исторического sing-box 1.13.21 переводятся на формат 1.14.3, Ubuntu 24.04 LTS amd64. Устаревший (legacy) формат DNS-серверов удалён в 1.14.0. Старая версия объясняет входные данные, а не рекомендуется для постоянной работы. Полного сквозного авторского испытания не проводилось.［1］［2］［6］［7］

Ключевые выводы

• Сохраняйте роли тегов, зависимости bootstrap и смысл маршрутов, а не только корректность JSON.
• HTTPS-сервер с доменным именем нуждается в независимом резолвере этого имени.
• Typed DNS по умолчанию соединяется напрямую; detour меняет применимость остальных dial-полей.
• Восстанавливайте бинарный файл, конфигурацию и параметры службы согласованным комплектом.

Как проходит миграция DNS в sing-box и кто отвечает за файл?

Начните с распределения ответственности за самостоятельное размещение и определите, кто создаёт эффективный файл. Если это GUI, панель, подписка или генератор, используйте его поддерживаемый путь и проверьте доставку обновлений профиля клиенту. Перезаписываемая локальная правка не является устойчивой миграцией.

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

Подготовьте приватный рабочий каталог, свободный loopback-порт 1053, dig из Ubuntu-пакета dnsutils и отдельно полученный официальный исполняемый файл 1.14.3 по пути /opt/sing-box-1.14.3/sing-box. До использования проверьте платформу артефакта и официальные сведения о целостности. Не перезаписывайте действующий бинарный файл и не скачивайте установочный скрипт для немедленного выполнения. Сохранённый текущий исполняемый файл нужен только там, где необходимо разобрать соответствующий исторический ввод.

Запишите реальный путь и версию программы, эффективную конфигурацию, include-каталоги, unit и drop-in, служебную идентичность, владельцев, права и автозапуск. Держите резервные копии вне активного дерева includes, иначе служба может загрузить их как конфигурацию. До изменения действующей службы проверьте независимый путь восстановления.

Шаг 1: опишите legacy DNS в sing-box и зависимости

Этот входной пример намеренно не содержит дополнительных правил, настройки кэша, FakeIP, фильтрации запросов или переопределения strategy. Сохраните его как dns-old.json в приватном каталоге упражнения. Это объясняющий образец, не команда замены работающей установки.

{
  "dns": {
    "servers": [
      {
        "tag": "bootstrap",
        "address": "1.1.1.1",
        "detour": "direct"
      },
      {
        "tag": "secure-dns",
        "address": "https://dns.google/dns-query",
        "address_resolver": "bootstrap",
        "detour": "direct"
      }
    ],
    "final": "secure-dns"
  },
  "inbounds": [
    {
      "type": "direct",
      "tag": "dns-test",
      "listen": "127.0.0.1",
      "listen_port": 1053
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "rules": [
      {
        "inbound": [
          "dns-test"
        ],
        "action": "hijack-dns"
      }
    ],
    "final": "direct"
  }
}

bootstrap разрешает имя хоста secure-dns; последний обрабатывает запросы, выбранные dns.final. Direct-вход при опущенном network принимает UDP и TCP на loopback. Правило для конкретного inbound передаёт его запросы DNS-обработчику. Оно не создаёт публичный резолвер и не перехватывает системный DNS целиком.［5］［9］

Перед работой с настоящим файлом перечислите все server tags и ссылки из DNS rules, final, route options и outbound dialers. Отметьте числовые адреса, доменные имена и прокси, через которые идут upstream-соединения. Существующий тег может обозначать неверную роль. Если присутствуют дополнительные стратегии или фильтры, остановите применение минимального рецепта и отдельно перенесите их семантику по официальному руководству.［1］

Шаг 2: сопоставьте поля и domain resolver в sing-box

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

Исторический ввод	Typed-цель	Сохраняемый смысл
address: 1.1.1.1	type: udp, числовой server, порт 53	Bootstrap доступен без дополнительного доменного разрешения
HTTPS URL в address	type: https, server, 443, path	Имя, путь и проверяемая TLS-идентичность соответствуют службе
address_resolver: bootstrap	domain_resolver: bootstrap	Имя upstream не разрешается через ещё не созданное собственное соединение
Server tag и dns.final	Сохранённые строки	Ссылки выбирают нужные роли серверов
Явный detour: direct этого ввода	Отсутствует в этой цели	Используется документированный прямой dial по умолчанию
Strategy или query policy в других местах	Отдельное сопоставление	Выбор ответов и фильтрация требуют самостоятельной проверки

Typed UDP и HTTPS по умолчанию используют прямое соединение, тогда как legacy мог наследовать основной outbound. Здесь старые серверы явно выбирали direct, поэтому отсутствие detour сохраняет намерение. Если исходная конфигурация использует прокси, не удаляйте detour ради сходства с примером: проследите outbound и bootstrap. Включённый detour делегирует соединение и заставляет игнорировать прочие dial-поля. Соседний domain_resolver не настраивает автоматически резолвер выбранного outbound.［3］［4］［8］

Сохраните целевой файл как dns-new.json:

{
  "dns": {
    "servers": [
      {
        "type": "udp",
        "tag": "bootstrap",
        "server": "1.1.1.1",
        "server_port": 53
      },
      {
        "type": "https",
        "tag": "secure-dns",
        "server": "dns.google",
        "server_port": 443,
        "path": "/dns-query",
        "domain_resolver": "bootstrap",
        "tls": {
          "enabled": true,
          "server_name": "dns.google",
          "insecure": false
        }
      }
    ],
    "final": "secure-dns"
  },
  "inbounds": [
    {
      "type": "direct",
      "tag": "dns-test",
      "listen": "127.0.0.1",
      "listen_port": 1053
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "rules": [
      {
        "inbound": [
          "dns-test"
        ],
        "action": "hijack-dns"
      }
    ],
    "final": "direct"
  }
}

HTTPS-upstream с именем явно выбирает независимый UDP-bootstrap. Проверку TLS оставьте включённой. TLS защищает HTTPS-участок, но UDP-bootstrap сам по себе не зашифрован. Эти публичные upstream — пример разделения зависимостей, не обещание конфиденциальности, доступности, задержки или работоспособности в определённом регионе.［4］

Шаг 3: проверьте цель отдельным процессом

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

/PRIVATE/BACKUP/sing-box-1.13.21 check -c dns-old.json
/opt/sing-box-1.14.3/sing-box version
/opt/sing-box-1.14.3/sing-box check -c dns-new.json
/opt/sing-box-1.14.3/sing-box run -c dns-new.json

Запускайте целевой процесс на переднем плане обычным пользователем. Порт 1053 не требует привилегии низких портов. Файлы упражнения должны оставаться приватными, с правами 600. Если loopback 1053 занят, остановитесь и согласованно выберите другой свободный высокий порт, не завершая процесс владельца. Успешный check означает принятие схемы, а работающий процесс и реальные запросы дают отдельные свидетельства.

Из другого терминала явно задайте адрес и порт:

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA
dig @127.0.0.1 -p 1053 example.com A +tcp

Проверьте статус DNS, запрошенный тип, ответ и указанный сервер. У зоны без IPv6-записи успешный ответ может не содержать AAAA. Браузер или dig без явного сервера способны использовать иной резолвер и не проверяют этот процесс. Записывайте собственные наблюдения приватно; вымышленных результатов здесь нет.

Шаг 4: проверьте отказы до замены службы

Создавайте приватные копии, меняйте одно условие, останавливайте только собственный foreground-процесс через Ctrl-C и запускайте выбранную копию. Между проверками возвращайте исправный файл. Общий firewall и системный DNS менять не требуется.

Проверка читателя	Ожидаемое наблюдение	Обработка отказа
Верная цель, запросы UDP и TCP	Процесс отвечает через выбранный DNS-путь	Разделите привязку, доступ к upstream, TLS и журналы
HTTPS направлен на неиспользуемый локальный порт копии	Реальный запрос не проходит, даже если схема принята	Восстановите endpoint, не ослабляйте TLS и не добавляйте скрытый fallback
В domain_resolver указан отсутствующий тег	Проверка или запуск отвергает ссылку	Исправьте ссылку до запросов
secure-dns разрешает своё имя через себя	Отказ или ошибка разрешения вместо правильного bootstrap	Верните независимый числовой bootstrap, не полагайтесь на точную строку ошибки
Целевой binary читает legacy-образец	Старая схема отвергается	Используйте mapped-файл, не обход устаревания
Неизменённая исправная цель перезапущена	Новые запросы проходят	Сравните программу, файл и права с исходной копией

Авария upstream может выглядеть как ошибка миграции. Разделяйте отказ схемы, привязку сокета, bootstrap имени, TLS и политику ответов. Это ожидаемые наблюдения, не авторский протокол тестов. Единственный тайм-аут не устанавливает конкретную причину.

Шаг 5: активируйте и восстановите согласованный комплект

Только после изолированной проверки используйте поддерживаемую процедуру владельца, чтобы направить службу на целевой binary и проверенный файл. Перепроверьте идентичность, доступ к нужным сертификатам, команду unit и includes. Проверьте эффективный файл от имени службы, перезапустите только разрешённый unit в окно обслуживания, прочитайте ограниченные журналы и повторите явные запросы через фактический вход службы.

Для восстановления остановите изменённую службу. Верните сохранённую программу или точный пакет, конфигурацию и includes, владельцев, unit и drop-in, прежний автозапуск. После изменения unit выполните sudo systemctl daemon-reload. Проверьте файл восстановленной соответствующей программой, запустите по прежнему состоянию, просмотрите статус и журналы, повторите исходные запросы. Один возврат JSON с несовместимой программой не является восстановлением.

Откат на историческую версию — временное сдерживание инцидента с учётом её поддержки безопасности и уведомлений. Не оставляйте legacy в эксплуатации бессрочно; запланируйте поддерживаемую миграцию. Для отдельного упражнения остановите свой процесс через Ctrl-C и проверьте освобождение 1053. Системный DNS клиента не менялся, поэтому общесетевой DNS маршрутизатора возвращать не требуется.

Итоги

• Сопоставьте тип, endpoint, tag, resolver и dial-путь каждого upstream.
• Проверяйте реальные ответы и отказы на явно указанном loopback-входе.
• Развёртывайте и восстанавливайте binary, файл и службу вместе.

Часто задаваемые вопросы (FAQ)

Можно оставить legacy-серверы в 1.14.3?

Нет. Граница удаления — 1.14.0; используйте typed-серверы, а не обход проверки старой схемы.［2］

Всегда ли достаточно заменить address_resolver?

Сопоставляйте поле в конкретном серверном и dial-контексте. Глобальная замена не сохраняет автоматически владельца прокси или политику запросов.

Зачем сохранять теги?

На них ссылаются правила и final. Переименование требует обновить нужные ссылки; неизменённый тег всё равно требует проверки роли.

Зачем HTTPS bootstrap-резолвер?

Имя upstream нужно разрешить до создания HTTPS-соединения. Разрешение через это же недоступное соединение создаёт цикл зависимости.

Нужно сохранять detour: direct везде?

Нет. Typed-серверы уже используют direct по умолчанию. Detour меняет применимость dial-полей; отдельно проверьте резолвер выбранного outbound.［3］［4］

sing-box check подтверждает работающий DNS?

Нет. Команда проверяет конфигурацию; запросы, политика ответов, upstream-доступ и перезапуск требуют собственных наблюдений.

Что делать, если генератор перезаписывает файл?

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

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

Источники:

1. sing-box DNS migration guide — https://sing-box.sagernet.org/migration/
2. sing-box legacy DNS server — https://sing-box.sagernet.org/configuration/dns/server/legacy/
3. sing-box UDP DNS server — https://sing-box.sagernet.org/configuration/dns/server/udp/
4. sing-box HTTPS DNS server — https://sing-box.sagernet.org/configuration/dns/server/https/
5. sing-box route rule actions — https://sing-box.sagernet.org/configuration/route/rule_action/
6. sing-box 1.14.3 release — https://github.com/SagerNet/sing-box/releases/tag/v1.14.3
7. sing-box 1.13.21 historical release — https://github.com/SagerNet/sing-box/releases/tag/v1.13.21
8. sing-box shared dial fields — https://sing-box.sagernet.org/configuration/shared/dial/
9. sing-box direct inbound — https://sing-box.sagernet.org/configuration/inbound/direct/

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

• Различить TUN и системный прокси
• Определить владельца профиля
• Разделить задачи клиента и ядра
• Проверить неполадки приложений