sing-box не запускается: порядок проверки конфигурации и логов

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

Проверка синтаксиса JSON и основных полей

Первое, что нужно сделать — убедиться, что конфигурационный файл не содержит ошибок. Используйте команду sing-box check -c config.json. Она проанализирует JSON и покажет, где именно найдена проблема. Это самый быстрый способ поймать лишнюю запятую, незакрытую скобку или опечатку в ключе.

Структура конфигурации должна содержать как минимум следующие блоки:

• log — позволяет настроить вывод логов и уровень подробности.
• dns — отвечает за разрешение доменных имён (важно, если используется rule-based маршрутизация).
• inbounds — список точек входа (локальные порты, TUN).
• outbounds — список точек выхода (прокси-серверы, direct).

Если outbounds отсутствует или пуст, sing-box аварийно завершится, так как не сможет определить, куда отправлять трафик. Даже минимальный outbound, такой как direct, обязателен.

Чтение и анализ логов запуска

Логи — главный источник информации. По умолчанию они выводятся в стандартный поток ошибок. При запуске через systemd выполните journalctl -u sing-box -f для просмотра в реальном времени. Если вы запускаете из терминала, просто смотрите на вывод.

Уровни логирования:

• panic/fatal — процесс прерван.
• error — ошибка, но работа продолжается.
• warn — потенциальная проблема.
• info — обычная информация.
• debug — детальная трассировка.

Для диагностики переключите "log": {"level": "debug"}. Это покажет, как sing-box обрабатывает каждый пакет и какой outbound выбирается. Обратите внимание на строки с fatal или error.

Проверка маршрутизации (route) и DNS

Даже если ядро запустилось, доступ к сайтам может отсутствовать из-за неправильных правил маршрутизации. В блоке route есть массив rules, которые сопоставляют трафик с outbound. Например, правило для домена google.com должно вести на прокси, а не в никуда.

Проверьте, что DNS-запросы не попадают под правило «blackhole» или «reject». В TUN-режиме обязательно добавьте route.dns.hijack или используйте dns.hijack в конфиге TUN. Без этого системные запросы DNS могут уходить напрямую мимо sing-box, что вызывает утечки и сбои.

Если DNS-сервер недоступен, соединение не установится. Протестируйте резолвер из командной строки, например nslookup example.com 8.8.8.8. В конфигурации dns.servers можно временно указать 1.1.1.1 и 8.8.8.8 для проверки.

TUN-режим: права и системные зависимости

TUN требует создания виртуального сетевого интерфейса. На Linux для этого нужны права root: sudo sing-box run -c config.json. На Windows необходимо установить драйвер wintun и запускать процесс с правами администратора.

Если интерфейс не создаётся, в логах будет ошибка типа failed to open TUN interface: operation not permitted. Проверьте также, что модуль tun загружен в ядро (команды lsmod | grep tun или modprobe tun). Для Android чипсетов может быть ограничение — используйте VPNService API.

В конфигурации tun укажите interface_name (например, tun0), mtu (обычно 1500), auto_route (true для автоматической маршрутизации). Также рекомендуется включить strict_route, но он может ломать локальные сети.

Настройка VLESS и транспорта

VLESS — популярный протокол, но требовательный к точности. Если в конфигурации сервера указан uuid, а у вас другой — соединение будет закрыто. Убедитесь, что поля server, server_port, uuid совпадают с теми, что выданы вашим провайдером.

Транспорт — это способ инкапсуляции данных. Чаще всего используют tcp, ws (WebSocket) или grpc. Если сервер настроен на ws, а клиент на tcp, соединение зависнет на этапе TLS. Внимательно проверьте блок transport:

"transport": {
  "type": "ws",
  "path": "/path",
  "headers": {"Host": "example.com"}
}

Для grpc добавьте "service_name": "yourService". Если используется TLS, укажите tls.enabled и tls.server_name — оно должно совпадать с сертификатом домена. Не используйте tls.insecure без крайней необходимости.

Отделяем клиент, ядро, сеть и сервер

Если ручной запуск из конфига работает, а через GUI нет — проблема в клиенте. Попробуйте экспортировать реальный конфиг, который передаётся ядру, и сравните его с ожидаемым. Некоторые графические оболочки добавляют свои inbound (например, SOCKS на localhost) и могут конфликтовать.

Если core не запускается в принципе, исключите локальные конфликты: порт уже занят, переменные окружения, отсутствие прав. Затем проверьте сеть: доступен ли сервер по порту (например, nc -vz server 443). Если сервер недоступен, проблема на стороне провайдера или в межсетевом экране.

Используйте ping и traceroute, но помните, что ICMP может быть заблокирован. Лучше ориентироваться на рабочие тесты через curl или openssl s_client.

Заключение

Системный подход к диагностике позволяет сократить время поиска ошибки. Всегда начинайте с проверки конфига, затем смотрите логи, далее переходите к сети и серверу. Документация sing-box — ваш надёжный помощник. В ней описаны все поля и примеры для типовых сценариев.