В чужой конфигурации Xray-core легко встретить сразу четыре загадочных слова. Mux включён, XMUX настроен вручную, Fragment режет TLS-рукопожатие, а Noise добавляет случайные пакеты. В комментариях обычно обещают более высокую скорость, устойчивость соединения и защиту от сетевого анализа.
Проблема в том, что четыре механизма работают совершенно по-разному. Mux способен сократить количество физических соединений, но замедлить загрузку файлов. XMUX управляет HTTP-соединениями и может создавать лишнюю нагрузку при неверных ограничениях. Fragment меняет структуру первых TLS-сообщений, но не скрывает их содержимое от полноценного анализа. Noise добавляет UDP-пакеты, которые иногда оказываются скорее помехой, чем защитой.
Более того, Xray-core заметно изменился. Старые руководства продолжают советовать настройки, которые уже переехали в другие разделы конфигурации. Менялось и стандартное поведение XMUX, поэтому параметры из популярного руководства двухлетней давности могут не соответствовать современному ядру.
Разберём четыре механизма , затем соберём три клиентских конфига и проверим, когда дополнительные настройки действительно имеют смысл.
Все примеры предназначены для законной настройки собственных серверов и диагностики сетевых соединений с разрешения владельца сети. Изменение структуры трафика не гарантирует доступность заблокированных ресурсов, не заменяет шифрование и не обеспечивает анонимность.
Четыре механизма Xray-core и почему их постоянно путают
Для начала полезно представить обычное подключение. Приложение обращается к локальному SOCKS5-прокси, Xray получает запрос и отправляет его на удалённый сервер через выбранный протокол.
Например, VLESS определяет формат проксируемого обмена и аутентификацию пользователя. REALITY или TLS отвечают за защиту транспортного соединения, а RAW либо XHTTP определяет, как передаются данные между клиентом и сервером.
Mux, XMUX, Fragment и Noise вмешиваются в разные участки такой цепочки.
| Механизм | Что меняет | Основная польза | Основной риск |
|---|---|---|---|
| mux.cool | Объединяет логические соединения внутри одного транспортного канала | Уменьшает затраты на открытие множества коротких соединений | Конкуренция потоков, возможное падение скорости |
| XMUX | Управляет повторным использованием HTTP/2 и HTTP/3-соединений | Контролирует количество соединений и запросов в XHTTP | Неподходящие лимиты создают задержки или лишние подключения |
| Fragment | Разделяет TCP-данные или TLS ClientHello на части | Помогает исследовать проблемы обработки TLS-рукопожатия | Дополнительные задержки и несовместимость |
| Noise | Отправляет дополнительные UDP-датаграммы | Позволяет изменять начальную последовательность UDP-трафика | Лишние пакеты, возможные тайм-ауты и ошибки |
Mux объединяет соединения, но не ускоряет интернет автоматически
Представьте, что браузер одновременно открывает восемь небольших TCP-соединений. Без Mux Xray может создать восемь отдельных транспортных соединений к прокси-серверу. С Mux несколько логических потоков передаются внутри одного физического соединения.
Уменьшается количество установлений TCP- и TLS-соединений. Для коротких запросов такой подход иногда сокращает накладные расходы.
Классический механизм называется mux.cool, а параметры задаются в объекте outbounds[].mux.
Например, значение concurrency = 8 позволяет одному Mux-соединению обслуживать до восьми одновременных логических TCP-потоков. Когда свободной ёмкости не хватает, ядро может открыть дополнительные соединения.
Однако восемь потоков внутри одного TCP-соединения не равны восьми независимым транспортным каналам. Потеря сегмента TCP способна задержать передачу данных сразу нескольким логическим потокам. Приложения также конкурируют за доступную пропускную способность и общие транспортные буферы.
Поэтому Mux может улучшить работу коротких запросов, но не обязан ускорять скачивание файлов, потоковое видео или тесты пропускной способности.
Есть ещё одна особенность. Mux используется не только для TCP. Xray поддерживает XUDP, позволяющий агрегировать UDP-сеансы. Управлять таким трафиком можно отдельно через xudpConcurrency.
Например, значение concurrency = -1 отключает классическое мультиплексирование TCP, а положительный xudpConcurrency позволяет оставить агрегацию UDP. Именно поэтому надпись «Mux включён» в графическом клиенте ещё не объясняет, каким трафиком реально управляет ядро.
XMUX работает внутри XHTTP и использует возможности HTTP
XMUX похож на классический Mux по названию, но работает на другом уровне.
XHTTP использует HTTP-запросы для обмена данными. При работе через HTTP/2 несколько потоков могут передаваться по одному TCP-соединению. HTTP/3 обеспечивает похожее мультиплексирование поверх QUIC, используя UDP вместо TCP.
XMUX управляет такими соединениями. Механизм решает, когда открывать новое подключение, сколько запросов отправлять через существующее и в какой момент перестать повторно использовать старое соединение.
Самый важный практический вывод состоит в том, что классический mux.cool не следует включать поверх XHTTP. HTTP/2 и HTTP/3 уже имеют собственное мультиплексирование, а дополнительный уровень Mux создаёт ненужную вложенность. Современный Xray-сервер ограничивает такое сочетание, сохраняя возможность отдельной работы с XUDP.
Отсюда и типичная ошибка. Пользователь включает XHTTP, затем активирует глобальный переключатель Mux в графической программе и получает не ускорение, а нестабильное соединение или отказ подключения.
У XMUX есть шесть основных параметров.
| Параметр | Что регулирует |
|---|---|
| maxConnections | Число базовых TCP/QUIC-соединений, между которыми распределяются запросы |
| maxConcurrency | Предельное число одновременных проксируемых сеансов на одном соединении |
| cMaxReuseTimes | Максимальное число повторных назначений сеансов на соединение |
| hMaxRequestTimes | Ограничение общего количества HTTP-запросов на соединении |
| hMaxReusableSecs | Время, в течение которого соединение можно использовать для новых запросов |
| hKeepAlivePeriod | Интервал поддержания неактивного HTTP-соединения |
maxConnections и maxConcurrency не следует назначать одновременно. Первый параметр ограничивает число базовых соединений, второй управляет количеством проксируемых сеансов на каждом соединении. В Xray-core предусмотрена проверка, запрещающая одновременное использование положительных значений обоих параметров.
Есть и тонкость с подсчётом. Один проксируемый сеанс XHTTP не обязательно равен одному HTTP-запросу. В режиме stream-one обычно используется один запрос, в stream-up два, а в packet-up количество запросов зависит от объёма отправляемых данных.
Поэтому hMaxRequestTimes и cMaxReuseTimes решают разные задачи. Первый считает HTTP-запросы, второй учитывает повторное использование базового соединения для проксируемых сеансов.
С параметрами по умолчанию тоже произошла перемена. В актуальном Xray-core стандартная конфигурация XHTTP устанавливает maxConnections = 3, hMaxRequestTimes = 600-900 и hMaxReusableSecs = 1800-3000. Старые описания, в которых базовым значением указан диапазон maxConcurrency = 16-32, уже не отражают стандартную конфигурацию нынешнего ядра.
Если XMUX не настроен вручную, ядро применяет собственные значения. При задании хотя бы одного параметра остальные автоматические значения XMUX могут перестать подставляться. Поэтому лучше либо оставить весь блок без настроек, либо явно определить связанные ограничения.
Fragment меняет TLS-рукопожатие, а не содержимое HTTPS
При подключении к HTTPS-серверу клиент начинает TLS-рукопожатие сообщением ClientHello. Сообщение содержит сведения о поддерживаемых алгоритмах, версиях TLS, расширениях и параметрах обмена ключами. При обычном SNI без ECH также может присутствовать открытое имя сервера.
Fragment позволяет разделить исходное сообщение на несколько меньших TLS-записей или фрагментировать начальные операции записи TCP, в зависимости от выбранного режима.
Например, вместо одной TLS-записи длиной 600 байт можно получить несколько записей, которые вместе содержат исходное сообщение ClientHello.
Но здесь есть принципиальное ограничение. TLS допускает разделение сообщений рукопожатия между записями, а сервер восстанавливает исходное сообщение перед обработкой. Система сетевого анализа, способная корректно собирать TCP-поток и TLS-записи, тоже может восстановить ClientHello.
Самостоятельную технологию изменения начального TLS-обмена мы уже разбирали на примере NoDPI. Общая идея похожа, но реализации, область применения и ограничения у программ различаются.
В Xray-core Fragment поддерживает два основных режима.
- packets = tlshello делит TLS ClientHello на несколько TLS-записей.
- packets = 1-3 обрабатывает первые три операции записи TCP-потока, не ограничиваясь поиском ClientHello.
В первом режиме разделение происходит на уровне TLS-записей. Во втором меняется отправка байтов TCP-потока. Ни один вариант не означает, что каждый фрагмент обязательно превратится в отдельный IP-пакет.
TCP может объединить соседние операции записи. При нулевой паузе несколько небольших TLS-записей вообще могут попасть в один сетевой пакет. Поэтому судить о работе Fragment только по количеству TCP-пакетов нельзя.
Дополнительный риск связан с пустыми TLS-записями. Некоторые комбинации параметров Fragment позволяют создавать записи нулевой длины. Такой способ нарушает требования TLS 1.3 к фрагментам рукопожатия и способен вызвать ошибку соединения. Для обычного тестирования подобные значения не нужны.
Noise добавляет UDP-пакеты и не превращает QUIC в другой протокол
В современных версиях Xray-core Fragment и Noise можно настраивать через FinalMask. Слой располагается после обработки транспортного шифрования и позволяет изменить итоговую форму передаваемого трафика.
Noise работает с UDP. Перед полезными датаграммами Xray может отправить дополнительные пакеты случайного или заданного содержимого.
Предположим, клиент устанавливает Hysteria2-соединение поверх QUIC. С включённым Noise перед первым QUIC-пакетом может появиться датаграмма из 32 случайных байтов. Затем клиент продолжит обычное QUIC-рукопожатие.
В отличие от Fragment, Noise не разделяет TLS ClientHello. Механизм создаёт отдельные UDP-пакеты. Получателю требуется корректно отбрасывать неожиданные данные. Если сервер или промежуточное оборудование реагирует на них ошибкой, подключение может перестать работать.
Не следует путать Noise с Salamander. Salamander представляет собой согласованный механизм преобразования UDP-пакетов, который требует одинакового пароля на клиентской и серверной сторонах. Noise не преобразует все последующие QUIC-пакеты и не требует от сервера обратного преобразования добавленного шума.
Более того, стандартный QUIC-профиль Hysteria2 уже имеет определённую структуру рукопожатия. Добавление случайного пакета перед ним не скрывает все последующие признаки протокола.
Три конфигурации Xray-core с реальными параметрами
Ниже приведены три клиентских JSON-конфигурации под актуальный синтаксис Xray-core. Каждая создаёт локальный SOCKS5-прокси на 127.0.0.1:10808.
Примеры предназначены для трёх разных сценариев. Первый показывает классический Mux и Fragment на TCP. Второй использует XHTTP и XMUX. Третий демонстрирует UDP Noise в Hysteria2.
Адреса example.net и example.org, тестовые UUID и обозначения секретов нужно заменить собственными данными. Без совместимого сервера и правильных ключей подключения не заработают. Проверка JSON не заменяет сетевого тестирования.
Конфиг № 1. VLESS + REALITY + RAW с Mux и Fragment
Первый пример рассчитан на собственный сервер VLESS с REALITY и транспортом RAW. Классический Mux объединяет TCP-запросы, а Fragment меняет форму TLS ClientHello на внешнем соединении.
В данном варианте намеренно отсутствует xtls-rprx-vision. Обычное мультиплексирование TCP через mux.cool не следует совмещать с Vision. Серверный профиль пользователя также должен быть настроен без Vision flow.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"address": "node.example.net",
"port": 443,
"id": "00000000-0000-4000-8000-000000000001",
"encryption": "none"
},
"mux": {
"enabled": true,
"concurrency": 8,
"xudpConcurrency": 16,
"xudpProxyUDP443": "skip"
},
"streamSettings": {
"method": "raw",
"security": "reality",
"realitySettings": {
"serverName": "www.example.org",
"fingerprint": "chrome",
"password": "REPLACE_WITH_REALITY_PUBLIC_KEY",
"shortId": "0123456789abcdef",
"spiderX": "/"
},
"finalmask": {
"tcp": [
{
"type": "fragment",
"settings": {
"packets": "tlshello",
"lengths": ["100-200"],
"delays": ["1-3"],
"maxSplit": "4-6"
}
}
]
}
}
}
]
}Разберём параметры, ради которых собрана конфигурация.
concurrency = 8 ограничивает количество одновременных логических TCP-потоков внутри одного соединения Mux. При большем числе запросов Xray может использовать дополнительные физические соединения.
xudpConcurrency = 16 задаёт отдельную ёмкость агрегирующего соединения XUDP. У XUDP собственная логика обработки UDP-сеансов, поэтому значение не следует трактовать как лимит на все UDP-пакеты.
xudpProxyUDP443 = skip исключает UDP-трафик на порт 443 из агрегации Mux. Для VLESS такой трафик может передаваться исходным способом через UoT. По умолчанию политика Mux для UDP/443 может отклонять подобные запросы, поэтому параметр заслуживает отдельной проверки при работе приложений с QUIC.
Далее идёт Fragment.
packets = tlshello выбирает TLS ClientHello, lengths = 100-200 задаёт диапазон размеров частей в байтах, а delays = 1-3 добавляет паузы между фрагментами в миллисекундах.
maxSplit = 4-6 ограничивает максимальное количество частей. Конкретное число выбирается из диапазона. Значения приведены для демонстрации механизма, а не как доказанный оптимум.
При использовании REALITY необходимо правильно заполнить password публичным значением соответствующей серверной пары ключей, а shortId и serverName должны совпадать с разрешёнными серверными параметрами. UUID тоже должен существовать в списке пользователей сервера. Поле encryption = none не означает отсутствие защиты внешнего соединения, поскольку транспорт использует REALITY.
Как проверять пользу. Сначала запустите конфигурацию без finalmask, измерьте время установления соединений, затем включите Fragment и сравните. Отдельным тестом отключите Mux. Только четыре сравнимых состояния покажут, какой механизм повлиял на результат.
При стабильной сети подобная комбинация вполне может работать хуже обычного VLESS + REALITY без дополнительных ухищрений. Не следует использовать первый пример как универсальную рекомендацию для максимальной скорости.
Конфиг № 2. VLESS + XHTTP + TLS с XMUX
Второй пример использует XHTTP поверх HTTP/2 и TLS. Такой транспорт подходит для серверов, где нужен HTTP-обмен, в том числе за совместимым обратным прокси.
В XHTTP задаём режим stream-up. Клиент передаёт данные потоковым HTTP-запросом, а ответная сторона обслуживает отдельный поток загрузки.
В отличие от первого примера классический Mux здесь выключен. XMUX регулирует количество базовых HTTP-соединений и срок их использования.
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"address": "edge.example.net",
"port": 443,
"id": "00000000-0000-4000-8000-000000000002",
"encryption": "none"
},
"mux": {
"enabled": false
},
"streamSettings": {
"method": "xhttp",
"security": "tls",
"tlsSettings": {
"serverName": "edge.example.net",
"allowInsecure": false,
"fingerprint": "chrome",
"alpn": ["h2"]
},
"xhttpSettings": {
"path": "/api/events",
"mode": "stream-up",
"extra": {
"xmux": {
"maxConnections": 3,
"cMaxReuseTimes": 0,
"hMaxRequestTimes": "600-900",
"hMaxReusableSecs": "1800-3000",
"hKeepAlivePeriod": 0
}
}
}
}
}
]
}На сервере должны работать VLESS и XHTTP с совпадающим путём /api/events. Для TLS потребуется действительный сертификат на соответствующее имя сервера. Если соединение проходит через Nginx или другой обратный прокси, нужно правильно настроить передачу потоковых HTTP-запросов и отключить несовместимую буферизацию.
Объект xmux находится внутри xhttpSettings.extra. Именно такое расположение использует современный формат конфигурации Xray.
maxConnections = 3 позволяет XMUX использовать до трёх базовых соединений для распределения запросов, после чего новые запросы начинают назначаться существующим соединениям. Конкретное распределение зависит от текущей занятости и состояния пула.
cMaxReuseTimes = 0 не задаёт отдельного ограничения на количество повторных назначений. Если указать положительное число, Xray перестанет назначать новые сеансы соединению после достижения заданного предела.
hMaxRequestTimes = 600-900 ограничивает общее число HTTP-запросов, которое соединение может обслужить. В режиме stream-up один проксируемый сеанс обычно порождает два HTTP-запроса, поэтому число HTTP-запросов не равно числу открытых приложением соединений.
hMaxReusableSecs = 1800-3000 позволяет повторно использовать соединение в течение примерно 30–50 минут. После истечения выбранного срока новые запросы должны получать другое соединение, а уже работающие сеансы могут завершиться обычным образом.
hKeepAlivePeriod = 0 сохраняет стандартное поведение поддержания соединения. Нулевое значение не следует понимать как безусловное отключение служебных пакетов.
Приведённые параметры воспроизводят стандартную политику современного XHTTP. Поэтому для обычного подключения весь блок extra.xmux можно удалить и предоставить ядру самостоятельно выставить значения. Ручная запись полезна прежде всего для изучения механизма и контролируемых экспериментов.
Если же требуется альтернативная стратегия, вместо maxConnections можно использовать maxConcurrency. Например, диапазон 8-16 ограничит число одновременно обслуживаемых проксируемых сеансов на одном базовом соединении. Одновременно указывать положительные maxConnections и maxConcurrency нельзя.
Есть техническая деталь, которую легко пропустить при сравнении конфигураций. В ряде выпусков Xray-core возникала ошибка XMUX, из-за которой ограничение числа соединений могло не соблюдаться при массовом открытии новых подключений. Исправление вошло в последующие версии. Если клиент начинает создавать десятки TCP-соединений вопреки установленному maxConnections, первым делом проверьте версию ядра и фактическое количество соединений, а не увеличивайте лимиты вслепую.
Наконец, alpn = h2 означает, что клиент устанавливает HTTP/2 поверх TCP. Для HTTP/3 потребуется использовать QUIC, а не просто добавить название протокола в список ALPN.
За обратным прокси возможна и более интересная схема. Клиент подключается к внешнему серверу по HTTP/3, но промежуточный сервер передаёт запросы к XHTTP по HTTP/2. Наличие HTTP/3 между пользователем и внешним узлом не означает, что внутренний Xray-сервер тоже обязан слушать QUIC.
Конфиг № 3. Hysteria2 + QUIC с UDP Noise
Третий пример показывает, как Noise применяется к UDP-транспорту.
В качестве основы используем Hysteria2. Протокол переносит проксируемые TCP- и UDP-сеансы поверх QUIC. Внешнее соединение работает через UDP, даже если внутри туннеля передаётся обычный HTTPS-запрос по TCP.
Дополнительный шум добавим перед QUIC-датаграммами. Настройка не требует такого же блока Noise на сервере, но сервер должен спокойно обрабатывать или игнорировать посторонние UDP-пакеты.
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "hysteria",
"settings": {
"version": 2,
"address": "h3.example.net",
"port": 443
},
"streamSettings": {
"method": "hysteria",
"security": "tls",
"tlsSettings": {
"serverName": "h3.example.net",
"allowInsecure": false,
"alpn": ["h3"]
},
"hysteriaSettings": {
"version": 2,
"auth": "REPLACE_WITH_SHARED_SECRET"
},
"finalmask": {
"udp": [
{
"type": "noise",
"settings": {
"reset": "0",
"noise": [
{
"rand": "24-48",
"delay": "2-5"
}
]
}
}
]
}
}
}
]
}На удалённом сервере должен работать Hysteria2, принимать UDP-подключения на выбранном порту и использовать тот же секрет аутентификации. TLS-сертификат должен соответствовать имени сервера, а транспорт должен поддерживать QUIC.
Основные настройки находятся внутри finalmask.udp.
type = noise включает генерацию дополнительных UDP-датаграмм.
rand = 24-48 задаёт случайную длину одного шумового пакета от 24 до 48 байтов. Содержимое пакета также заполняется случайными байтами.
delay = 2-5 задаёт паузу после отправки шумового пакета в миллисекундах. При нескольких элементах массива Noise пауза разделяет их отправку. В данном примере после шумового пакета следует основная передача.
reset = 0 отключает периодический сброс состояния шума для того же адреса назначения. В рамках соответствующего состояния Noise отправляется один раз. Новый экземпляр клиента или новое состояние соединения может привести к повторной отправке.
Что изменится в сетевом дампе? Перед началом нормального QUIC-обмена появится дополнительная UDP-датаграмма. Последующие сообщения останутся обычным QUIC-трафиком Hysteria2.
Поэтому такой Noise нельзя считать полноценной маскировкой Hysteria2. Сетевой анализатор способен учитывать всю последовательность пакетов, а не только первый датаграммный пакет.
Существует и более серьёзная проблема. Случайные датаграммы могут попасть в серверную логику обработки UDP или вызвать неожиданные ошибки на промежуточном оборудовании. Нельзя гарантировать, что сервер обязательно проигнорирует шум.
Для первого запуска Hysteria2 лучше удалить секцию FinalMask. Если обычное QUIC-соединение стабильно, шум можно включить отдельно и сравнить количество ошибок, время подключения и реакцию сервера.
Для Hysteria2 также существует Salamander, а в более новых реализациях доступен экспериментальный Gecko. Gecko разбивает и дополняет части QUIC-рукопожатия, Salamander преобразует содержимое пакетов с использованием общего пароля. В отличие от Noise, такие механизмы требуют согласованной настройки обоих концов соединения. Смешивать их параметры с обычным случайным шумом без отдельной проверки не следует.
Проверяем три конфигурации и ищем реальные ошибки
Даже синтаксически правильный JSON не гарантирует рабочего соединения. Xray может успешно разобрать конфигурацию и затем не подключиться из-за несовпадающего UUID, неправильного REALITY-ключа, неподходящего TLS-сертификата или неверного маршрута.
Перед тестированием сохраните конфигурацию в файл config.json, замените заглушки настоящими значениями и проверьте версию установленного ядра.
xray versionЗатем проверьте конфигурацию без запуска прокси.
xray run -test -c config.jsonКоманда обнаружит часть ошибок конфигурации, включая несовместимые параметры или неправильный формат отдельных значений. Неправильная настройка удалённого сервера при такой проверке может остаться незамеченной.
Полезна и команда просмотра объединённого JSON.
xray run -dump -c config.jsonНо у команды есть ограничение. Вывод показывает объединённый конфигурационный файл, а не обязательно все значения, которые Xray позднее подставит при построении внутренних объектов. Поэтому отсутствие автоматических значений XMUX в результате -dump ещё не доказывает, что механизм работает без ограничений.
Запускаем клиент.
xray run -c config.jsonВ другом терминале отправляем запрос через SOCKS5.
curl --socks5-hostname 127.0.0.1:10808 https://example.org/Параметр --socks5-hostname передаёт имя целевого сайта через SOCKS5. Такой способ помогает исключить локальное разрешение домена самого сайта инструментом curl. Однако DNS-запросы для адреса прокси-сервера всё ещё могут выполняться локально, если соответствующий адрес задан доменным именем.
Для проверки внешнего IP-адреса можно обратиться к сервису определения адреса через прокси.
curl --socks5-hostname 127.0.0.1:10808 https://api.ipify.orgСравните результат с прямым запросом без прокси. Если внешний адрес отличается ожидаемым образом, запрос действительно прошёл через другой выходной узел. Однако такой тест не проверяет весь трафик компьютера. SOCKS5 обслуживает только приложения, которые направляют через него свои подключения.
Как сравнить скорость без самообмана
Для первых измерений достаточно curl. Команда ниже показывает время соединения с целевым ресурсом, время до первого байта и общую длительность запроса.
curl --socks5-hostname 127.0.0.1:10808
--output /dev/null
--write-out 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}
'
https://example.org/Но отдельные показатели следует трактовать осторожно. time_connect отражает установление соединения curl с локальным SOCKS5-прокси, а не весь путь до удалённого сервера Xray. Поэтому для оценки внешнего соединения полезнее сравнивать общую задержку, время до первого байта и журналы ядра.
Сделайте несколько десятков запросов. Сравните медиану времени, наиболее медленные ответы, количество неудачных подключений и потребление ресурсов.
Для Mux полезен тест множества одновременных коротких подключений. Для XMUX добавьте продолжительную серию запросов и следите за количеством базовых TCP-соединений. Для Fragment измеряйте ошибки и задержки TLS-рукопожатия. Для Noise сравнивайте стабильность QUIC и число лишних UDP-датаграмм.
Одинаково важна воспроизводимость. Проверяйте одну настройку за раз, чередуйте исходную и изменённую конфигурации и не сравнивайте результаты, полученные на разных серверах или при заметно различающейся сетевой нагрузке.
Как увидеть Fragment и Noise в Wireshark
На Linux удобно сохранить сетевой дамп через tcpdump. Вместо тестового IP-адреса используйте настоящий адрес собственного сервера.
sudo tcpdump -ni any host 203.0.113.10 -w xray-test.pcapОткройте файл в Wireshark и сравните соединения с включённым и выключенным Fragment. В первом TCP-примере ищите TLS ClientHello, проверяйте количество TLS-записей и их размеры.
Для UDP Noise сравните первые датаграммы перед QUIC-рукопожатием. Если настройка работает ожидаемым образом, на внешнем интерфейсе появится дополнительный пакет до начала основного обмена.
Следует учитывать, что захват на самом компьютере может показывать крупные сегменты из-за механизмов сетевой разгрузки. Для точного анализа структуры пакетов на линии иногда требуется захват на маршрутизаторе или отдельном узле. Количество записей в приложении и количество физических пакетов могут различаться.
Журналы Xray тоже помогают. Уровень info в XHTTP способен показать выбранный режим соединения и связанные параметры HTTP. При этом не нужно оставлять подробное журналирование включённым постоянно, поскольку журналы могут содержать адреса подключений и другие чувствительные сведения.
Самые частые ошибки
| Симптом | Возможная причина | Что попробовать |
|---|---|---|
| XHTTP не устанавливает соединение | Включён обычный mux.cool или не совпадают параметры транспорта | Выключить Mux, проверить path, mode и серверную сторону |
| REALITY отклоняет подключение | Ошибочный ключ, shortId, serverName или UUID | Сверить параметры клиента с конфигурацией сервера |
| После Fragment появились ошибки TLS | Сервер или промежуточное оборудование не принимает изменённые TLS-записи | Удалить finalmask.tcp и повторить подключение |
| XMUX создаёт слишком много TCP-соединений | Ошибочный лимит, нагрузка или особенности версии ядра | Обновить ядро и сравнить со стандартными настройками |
| После Noise перестал работать Hysteria2 | Сервер или промежуточная сеть реагирует на дополнительные UDP-пакеты | Удалить finalmask.udp, проверить UDP-порт и журналы |
| Mux ухудшил скорость загрузки | Конкуренция потоков внутри одного транспортного соединения | Отключить TCP Mux и повторить измерения |
| SOCKS5 работает, но часть программ подключается напрямую | Приложения не используют локальный прокси | Проверить настройки приложения или системную маршрутизацию |
Отдельно стоит проверить старые конфигурации, найденные в блогах и чатах. Ранее Fragment и Noise часто задавались внутри настроек исходящего freedom. В современном синтаксисе соответствующие функции доступны через FinalMask, где используются объекты tcp и udp.
Переносить старые названия полей в новую структуру механически нельзя. В частности, современный Fragment использует массивы lengths и delays, а не просто произвольное копирование старых одиночных значений.
Частые вопросы о XMUX, Mux, Fragment и Noise
Нужно ли включать XMUX вручную при использовании XHTTP?
Обычно нет. XHTTP уже использует собственное управление HTTP-соединениями. Для начала разумнее оставить стандартные настройки XMUX и проверить работу на реальной нагрузке. Ручные ограничения нужны при конкретных проблемах с количеством соединений, временем их жизни или совместимостью с обратным прокси.
Почему нельзя просто включить Mux и XMUX одновременно?
Классический Mux создаёт собственное мультиплексирование поверх транспортного соединения. XHTTP уже использует возможности HTTP/2 или HTTP/3. Дополнительный уровень не даёт автоматического ускорения, усложняет управление потоками и может нарушить совместимость. Современный Xray ограничивает двойное мультиплексирование, хотя отдельные варианты использования XUDP остаются возможными.
Можно ли совмещать Mux с VLESS REALITY Vision?
Классическое TCP-мультиплексирование mux.cool не следует совмещать с Vision. Если клиент и сервер используют flow xtls-rprx-vision, лучше оставить обычный Mux для TCP отключённым. Отдельные параметры XUDP не следует путать с мультиплексированием TCP-потоков.
Что лучше использовать в XMUX, maxConnections или maxConcurrency?
Выбор зависит от задачи. maxConnections ограничивает число базовых соединений, а maxConcurrency определяет предельное количество одновременно обслуживаемых проксируемых сеансов на каждом соединении. Совмещать положительные значения нельзя. Для большинства пользователей штатные значения XMUX лучше произвольно подобранных ограничений.
Почему Fragment не всегда создаёт несколько TCP-пакетов?
Фрагментация TLS-записей и разделение TCP-пакетов происходят на разных уровнях. Даже если ClientHello разделён на несколько TLS-записей, TCP и операционная система могут передать несколько записей внутри одного сетевого сегмента. Для проверки нужно анализировать структуру TLS и фактические пакеты отдельно.
Защищает ли Fragment имя сайта от DPI?
Нет гарантии. Fragment меняет форму передачи ClientHello, но не шифрует открытые поля. Анализатор, способный собрать TCP-поток и TLS-записи, восстановит исходное сообщение. Для сокрытия SNI существует отдельный механизм ECH, поддержка и работоспособность которого зависят от клиента, сервера и сетевой инфраструктуры.
Можно ли добавить Noise к любому VLESS-подключению?
Noise в FinalMask работает с UDP-датаграммами. Для обычного VLESS поверх TCP такой механизм не является заменой Fragment. Noise может применяться к подходящим UDP-транспортам, но корректность соединения зависит от реализации транспорта и поведения удалённой стороны.
Чем Noise отличается от Salamander в Hysteria2?
Noise добавляет посторонние UDP-пакеты перед основной передачей. Salamander преобразует сами пакеты QUIC и требует одинакового секрета на обеих сторонах. Поэтому Salamander меняет вид всего соответствующего UDP-обмена, а Noise только добавляет отдельные датаграммы.
Почему конфиг работает в Xray-core, но не работает в графическом клиенте?
Графические оболочки могут использовать разные версии встроенного ядра, собственные форматы профилей и неполную поддержку отдельных параметров. Некоторые программы также применяют глобальные настройки Mux ко всем подключениям. Проверьте фактическую версию Xray-core, экспортированный JSON и параметры, которые оболочка передаёт ядру.
Что в итоге выбрать
Если задача состоит в получении стабильного соединения, начинать лучше с простой конфигурации. Дополнительные механизмы стоит включать только после того, как обычный транспорт работает и измерения показывают конкретную проблему.
Для VLESS + REALITY + RAW с Vision классический Mux обычно не нужен. Fragment имеет смысл проверять отдельно, если наблюдаются проблемы на этапе TLS-рукопожатия. При нормальной работе соединения дополнительная фрагментация чаще усложняет схему, чем улучшает её.
Для XHTTP логичнее использовать встроенный XMUX со стандартными параметрами. Ручная настройка оправдана, если действительно требуется изменить количество соединений или поведение их повторного использования. При работе через CDN и обратные прокси дополнительно проверяйте совместимость режима XHTTP с HTTP-инфраструктурой.
Для Hysteria2 сначала проверьте обычный QUIC без UDP Noise. Добавление случайных пакетов не создаёт полноценную маскировку и может ухудшить надёжность. Если необходим другой формат всего UDP-обмена, следует отдельно изучить согласованные механизмы вроде Salamander, учитывая их требования к серверу.
Главный вывод. Mux экономит транспортные подключения, XMUX управляет соединениями HTTP/2 и HTTP/3, Fragment меняет структуру начальных TCP/TLS-данных, Noise добавляет UDP-пакеты. Четыре функции нельзя оценивать по принципу «чем больше включено, тем лучше».
Лучший Xray-конфиг не тот, где десятки хитрых параметров. Лучший конфиг предсказуемо устанавливает соединение, не создаёт лишних задержек, не расходует ресурсы без причины и остаётся понятным при диагностике. Если после удаления Fragment, Noise или Mux ничего не ухудшилось, возвращать лишние настройки нет смысла.
