Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Настройка ShadowTLS v3: два уровня аутентификации
Marcus Reid
11 октября 2026 г.· 11 мин чтения
Настройка ShadowTLS v3 требует двух независимых секретов: пароля внешнего пользователя ShadowTLS и ключа внутреннего прокси. Одно рукопожатие TLS не доказывает, что любой из уровней разрешил полезный прокси-запрос. Здесь используются sing-box 1.14.3 и Ubuntu 24.04 LTS x64 на обеих сторонах, строгий v3 и один метод Shadowsocks 2022.［1］［2］
Ключевые выводы
- На сервере задавайте v3
users, а не верхнеуровневый пароль v2.- Создавайте разные секреты для внешнего пользователя и внутреннего прокси.
- Используйте свой сайт рукопожатия с TLS 1.3 и отключённым wildcard SNI.
- Ограничьте внутренний слушающий порт и проверьте передачу данных приложения.
- Отдельно проверяйте неверный внешний пароль, внутренний ключ и сбои сайта рукопожатия.
Инструкция подготовлена по официальным источникам ниже; полный сквозной тест не выполнялся. Версия обозначает применимость документации, а не испытанное автором окружение. Начните с обязанностей владельца и восстановления при самостоятельном размещении.
Какие границы разделяет настройка ShadowTLS v3?
Путь клиента: приложение → локальный SOCKS → шифрование Shadowsocks → транспорт ShadowTLS → серверный Shadowsocks → назначение. Внешнее рукопожатие использует отдельный TLS-сайт. Имя его сертификата не обязательно совпадает с адресом прокси-сервера. Разделяйте эти обязанности с помощью объяснения протокола и транспорта.
Работайте только с разрешёнными хостами. Требуются строгая проверка SSH по отдельному независимо проверенному known_hosts, консоль восстановления и копии существующих служб и правил экрана. Остановитесь при неизвестном, изменённом или отозванном ключе. Выделите свободные TCP 8443 для ShadowTLS и только loopback TCP 24444 для внутреннего входа; перед изменениями проверьте владельцев через sudo ss -lntup.
Нужен отдельный собственный HTTPS-сайт с TLS 1.3 и публично доверенным сертификатом для handshake.example.com. Его примерный адрес здесь — 203.0.113.20, адрес прокси — 203.0.113.10. Замените оба реальными разрешёнными адресами. Числовой адрес устраняет отдельный начальный DNS-поиск сайта рукопожатия в этом примере. Его доступность и продление сертификата остаются вашей обязанностью.
Два уровня добавляют ещё одну зависимость доступности. Если контроль реализации не нужен, сравните обязанности владельца VPS и пользователя VPN. ShadowTLS не гарантирует необнаружимость; TLS fingerprinting — отдельный вопрос, не равнозначный правильным секретам.
Шаг 1: установите sing-box и проверьте свой TLS-сайт
Скачайте архив Linux amd64 из официального выпуска v1.14.3. Изучите примечания к выпуску, миграции, сообщения о безопасности и опубликованные проверочные материалы; распакуйте в закрытый временный каталог. На обеих машинах установите бинарный файл в /opt/sing-box-shadowtls/1.14.3/sing-box, владелец root, режим 0755. Проверьте версию по полному пути, не подменяя её незаметно сборкой для разработки.［1］
Из сети прокси-сервера проверьте собственный сайт:
openssl s_client -connect 203.0.113.20:443 -servername handshake.example.com -tls1_3 -verify_hostname handshake.example.com -verify_return_error </dev/null
Требуйте согласования TLS 1.3 и успешной проверки цепочки и имени. Соединения или читаемой веб-страницы недостаточно. Сначала исправьте настройки TLS сайта, сертификат, часы или доступность. Предпосылки строгого рукопожатия v3 не оправдывают ослабление проверки.［3］
Создайте служебного пользователя shadowtls-proxy без входной оболочки. Каталог /etc/sing-box-shadowtls должен принадлежать root:shadowtls-proxy, режим 0750. Разрешите нужным клиентам только TCP 8443 в локальном экране и у провайдера; серверу нужен доступ к сайту рукопожатия и разрешённым назначениям. Сохраните SSH и аварийный доступ. Не публикуйте TCP 24444 в сеть.
Создайте независимые секреты
В закрытом административном терминале выполните установленной программой:
/opt/sing-box-shadowtls/1.14.3/sing-box generate rand --base64 32
/opt/sing-box-shadowtls/1.14.3/sing-box generate rand --base64 16
Первое значение используйте как REPLACE_OUTER_PASSWORD, второе — как REPLACE_INNER_KEY. Метод 2022-blake3-aes-128-gcm требует 16-байтовый ключ в base64. Не используйте внешний пароль повторно и не подставляйте произвольную запоминающуюся фразу вместо внутреннего ключа. Храните оба значения конфиденциально, без снимков экрана и общих историй команд с секретами.［4］
Шаг 2: настройка sing-box ShadowTLS и внутреннего сервера
Через sudoedit создайте /etc/sing-box-shadowtls/server.json. Замените примерный IP и оба секрета. Этот фиксированный маршрут v3 использует users, strict_mode: true и wildcard_sni: off; произвольные имена SNI не перенаправляются.［2］
{
"log": {"level": "warn"},
"dns": {
"servers": [{"type": "local", "tag": "system-dns"}]
},
"inbounds": [
{
"type": "shadowtls",
"tag": "st-in",
"listen": "0.0.0.0",
"listen_port": 8443,
"version": 3,
"users": [{"name": "trial-user", "password": "REPLACE_OUTER_PASSWORD"}],
"handshake": {"server": "203.0.113.20", "server_port": 443},
"strict_mode": true,
"wildcard_sni": "off",
"detour": "ss-in"
},
{
"type": "shadowsocks",
"tag": "ss-in",
"listen": "127.0.0.1",
"listen_port": 24444,
"network": "tcp",
"method": "2022-blake3-aes-128-gcm",
"password": "REPLACE_INNER_KEY"
}
],
"outbounds": [{"type": "direct", "tag": "direct", "domain_resolver": "system-dns"}],
"route": {"final": "direct"}
}
Входной detour передаёт аутентифицированный внешний поток указанному внутреннему входу внутри процесса. Это не выходной маршрут в интернет. Внутренний порт слушает только loopback, разрешён только TCP. Имена назначений приложения разрешаются локальным резолвером сервера; конфиденциальность DNS относительно этого резолвера не обещается.［4］［5］［6］
Назначьте файлу владельца root:shadowtls-proxy и режим 0640. Резервные копии ограничьте так же. Ни служебному пользователю, ни клиенту не требуется возможность заменять бинарный файл root.
Шаг 3: соедините клиент с обоими уровнями
На клиентской Ubuntu создайте каталог своего пользователя с режимом 0700 и сохраните этот текст как client.json, режим 0600. Замените IP прокси и оба секрета, сохранив имя сертификата собственного сайта рукопожатия.
{
"log": {"level": "warn"},
"inbounds": [{
"type": "mixed",
"tag": "local",
"listen": "127.0.0.1",
"listen_port": 1082,
"set_system_proxy": false
}],
"outbounds": [
{
"type": "shadowsocks",
"tag": "ss-out",
"server": "127.0.0.1",
"server_port": 24444,
"method": "2022-blake3-aes-128-gcm",
"password": "REPLACE_INNER_KEY",
"network": "tcp",
"detour": "st-out"
},
{
"type": "shadowtls",
"tag": "st-out",
"server": "203.0.113.10",
"server_port": 8443,
"version": 3,
"password": "REPLACE_OUTER_PASSWORD",
"tls": {
"enabled": true,
"server_name": "handshake.example.com",
"min_version": "1.3",
"insecure": false
}
}
],
"route": {"final": "ss-out"}
}
Выход Shadowsocks обеспечивает внутреннее шифрование. Его detour выбирает st-out: закреплённый выход ShadowTLS соединяется со своим настроенным сервером, игнорируя назначение, переданное верхним уровнем. Поэтому 127.0.0.1:24444 здесь не означает обращение к серверу на клиентской машине. Не удаляйте detour и не меняйте final на st-out: это пропустило бы внутреннее шифрование.［7］［8］
Перед запуском проверьте обе конфигурации:
sudo -u shadowtls-proxy /opt/sing-box-shadowtls/1.14.3/sing-box check -c /etc/sing-box-shadowtls/server.json
/opt/sing-box-shadowtls/1.14.3/sing-box check -c ./client.json
Требуйте успешного завершения. Это проверка конфигурации, не всего пути передачи. Исправляйте шаблонные значения, неправильный формат ключа, неподдерживаемое поле или разрешения чтения, а не обходите валидацию.
Шаг 4: запустите отдельную службу и проверьте передачу
От root создайте /etc/systemd/system/sing-box-shadowtls.service:
[Unit]
Description=ShadowTLS v3 and inner Shadowsocks
After=network-online.target
Wants=network-online.target
[Service]
User=shadowtls-proxy
Group=shadowtls-proxy
ExecStart=/opt/sing-box-shadowtls/1.14.3/sing-box run -c /etc/sing-box-shadowtls/server.json
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
UMask=0077
[Install]
WantedBy=multi-user.target
Выполните sudo systemctl daemon-reload, затем sudo systemctl start sing-box-shadowtls. Убедитесь, что именно служба владеет TCP 8443 и что TCP 24444 доступен только на loopback. На клиенте запустите закреплённую программу с run -c ./client.json на переднем плане. Проверьте, что mixed-вход — только 127.0.0.1:1082; не включайте системный прокси или TUN для этого испытания.
Используйте собственную HTTPS-точку с известным содержимым:
curl --fail --show-error --noproxy '' --proxy socks5h://127.0.0.1:1082 https://check.example.net/health
Замените URL своим разрешённым ресурсом. Требуйте ожидаемый ответ приложения, затем повторите небольшую контролируемую отправку и получение файла. Успешное TLS-рукопожатие, активная служба или подключённый локальный сокет не являются результатом приёмки. Настройте один тестовый браузер на локальный SOCKS и откройте проверку IP. Результат относится только к этому запросу, не ко всему DNS, IPv6, UDP и остальным приложениям.
Как проверяется аутентификация ShadowTLS?
Сделайте закрытые копии клиентского файла и меняйте строго одно условие за испытание. Остановите прежний процесс на переднем плане до запуска копии на том же локальном порту. Между отрицательными случаями возвращайте правильный файл и повторяйте положительное обращение.
| Метод проверки | Ожидаемое поведение | Обработка ошибки |
|---|---|---|
| Правильные внешний пароль и внутренний ключ | Контрольный HTTPS-запрос передаётся | Разделите локальный вход, сайт рукопожатия, внешнюю и внутреннюю аутентификацию, назначение |
| Заменить только внешний пароль другим случайным значением | Полезный аутентифицированный прокси-запрос недоступен | Возможное TLS-рукопожатие не доказывает разрешённую передачу |
| Заменить только внутренний ключ другим правильным 16-байтовым base64-ключом | Внутренняя аутентификация не проходит | Некорректный формат проверял бы парсер, а не аутентификацию |
| В отдельном испытании указать недоступный сайт рукопожатия | Передача не завершается | Верните цель, не меняя постороннюю рабочую сеть |
| Направить отдельное испытание на собственный сайт только с TLS 1.2 | Строгий v3 не удовлетворяет условию TLS 1.3 | Верните утверждённый TLS 1.3 сайт, не ослабляйте проверку клиента |
| Перезапустить только эту службу и выполнить новый запрос | Разрешённая передача восстанавливается | Проверьте права файлов, доступность цели и владельца запуска |
Для сбоев цели используйте отдельный одноразовый экземпляр на свободном порту либо согласованное изолированное окно. Не выключайте общий сайт ради отрицательного результата. Ограничьте журналы; перед передачей отчёта удалите секреты, закрытые адреса и метаданные назначений.
Как обновлять, отзывать доступ и восстанавливать службу?
Перед обновлением конфиденциально сохраните бинарный файл, серверную и клиентскую конфигурации, unit и настройки сайта рукопожатия. Следите за выпусками и миграциями sing-box; подготовьте новый каталог версии, проверьте оба файла, повторите многоуровневую матрицу. Продление сертификата сайта тоже требует внимания: неизменившийся прокси может перестать работать из-за истёкшей внешней зависимости.
Для отзыва удалите названного внешнего пользователя из конфигурации сервера и проверьте её. Перезапустите только эту службу, загрузив изменение и прекратив установленные соединения; остальные пользователи того же экземпляра тоже будут прерваны. Проверьте отказ нового соединения с удалённым паролем. Общий внутренний ключ — другая граница: его смена требует обновления всех авторизованных клиентов, которые его используют. При окончательном выводе испытания из эксплуатации отзовите оба секрета.
Откат возвращает совместимый сохранённый файл и путь программы этого unit, после чего повторяются положительные проверки и отказы. Не оставляйте уязвимую версию навсегда. Для выключения восстановите настройки прокси приложения, остановите клиент, выполните sudo systemctl disable --now sing-box-shadowtls и удалите только соответствующее TCP-правило экрана. Проверьте исчезновение обоих слушающих портов. Оставьте независимо управляемый сайт рукопожатия работающим, если он нужен другим задачам: удаление прокси не разрешает удалить этот сайт.
Итоги
Проверяйте внешнего пользователя, внутренний ключ, сайт рукопожатия и передачу к назначению отдельно. Правильная конфигурация необходима, но приёмка также требует полезной передачи, целенаправленных отказов, перезапуска и отзыва доступа. Сквозные результаты развёртывания здесь не заявляются.
Часто задаваемые вопросы (FAQ)
Совпадает ли внешний пароль ShadowTLS с ключом Shadowsocks?
Нет. Создавайте независимые значения. Этот метод Shadowsocks 2022 требует 16-байтовый ключ в base64, а внешний пароль служит аутентификации ShadowTLS.
Можно ли использовать серверное поле password v2 для v3?
В этой конфигурации используйте массив users версии v3. Смешение полей разных версий скрывает настроенную границу аутентификации и затрудняет диагностику.
Доказывает ли TLS-рукопожатие работу двухуровневого прокси?
Нет. Проверьте собственное назначение через полную внутреннюю и внешнюю цепочку, затем убедитесь, что неверные секреты не дают такую же полезную передачу.
Зачем нужен собственный сайт рукопожатия?
Владение позволяет обслуживать сертификат и политику TLS, разрешать трафик и планировать восстановление, не делая посторонний публичный сайт своей эксплуатационной зависимостью.
Нужно ли включать wildcard SNI для этого маршрута?
Оставьте его отключённым. Здесь используется одна утверждённая цель рукопожатия; произвольная переадресация имён и расширенная матрица назначений не разрешаются.
Почему внутренний Shadowsocks слушает только loopback?
Внешний вход передаёт ему потоки внутри серверного процесса. Публичный внутренний порт создал бы дополнительную доступную поверхность аутентификации за пределами ограниченной схемы.
Меняет ли удаление внешнего пользователя внутренний ключ?
Нет, это независимые секреты. Удалите внешнего пользователя и прекратите его сеансы; общий внутренний ключ меняйте отдельно, обновляя всех затронутых авторизованных клиентов.
Источники:
- sing-box release v1.14.3 — https://github.com/SagerNet/sing-box/releases/tag/v1.14.3
- sing-box: ShadowTLS inbound — https://sing-box.sagernet.org/configuration/inbound/shadowtls/
- ShadowTLS: v3 protocol — https://github.com/ihciah/shadow-tls/wiki/V3-Protocol
- sing-box: Shadowsocks inbound — https://sing-box.sagernet.org/configuration/inbound/shadowsocks/
- sing-box: listen fields and inbound detour — https://sing-box.sagernet.org/configuration/shared/listen/
- sing-box: dial fields and domain resolver — https://sing-box.sagernet.org/configuration/shared/dial/
- sing-box: Shadowsocks outbound — https://sing-box.sagernet.org/configuration/outbound/shadowsocks/
- Pinned sing-box ShadowTLS outbound implementation — https://github.com/SagerNet/sing-box/blob/v1.14.3/protocol/shadowtls/outbound.go
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
