Реальное iCloud-соединение от iPhone имеет характерный паттерн: конкретные API-эндпоинты, характерные тайминги, специфичные заголовки. VLESS-туннель с произвольным трафиком ведёт себя иначе: постоянный двунаправленный поток без пауз, нетипичные размеры пакетов, никаких iCloud API-запросов.
Каким образом можно определить API-эндпоинты, если путь, заголовки, параметры и тело запроса зашифрованы и стороннему наблюдателю виден только SNI?
WebSocket умер по конкретной причине: соединение начинается с HTTP Upgrade, после чего переходит в постоянный двунаправленный поток без характерных HTTP запрос-ответных пар. Этот паттерн детектируется давно и надёжно.
Вовсе он и не умер. WS/HTTPUpgrade-транспорт работает до сих пор. А причина его потенциальной уязвимости кроется главным образом в alpn HTTP/1.1, что при использовании CDN может быть подозрительным (по умолчанию они работают по HTTP/2 и HTTP/3, если поддерживается браузером). Подчеркиваю: может быть. Мне неизвестно ни об одном случае блокировки по этому признаку.
XHTTP разделяет восходящий и нисходящий трафик на отдельные HTTP-транзакции
Непонятно, о каких транзакциях идёт речь. Если о HTTP-запросах, то режим stream-one создаёт только один. Если про разделение нисходящего и исходящего потоков, то это работает только при дополнительной настройке.
packet-up — <...> Стартовый выбор по умолчанию.
Неправда. По умолчанию сервер принимает все три режима. А поведение клиента зависит от параметров TLS и alpn.
stream-up — <...> Быстрее, но не проходит через все CDN и реверс-прокси. Для прямого соединения без CDN.
Первое утверждение противоречит второму. Если некоторые CDN (в том числе самая популярная — Cloudflare) поддерживают этот режим, зачем безапелляционно утверждать, что он предназначен только для прямого соединения?
stream-one — <...> Медленнее, но единственный режим совместимый с XTLS-Vision.
Снова неправда. XTLS-Vision поддерживается всеми режимами xHTTP (и другими транспортами) при включении VLESS Encryption. (Но TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3).
Nginx для stream-one требует конкретных директив: ...
Достаточно grpc_pass
Версии Xray на клиенте и сервере обязаны совпадать. Несовпадение даёт либо глюки, либо полную неработоспособность без понятных ошибок. Это не «желательно» — это условие работоспособности.
Это отнюдь не условие работоспособности. Версии могут быть разными. Более того, насколько мне известно, во VLESS реализован механизм обмена информацией о версиях ядра клиента и сервера и функционал подстраивается под это соотношение. Да, отсутствие некоторых функций на одной стороне может привести к невозможности подключения, но далеко не всегда.
Ну и напоследок про таблицу. Сначала вы пишете про IP/ASN несоответствие, а потом называете связку VLESS + XHTTP + Reality «лучшей из доступных», даже лучше сервера со своим собственным доменом. Хотя в таком случае проблема несоответствия домена IP-адресу сохраняется.
Далее в таблице указано, что xHTTP работает через CDN только в режиме packet-up, что не соответствует действительности: функционально это поддерживается каждым из режимов. Packet-up лишь обеспечивает максимальную совместимость со всеми CDN.
По неизвестной причине TLS-отпечаток в конфигурации VLESS + xHTTP без Reality у вас удостоился лишь звания «хорошего», хотя utls работает одинаково и с ним, и без. Про XTLS-Vision уже писал.
Но самое удивительное, что вы заявляете о частичной поддержке работы через CDN конфигурацией VLESS + XHTTP + Reality. Это исключено. Reality никоим образом не может проходить через CDN, это противоречит принципу его работы.
Складывается ощущение, что ИИ принял самое непосредственное участие в написании этой статьи, потому что человек, который ознакомился с документацией, не допустил бы таких глупых ошибок.
Это обязательно? В документации рекомендовано использовать maxConcurrency вместо maxConnections:
Я выбрал maxConcurrency вместо maxConnections, чтобы предотвратить превращение количества соединений в фиксированный шаблон (fixed pattern). Конечно, если вам нравится второй вариант, можете настроить его вручную.
Вы упомянули, что многие советуют переход на проксирование через Cloudflare. Это странно, потому что он под блокировкой ещё с лета. У меня, например, к июлю полностью отвалился на нём xhttp — сначала только в режимах stream-up/stream-one, а затем и на packet-up. Не открывается и множество сайтов под ним — как на мобильных операторах, так и на ПК.
Протестировал xhttp с Reality — та же беда. Видимо, остается только вариант с размещением xray за обратным прокси. Но в таком случае, полагаю, можно использовать просто транспорт HTTP/2 вместо xhttp (по идее мультиплексирование должно работать на уровне протокола h2).
К статье есть серьёзные вопросы.
Каким образом можно определить API-эндпоинты, если путь, заголовки, параметры и тело запроса зашифрованы и стороннему наблюдателю виден только SNI?
Вовсе он и не умер. WS/HTTPUpgrade-транспорт работает до сих пор. А причина его потенциальной уязвимости кроется главным образом в alpn HTTP/1.1, что при использовании CDN может быть подозрительным (по умолчанию они работают по HTTP/2 и HTTP/3, если поддерживается браузером). Подчеркиваю: может быть. Мне неизвестно ни об одном случае блокировки по этому признаку.
Непонятно, о каких транзакциях идёт речь. Если о HTTP-запросах, то режим stream-one создаёт только один. Если про разделение нисходящего и исходящего потоков, то это работает только при дополнительной настройке.
Неправда. По умолчанию сервер принимает все три режима. А поведение клиента зависит от параметров TLS и alpn.
Первое утверждение противоречит второму. Если некоторые CDN (в том числе самая популярная — Cloudflare) поддерживают этот режим, зачем безапелляционно утверждать, что он предназначен только для прямого соединения?
Снова неправда. XTLS-Vision поддерживается всеми режимами xHTTP (и другими транспортами) при включении VLESS Encryption. (Но TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3).
Достаточно
grpc_passЭто отнюдь не условие работоспособности. Версии могут быть разными. Более того, насколько мне известно, во VLESS реализован механизм обмена информацией о версиях ядра клиента и сервера и функционал подстраивается под это соотношение. Да, отсутствие некоторых функций на одной стороне может привести к невозможности подключения, но далеко не всегда.
Ну и напоследок про таблицу. Сначала вы пишете про IP/ASN несоответствие, а потом называете связку VLESS + XHTTP + Reality «лучшей из доступных», даже лучше сервера со своим собственным доменом. Хотя в таком случае проблема несоответствия домена IP-адресу сохраняется.
Далее в таблице указано, что xHTTP работает через CDN только в режиме packet-up, что не соответствует действительности: функционально это поддерживается каждым из режимов. Packet-up лишь обеспечивает максимальную совместимость со всеми CDN.
По неизвестной причине TLS-отпечаток в конфигурации VLESS + xHTTP без Reality у вас удостоился лишь звания «хорошего», хотя utls работает одинаково и с ним, и без. Про XTLS-Vision уже писал.
Но самое удивительное, что вы заявляете о частичной поддержке работы через CDN конфигурацией VLESS + XHTTP + Reality. Это исключено. Reality никоим образом не может проходить через CDN, это противоречит принципу его работы.
Складывается ощущение, что ИИ принял самое непосредственное участие в написании этой статьи, потому что человек, который ознакомился с документацией, не допустил бы таких глупых ошибок.
Это обязательно? В документации рекомендовано использовать maxConcurrency вместо maxConnections:
Вы упомянули, что многие советуют переход на проксирование через Cloudflare. Это странно, потому что он под блокировкой ещё с лета. У меня, например, к июлю полностью отвалился на нём xhttp — сначала только в режимах stream-up/stream-one, а затем и на packet-up. Не открывается и множество сайтов под ним — как на мобильных операторах, так и на ПК.
Протестировал xhttp с Reality — та же беда. Видимо, остается только вариант с размещением xray за обратным прокси. Но в таком случае, полагаю, можно использовать просто транспорт HTTP/2 вместо xhttp (по идее мультиплексирование должно работать на уровне протокола h2).