todo/protocols/trojan.md

date	tags	aliases	link
2026-07-25	протоколы trojan tls обход-блокировок	Trojan Trojan-GFW Trojan-Go	https://github.com/trojan-gfw/trojan

🐴 Trojan: прокси, который притворяется обычным HTTPS-сайтом

[!info] О чём заметка Разбор протокола Trojan — минималистичного прокси поверх настоящего TLS, устроенного вокруг одной идеи: сервер должен вести себя как обычный веб-сайт для всех, кто не знает пароля. Здесь: как работает механизм отката (fallback), чем Trojan отличается от xray/vless, что добавил Trojan-Go и где у схемы слабое место. Карта протоколов — в protocols/00-overview.

TL;DR

• Trojan не изобретает своё шифрование: он работает внутри обычного TLS-соединения к вашему домену с настоящим сертификатом. Всё шифрование — это тот же TLS, которым пользуется весь веб.
• Аутентификация предельно простая: первым делом клиент отправляет хеш пароля, и если он верный — сервер начинает проксировать.
• Главная защитная идея — fallback: при неверном пароле или при обычном визите браузером сервер молча передаёт соединение настоящему веб-серверу. Активный зонд видит нормальный сайт, а не «странный порт».
• Требуется домен и валидный сертификат — в этом отличие от xray/reality, который позволяет прикрыться чужим сайтом без собственного домена.
• Слабое место — не аутентификация, а статистика: связка «TLS внутри TLS» имеет узнаваемый почерк, и современный DPI ловит её независимо от корректности fallback.
• Trojan-Go — форк с транспортом WebSocket, мультиплексированием и другими надстройками; исходный trojan-gfw/trojan — эталонная реализация на C++.

Идея: не выделяться, потому что ты и есть сайт

Trojan появился как реакция на слабость протоколов «случайных байтов» вроде раннего protocols/shadowsocks: их выдавал сам факт того, что трафик не похож ни на что известное. Ответ автора Trojan звучал так: не надо изобретать маскировку — надо просто быть настоящим HTTPS-сервером.

Устройство минимально. На сервере стоит веб-сайт с доменом и обычным сертификатом (Let's Encrypt подойдёт). Клиент устанавливает к нему обычное TLS-соединение — то же самое рукопожатие, которое делает браузер. Внутри установленного канала клиент первым же сообщением отправляет: хеш пароля (SHA-224 в шестнадцатеричном виде), команду (TCP/UDP), адрес назначения — и дальше данные.

Сервер, получив соединение, смотрит на первые байты. Пароль верный — работает как прокси. Пароль неверный или это вообще обычный HTTP-запрос браузера — сервер отдаёт соединение настоящему веб-серверу, и посетитель видит нормальный сайт.

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

Fallback: почему это главное в протоколе

Механизм отката заслуживает отдельного объяснения, потому что именно он отличает Trojan от протоколов, которые «просто шифруют».

Классический сценарий обнаружения прокси — активное зондирование: цензор видит подозрительное соединение, запоминает адрес и позже сам подключается к серверу, пробуя разные варианты. Протокол без защиты выдаёт себя реакцией: обрывает соединение, отвечает мусором, ведёт себя не как веб-сервер. Так в своё время ловили и Shadowsocks, и уязвимую реализацию protocols/vmess.

Trojan на такую проверку отвечает содержимым настоящего сайта — не эмуляцией, а буквально ответом реального веб-сервера, который стоит рядом. Отличить это от обычного хостинга по одному запросу нельзя.

[!warning] Fallback защищает от зонда, но не от статистики Устойчивость к активной проверке — половина задачи. Вторая половина — пассивный анализ: у соединения, внутри которого работает ещё одно шифрованное соединение («TLS внутри TLS»), характерные размеры первых пакетов и ритм обмена, отличающиеся от обычного просмотра сайта. Именно этот класс детекта разобран в VLESS/dpi-tls-june-2026, и против него в мире Xray придуманы XTLS Vision, а в соседних экосистемах — protocols/anytls с его набивкой. У Trojan своего ответа на эту проблему нет.

Второе ограничение — нужен настоящий домен с сертификатом. Это и деньги (домен), и след: домен регистрируется, сертификат попадает в публичные логи Certificate Transparency, а сайт-прикрытие должен выглядеть правдоподобно. Именно эту цепочку требований снял xray/reality, позволивший прикрываться чужим сайтом без собственного домена — поэтому новые установки чаще делают на нём.

Trojan против VLESS

Вопрос возникает постоянно, потому что оба протокола работают внутри TLS и оба почти не добавляют собственного шифрования.

Свойство	Trojan	xray/vless
Аутентификация	Хеш пароля в начале потока	UUID пользователя
Собственное шифрование	Нет, только TLS	Нет, только TLS (в новых версиях есть опциональное шифрование)
Защита от активного зонда	Fallback на настоящий веб-сервер	Fallback у Xray-сервера, а с REALITY — прикрытие чужим сайтом
Свой домен и сертификат	Обязательны	Обязательны для обычного TLS, не нужны с REALITY
Борьба с «TLS внутри TLS»	Не предусмотрена	XTLS Vision
Развитие	Практически остановилось	Активное, в xray/project-x

Вывод из таблицы простой: Trojan — исторически важный и по-прежнему рабочий протокол, но VLESS покрывает те же сценарии и умеет больше. Если сервер уже работает на Trojan и не блокируется — менять ради самой смены незачем. Если поднимаете новое — почти всегда разумнее VLESS с REALITY.

Trojan-Go и варианты

Эталонная реализация — trojan-gfw/trojan на C++. Форк Trojan-Go добавил к протоколу то, чего не хватало на практике: транспорт WebSocket (позволяет прятать соединение за CDN), мультиплексирование нескольких потоков в одном соединении, обфускацию через плагины Shadowsocks, встроенный менеджер пользователей. Поддержка Trojan есть во всех универсальных ядрах — Clash/02-mihomo, sing-box/sing-box-extended, xray/project-x, — поэтому клиент выбирается свободно.

[!note] «Trojan» в подписке не всегда значит одно и то же В конфигах встречаются варианты: чистый Trojan поверх TLS, Trojan поверх WebSocket (наследие Trojan-Go), Trojan с обёрткой вроде protocols/shadowtls. Параметры транспорта должны совпадать на клиенте и сервере — при рассинхроне соединение не установится, хотя пароль и адрес верны. Это частая причина «ключ рабочий, а не подключается».

Практические выводы

• Trojan имеет смысл там, где уже есть домен и сайт: прокси прячется за реальным веб-присутствием, и это выглядит естественно.
• Держите сайт-прикрытие настоящим и осмысленным. Пустая страница «It works!» на домене, к которому идёт заметный трафик, — сама по себе подозрительная деталь.
• Не рассчитывайте на fallback как на полную защиту: он закрывает активные проверки, а не поведенческий анализ.
• Для новых развёртываний сравните с xray/reality: там не нужен свой домен и есть ответ на «TLS внутри TLS».

📚 См. также

• protocols/00-overview — карта задач и поддержки в ядрах.
• xray/vless и xray/reality — основная альтернатива и её преимущества.
• protocols/shadowsocks — протокол, недостатки которого Trojan исправлял.
• protocols/vmess — третий ветеран эпохи и его уязвимость к активному зондированию.
• protocols/anytls — современный подход к проблеме «TLS внутри TLS».
• VLESS/dpi-tls-june-2026 — как выглядят такие соединения для DPI.

---

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