todo/protocols/anytls.md

date	tags	aliases	link
2026-07-25	протоколы anytls tls dpi обход-блокировок	AnyTLS anytls-go TLS in TLS	https://github.com/anytls/anytls-go

🧬 AnyTLS: протокол против детекта «TLS внутри TLS»

[!info] О чём заметка Разбор протокола AnyTLS — относительно нового (2025) прокси, спроектированного вокруг одной конкретной проблемы: характерного почерка, который возникает, когда шифрованное соединение прячут внутри другого шифрованного соединения. Здесь: в чём суть проблемы, как AnyTLS с ней борется набивкой и пулом сессий, чем он отличается от XTLS Vision и где его границы. Карта протоколов — в protocols/00-overview.

TL;DR

• Проблема: когда прокси-протокол работает внутри TLS, у трафика появляется узнаваемый ритм — «рукопожатие внутри рукопожатия», характерные размеры первых пакетов. DPI ловит это, не расшифровывая ничего.
• Ответ AnyTLS: настраиваемая схема набивки (padding), которая меняет размеры записей на уровне открытого текста до шифрования, плюс мультиплексирование нескольких потоков в одном TLS-соединении и пул готовых сессий, чтобы не создавать новое соединение на каждый запрос.
• Набивка по умолчанию описана явно: первая порция фиксирована в 30 байт, дальше идут ступени 100–400 и 400–500 байт до восьмого уровня. Схему можно переопределить своей.
• AnyTLS не прикрывается чужим сайтом: ему нужны свой домен и сертификат, как protocols/trojan, а не как xray/reality.
• Поддерживается sing-box/sing-box-extended и Clash/02-mihomo (и как исходящий, и как входящий), в Xray-core обсуждался, но своей реализации там нет.
• Проект молодой: протокол дорос до второй версии в 2025 году, оценки эффективности пока предварительные — закладываться на него как на «серебряную пулю» рано.

Проблема: почему «TLS внутри TLS» видно

Разберём подробно, потому что весь смысл AnyTLS — в этой задаче.

Когда вы через прокси открываете HTTPS-сайт, происходит следующее. Сначала ваш клиент устанавливает внешнее TLS-соединение с прокси-сервером — это то, что видит провайдер. Затем внутри этого канала браузер устанавливает внутреннее TLS-соединение уже с самим сайтом. Провайдер не может прочитать ни то, ни другое: всё зашифровано.

Но ему и не нужно читать. Ему достаточно смотреть на размеры и тайминги. Обычный визит на сайт начинается с рукопожатия характерного вида и переходит к передаче данных. А в случае прокси сразу после установления внешнего канала внутри идёт ещё одно рукопожатие — со своим узнаваемым набором размеров записей и своим ритмом «запрос-ответ-запрос». Наблюдатель видит зашифрованный поток, у которого первые несколько пакетов складываются в характерную картинку, не встречающуюся при обычном веб-сёрфинге.

Проще говоря: вас выдаёт не содержимое, а форма — как силуэт человека под одеялом. Подробно этот класс детекта и его развитие в российских сетях разобраны в VLESS/dpi-tls-june-2026.

Известные ответы на проблему различаются по подходу. XTLS Vision (в экосистеме xray/project-x) распознаёт внутреннее рукопожатие и после его завершения перестаёт накладывать второй слой шифрования, передавая данные напрямую — силуэт исчезает, потому что исчезает второе одеяло. AnyTLS идёт другим путём: он оставляет структуру как есть, но меняет её форму набивкой.

Как устроен AnyTLS

Оболочка. AnyTLS заворачивает произвольный прокси-трафик в стандартный TLS — совместимость с обычной TLS-инфраструктурой сохраняется, никаких экзотических расширений не требуется.

Схема набивки (padding scheme). Ключевой механизм: перед шифрованием AnyTLS добивает записи до заданных размеров, разрушая ту самую характерную последовательность. Схема по умолчанию, по документации протокола, устроена ступенями: первая порция фиксирована в 30 байт, для небольших данных используется набивка 100–400 байт, для средних и крупных — цепочки 400–500 байт, и так до восьмого уровня (stop=8), после чего набивка прекращается. Схему можно заменить своей — в этом смысл названия: вы управляете тем, как выглядит поведение вашего трафика.

Сессии и мультиплексирование. AnyTLS мультиплексирует несколько логических потоков в одном TLS-соединении и держит пул простаивающих сессий со стратегией «использовать самую свежую, вычищать самые старые». Это снижает накладные расходы на установление соединений и заодно убирает ещё один демаскирующий признак: у прокси-клиента иначе получается подозрительно много одинаковых коротких TLS-соединений подряд.

Версия 2 протокола (2025) добавила обратную связь о состоянии сервера и работу с перегрузкой туннеля — это про качество связи, а не про маскировку.

Чего AnyTLS не делает

Здесь важно не переоценить инструмент.

Он не прикрывается чужим сайтом. В отличие от xray/reality, AnyTLS не выдаёт себя за постороннего — ему нужен собственный домен и сертификат. Значит, остаются те же следы, что у protocols/trojan: домен зарегистрирован, сертификат попал в публичные логи прозрачности, а сам сервер должен выглядеть правдоподобно для активной проверки.

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

Он не заменяет транспорт. AnyTLS — про то, как выглядит поток внутри TLS. Проблемы уровня «в сети режут TLS на нестандартных портах» или «UDP заблокирован» он не решает.

[!warning] Молодой протокол — отдельный риск AnyTLS появился в 2025 году, его вторая версия вышла в том же году, и объём независимого анализа пока невелик. У молодых протоколов регулярно находят и ошибки реализации, и неучтённые демаскирующие признаки — так было и с protocols/shadowtls, чья третья версия считалась устойчивой, пока в 2025 году не показали обратное. Используйте AnyTLS как один из вариантов в арсенале, а не как единственную опору, и обновляйте ядро.

Где поддерживается и как настраивается

Реализации: эталонная anytls-go, а также порты на Rust. Из ядер AnyTLS поддерживают sing-box/sing-box-extended и Clash/02-mihomo — в последнем и как исходящее подключение, и как слушатель (то есть mihomo может быть сервером AnyTLS). В xray/project-x протокол обсуждался в issue-трекере, но собственной реализации нет — это как раз тот случай, когда список поддержки протоколов определяет выбор ядра.

Настройка со стороны клиента минимальна: адрес, порт, пароль, домен для TLS и, при желании, своя схема набивки. Именно последнее отличает AnyTLS от большинства протоколов: параметр маскировки вынесен в конфиг, и его можно менять, не меняя протокол.

📚 См. также

• protocols/00-overview — карта задач и поддержки в ядрах.
• VLESS/dpi-tls-june-2026 — подробно о проблеме, ради которой AnyTLS создан.
• xray/xtls-vision — альтернативный ответ на ту же проблему в экосистеме Xray.
• protocols/shadowtls — другой подход к маскировке под TLS и история его обнаружения.
• protocols/trojan — протокол с похожими требованиями (свой домен и сертификат).
• Clash/06-features-protocols — как AnyTLS выглядит в YAML-конфиге.
• 🔗 anytls/anytls-go — эталонная реализация и документация протокола.

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.