Автор, если Вы не можете написать статью без использования ИИ, то хотя бы проверяйте информацию, которую он предоставляет.
25 мая 2026. <...> Под раздачу попали VLESS, Xray, MTProto, WireGuard, gRPC.
Xray не мог попасть под раздачу, потому что это не протокол, а фреймворк, на основе которого работают протоколы с различными настройками. WireGuard блокируется уже несколько лет, 25 мая не сыграло в его судьбе никакой роли. gRPC сам по себе для проксирования не используется и работает вместе с VLESS.
2 июня 2026 — и тут же отдельный инфраструктурный фактор, к ТСПУ вообще не относящийся: европейский ДЦ nLighten без предупреждения обесточил стойки. О нём подробно в разделе 7...
Зачем в статье, посвящённой работе ТСПУ, подробно разбирать ситуацию, вообще не относящуюся к ТСПУ? Примечательно, что нейронка далее по тексту это подмечает:
«Два события совпали по времени с июньскими блокировками, но к ТСПУ прямого отношения не имеют, и сваливать их в один нарратив о «заморозке по fingerprint» — ошибка».
А вот про имена — осторожно. В обсуждениях в «подозрительный» список заносят Selectel, Yandex.Cloud, Cloud.ru. <...> Yandex.Cloud — системообразующий провайдер, за которым стоит изрядная доля рунета; его попадание в список поведенческой заморозки — заявление экстраординарное, и пруф ему нужен уровня пакетного дампа. <...> Я и сам прогнал 12-часовой замер с RU-машины (Ростелеком, AS34168, 72 цикла, 14 июня) к GitHub/PyPI/Fastly: ни одной заморозки, медиана TLS-хендшейка ~135 мс, доступность 99–100%
А причем здесь GitHub с PyPI и Fastly? Речь же шла о российских облаках, разве нет?
VLESS-клиенты (Happ, v2rayTun, Hiddify) по умолчанию используют мультиплексирование (XMUX/Mux) или connection pooling
Xmux используется только в xHTTP и работает на уровне ядра, клиенты сами по себе здесь ни при чём. Mux клиенты по умолчанию не используют, нужно включать его.
Реальный браузер после хендшейка генерирует специфичные паттерны — API-запросы, тайминги, ALPN. А туннель — это непрерывный двунаправленный поток без характерных пауз и смены размеров пакетов.
Как, по-Вашему, DPI определяет наличие или отсутствие запросов к API, если заголовки, путь и тело запроса зашифрованы? Внутри TLS может быть что угодно, а API используют в том числе для загрузки файлов, так что объём трафика здесь сомнительная характеристика. Просмотр видео по HTTP/2 с метриками тоже может выглядеть как непрерывный двунаправленный поток. А вот паузы и размеры пакетов, пожалуй, маркером будут.
TLS-in-TLS: фундаментальная проблема
Непонятно, причём здесь это. Нет никаких доказательств, подтверждающих фильтрацию на основе TLS-in-TLS в России.
уязвимость: если DPI научится детектировать «один долгий GET + много коротких POST к одному path» как аномалию — попадёт под удар
Опять же, каким образом возможно обнаружение типа и пути запроса внутри TLS-соединения?
блокировка QUIC/UDP на 443 = блокировка HTTP/3 для всего рунета (YouTube, Google, Cloudflare) — РКН этого избегает;
YouTube и Cloudflare уже давно блокируются. QUIC ограничивается у некоторых провайдеров.
Транспорт: VLESS+TCP+mux. ALPN: h1.
Может быть и h2.
<...> исторический ряд OpenVPN → WireGuard → Shadowsocks → VLESS → REALITY — это иллюстрация, а не доказательство.
Почему Reality стоит после VLESS, если это не прокси-протокол, а замена обычному TLS, которая, как правило, работает в рамках VLESS?
Короче говоря, статья представляет собой нейрообработку недавней публикации «О схеме ограничений РКН в июне 2026-го» (для понимания ситуации гораздо полезнее будет прочитать её), а также ряда других источников разной степени авторитетности.
К слову, отпечаток Chrome в ядрах xray и sing-box отличается и у последнего (во всяком случае, 3 недели назад) не вызывал блокировку. Предполагаю, что и Firefox тоже, поскольку только на sing-box он вызывает у меня ту самую заморозку.
Трафик к my.telegram.org - это обычный HTTPS поверх TLS, ровно такой же, как у любого банка, любого магазина, любого корпоративного сервиса. Если бы провайдер фильтровал этот трафик по содержимому, легло бы пол-инета. Значит, режут на самом дешёвом этапе - на разрешении имени.
Фильтруют в том числе и по содержимому, а именно по значению SNI (домен сайта), которое передаётся при TLS-handshake в незашифрованном виде. Когда мы говорим про Telegram, то сочетаются блокировки по DNS, SNI, сигнатурам MTProto (собственный протокол Telegram) и MTProxy (встроенный в Telegram прокси-протокол).
У Вашего провайдера по какой-то причине не блокируется доступ к my.telegram.org по SNI, потому что у меня (как и, подозреваю, у большинства) без дополнительных средств он не открывается даже при использовании DoH.
Я указал на ситуацию в целом. Она зависит от конфигурации ядра (как правило, xray или sing-box) и (или) клиента.
Можно, например, перехватывать незащищённые DNS-запросы и перенаправлять их на другой DNS-сервер, блокировать их или менять протокол на основе заданных правил. Во многих клиентах, включая приложение автора, можно настроить поведение DNS в настройках.
Если Вы используете Reality, то это обычное поведение. При инициировании TLS-соединения Reality подключается к маскировочному сайту. Когда этот сайт не отвечает, не работает и прокси.
Вопрос об отношении С. к материи составляет основной вопрос философии. Диалектико-материалистич. решение этого вопроса состоит в том, что С. есть свойство высокоорганизованной материи, функция того сложного “куска материи”, к-рый называется мозгом человека.
Философская Энциклопедия. В 5-х т. — М.: Советская энциклопедия. Под редакцией Ф. В. Константинова. 1960—1970
Смысл моего суждения состоял в том, что нахождение сознания внутри материального объекта не означает материальности самого сознания и превалирования материи над сознанием. Иными словами, даже если согласиться с материалистическим пониманием сознания в этом аспекте, вышеизложенное не подтверждается.
Тот факт, что сознание заключено в материальный объект (головной мозг), не говорит о том, что всё материально, и даже о первичности материи, поскольку помимо материальной формы есть и содержание — деятельность сознания, и она носит по большей части идеалистический характер. Все сведения об окружающем мире, которые известны человечеству, были приобретены посредством неё: будь то познание через органы чувств или построение логических конструкций, опытным или теоретическим путём.
Я вовсе не отрицаю вклада нейробиологов, изучающих деятельность мозга, но то, что происходит внутри нашего сознания, не может быть в достаточной степени объяснено на основе данных, полученных таким путём.
Если всё, что мы знаем о мире, прошло через «фильтр» сознания, то мы в принципе не можем безапелляционно заявлять об объективном существовании чего-либо в материальном мире в том виде, в котором оно предстало нашему сознанию. Вся наша жизнь решающим образом зависит от идей. Даже слова обусловлены ими. Предательство, ложь, героизм, правда, добро, зло — от того, что человек вкладывает в их смысл, зависит и выраженная ими мысль, а мысль порождает наше поведение. А значит, утверждения о всеобщей материальности и примате материи неверны.
Реальное 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).
Автор, если Вы не можете написать статью без использования ИИ, то хотя бы проверяйте информацию, которую он предоставляет.
Xray не мог попасть под раздачу, потому что это не протокол, а фреймворк, на основе которого работают протоколы с различными настройками. WireGuard блокируется уже несколько лет, 25 мая не сыграло в его судьбе никакой роли. gRPC сам по себе для проксирования не используется и работает вместе с VLESS.
Зачем в статье, посвящённой работе ТСПУ, подробно разбирать ситуацию, вообще не относящуюся к ТСПУ? Примечательно, что нейронка далее по тексту это подмечает:
«Два события совпали по времени с июньскими блокировками, но к ТСПУ прямого отношения не имеют, и сваливать их в один нарратив о «заморозке по fingerprint» — ошибка».
А причем здесь GitHub с PyPI и Fastly? Речь же шла о российских облаках, разве нет?
Xmux используется только в xHTTP и работает на уровне ядра, клиенты сами по себе здесь ни при чём. Mux клиенты по умолчанию не используют, нужно включать его.
Как, по-Вашему, DPI определяет наличие или отсутствие запросов к API, если заголовки, путь и тело запроса зашифрованы? Внутри TLS может быть что угодно, а API используют в том числе для загрузки файлов, так что объём трафика здесь сомнительная характеристика. Просмотр видео по HTTP/2 с метриками тоже может выглядеть как непрерывный двунаправленный поток. А вот паузы и размеры пакетов, пожалуй, маркером будут.
Непонятно, причём здесь это. Нет никаких доказательств, подтверждающих фильтрацию на основе TLS-in-TLS в России.
Опять же, каким образом возможно обнаружение типа и пути запроса внутри TLS-соединения?
YouTube и Cloudflare уже давно блокируются. QUIC ограничивается у некоторых провайдеров.
Может быть и h2.
Почему Reality стоит после VLESS, если это не прокси-протокол, а замена обычному TLS, которая, как правило, работает в рамках VLESS?
Короче говоря, статья представляет собой нейрообработку недавней публикации «О схеме ограничений РКН в июне 2026-го» (для понимания ситуации гораздо полезнее будет прочитать её), а также ряда других источников разной степени авторитетности.
К слову, отпечаток Chrome в ядрах xray и sing-box отличается и у последнего (во всяком случае, 3 недели назад) не вызывал блокировку. Предполагаю, что и Firefox тоже, поскольку только на sing-box он вызывает у меня ту самую заморозку.
Alt + 0151 на numpad.
Если у вас «полный дефолт» на xhttp, то xmux работает с настройками по умолчанию.
Фильтруют в том числе и по содержимому, а именно по значению SNI (домен сайта), которое передаётся при TLS-handshake в незашифрованном виде. Когда мы говорим про Telegram, то сочетаются блокировки по DNS, SNI, сигнатурам MTProto (собственный протокол Telegram) и MTProxy (встроенный в Telegram прокси-протокол).
У Вашего провайдера по какой-то причине не блокируется доступ к my.telegram.org по SNI, потому что у меня (как и, подозреваю, у большинства) без дополнительных средств он не открывается даже при использовании DoH.
Эти сайты не грузятся из-за того, что они под Cloudflare.
Я указал на ситуацию в целом. Она зависит от конфигурации ядра (как правило, xray или sing-box) и (или) клиента.
Можно, например, перехватывать незащищённые DNS-запросы и перенаправлять их на другой DNS-сервер, блокировать их или менять протокол на основе заданных правил. Во многих клиентах, включая приложение автора, можно настроить поведение DNS в настройках.
Если Вы используете Reality, то это обычное поведение. При инициировании TLS-соединения Reality подключается к маскировочному сайту. Когда этот сайт не отвечает, не работает и прокси.
Смысл моего суждения состоял в том, что нахождение сознания внутри материального объекта не означает материальности самого сознания и превалирования материи над сознанием. Иными словами, даже если согласиться с материалистическим пониманием сознания в этом аспекте, вышеизложенное не подтверждается.
Зависит от настроек tun в клиенте и конфигурации xray/sing-box.
Тот факт, что сознание заключено в материальный объект (головной мозг), не говорит о том, что всё материально, и даже о первичности материи, поскольку помимо материальной формы есть и содержание — деятельность сознания, и она носит по большей части идеалистический характер. Все сведения об окружающем мире, которые известны человечеству, были приобретены посредством неё: будь то познание через органы чувств или построение логических конструкций, опытным или теоретическим путём.
Я вовсе не отрицаю вклада нейробиологов, изучающих деятельность мозга, но то, что происходит внутри нашего сознания, не может быть в достаточной степени объяснено на основе данных, полученных таким путём.
Если всё, что мы знаем о мире, прошло через «фильтр» сознания, то мы в принципе не можем безапелляционно заявлять об объективном существовании чего-либо в материальном мире в том виде, в котором оно предстало нашему сознанию. Вся наша жизнь решающим образом зависит от идей. Даже слова обусловлены ими. Предательство, ложь, героизм, правда, добро, зло — от того, что человек вкладывает в их смысл, зависит и выраженная ими мысль, а мысль порождает наше поведение. А значит, утверждения о всеобщей материальности и примате материи неверны.
К статье есть серьёзные вопросы.
Каким образом можно определить 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).