🪤 Ловушка обновления 3x-ui: как scMinPostsIntervalMs триггерит ТСПУ

О чём заметка

Узкий, но коварный случай «Июньской блокировки 2026»: после обновления панели 3x-ui (веб-панель управления прокси-ядром Xray) до ветки 3.x.x у многих администраторов массово отвалились соединения — особенно на мобильных операторах. Причина не в самих серверах, а в том, что новая версия панели стала автоматически вшивать в конфиг Xray параметр scMinPostsIntervalMs: 30, который сам по себе триггерит ТСПУ (Технические Средства Противодействия Угрозам) — оборудование DPI (Deep Packet Inspection, глубокий анализ пакетов) Роскомнадзора. Здесь — что это за параметр, почему он попадает под фильтр и как починить. Общая картина блокировки (И-триггер из трёх условий) — в обзорной заметке про «Июньскую блокировку 2026».

Статус данных

Связь параметра scMinPostsIntervalMs: 30 со срабатыванием ТСПУ — это эмпирическое наблюдение из разбора eByeBots (7 июня 2026): «опытным путём доказано, что именно это ограничение мгновенно триггерит алгоритмы ТСПУ на мобильных сетях». Это не официальная документация и не подтверждённая разработчиками Xray причинно-следственная связь; объяснение «почему» (через поведенческий признак частоты) — реконструкция, а не утверждение eByeBots. Параметры фильтра различаются по операторам и регионам и со временем меняются. Перед откатом версии сделайте резервную копию конфигурации.

TL;DR

• Симптом: после обновления 3x-ui до ветки 3.x.x прокси (например, на протоколе VLESS — лёгком прокси поверх Xray) на транспорте XHTTP (маскировка трафика под обычный HTTP, ранее назывался SplitHTTP) начали массово блокироваться, особенно на мобильном интернете.
• Причина: панель стала автоматически добавлять в конфиг ядра Xray два параметра — "scMaxEachPostBytes": "1000000" и "scMinPostsIntervalMs": "30". Именно scMinPostsIntervalMs: 30 — минимальный интервал между POST-запросами (HTTP-метод, которым клиент отправляет данные на сервер) — разрешает слать их уже через 30 мс после предыдущего, то есть очень часто при активной передаче. ТСПУ ловит эту «суетливость» как признак туннеля.
• Почему это триггер: частые короткие POST делают поведение туннеля «машинным» — это родственно поведенческому признаку «частоты», на котором стоит третье условие И-триггера ТСПУ. Строго оно считается по числу новых TLS-сессий к одному адресу (см. обзорную заметку), но «суетливый» транспорт питает тот же сигнал.
• Фикс: вручную вырезать scMaxEachPostBytes и scMinPostsIntervalMs из конфига — на сервере (вкладка «Расширенный шаблон») и из клиентских ссылок (блок Extra). Если не помогло — откатить панель до стабильной 2.9.4.

Что такое 3x-ui и XHTTP

• 3x-ui — популярная веб-панель для управления сервером Xray (ядро прокси, на котором работают VLESS, VMess, Trojan и др.). Через неё админ заводит пользователей, генерирует ссылки-подключения и правит конфиг, не залезая в JSON руками.
• XHTTP (ранее SplitHTTP) — один из транспортов Xray: он маскирует трафик прокси под обычный HTTP-обмен, разбивая поток на серию HTTP-запросов (в том числе POST — метод отправки данных от клиента к серверу). Маскировка под HTTP помогает против DPI — но только пока поведение запросов выглядит «человеческим».

На пальцах

Представь курьера, который носит письма (данные) через проходную (ТСПУ), маскируясь под обычного посетителя. Пока он ходит спокойно, охрана не реагирует. Но если разрешить ему слать письма уже через 30 миллисекунд после предыдущего — при потоке данных он начинает мелькать в проходной по 30+ раз в секунду. Никакой обычный посетитель так не делает; охрана опознаёт «слишком частый» паттерн и блокирует. scMinPostsIntervalMs: 30 — это и есть снятый тормоз, который позволяет курьеру бегать как можно чаще и выдаёт маскировку.

Почему именно scMinPostsIntervalMs: 30 опасен

scMinPostsIntervalMs задаёт минимальный интервал (в миллисекундах) между POST-запросами, которыми клиент отправляет данные на сервер в режиме XHTTP. Это нижний порог (троттл), а не форсированный темп: значение 30 не заставляет слать POST каждые 30 мс, но разрешает делать это уже через 30 мс после предыдущего — то есть до ~33 запросов в секунду на пике отдачи. При активной передаче клиент упирается в этот разрешённый максимум, и поведение становится «суетливым».

Для ТСПУ это выглядит как поток частых однотипных запросов к одному адресу — поведение, по которому фильтр отличает машинный туннель от обычного браузинга. В терминах И-триггера «Июньской блокировки» это близко к третьему условию (частота). Важная оговорка: строго третье условие модели измеряется по числу параллельных TLS-сессий к одному имени хоста за окно времени, а POST-запросы XHTTP идут внутри уже установленных сессий — поэтому «частые POST → третье условие» это реконструкция механизма, а не дословное утверждение источника. Эталон eByeBots даёт лишь эмпирический факт: с scMinPostsIntervalMs: 30 ТСПУ срабатывает.

Парный параметр scMaxEachPostBytes: "1000000" задаёт максимальный размер одного POST (1 МБ) и вшивается панелью заодно; триггерной роли эталон ему не приписывает — «опытным путём доказано» срабатывание именно от scMinPostsIntervalMs: 30.

Почему «на мобильных»

По наблюдениям eByeBots эффект сильнее всего на сотовых операторах. Это согласуется с тем, что параметры ТСПУ «плавающие» и зависят от оператора и региона: на одних сетях порог частоты жёстче, на других — мягче. Поэтому один и тот же конфиг может работать на домашнем провайдере и падать на мобильном.

Как починить

Главное

Нужно убрать из конфигурации навязанный обновлением «слишком частый» интервал POST — тогда поведение XHTTP-транспорта перестаёт пробивать порог частоты.

• Сделать резервную копию текущего конфига Xray и клиентских ссылок.
• На сервере открыть в 3x-ui вкладку «Расширенный шаблон» (Advanced Template) и удалить строки (это фрагмент внутри настроек XHTTP-транспорта, а не самостоятельный JSON):

  "scMaxEachPostBytes": "1000000",
  "scMinPostsIntervalMs": "30"

• В клиентских ссылках убрать эти же параметры из блока Extra (иначе клиент продолжит слать частые POST, даже если сервер их не требует).
• Перевыпустить/обновить ссылки у пользователей и переподключиться, проверить доступность на мобильном операторе (где симптом проявлялся сильнее всего).
• Если не помогло — откатить (даунгрейд) панель 3x-ui до стабильной версии 2.9.4, в которой эти параметры не вшиваются автоматически.

Оговорка

Это лечит поведенческий признак (частоту POST-запросов XHTTP). Если ваш прокси режется по другому условию И-триггера — по подсети сервера или по TLS-отпечатку (например, fingerprint: chrome в REALITY) — правка scMinPostsIntervalMs не поможет, нужны меры из соответствующих заметок. Параметры фильтра меняются: значения, безопасные сегодня, могут попасть под правило завтра.

Источники

Источник	Дата	Что отсюда взято
eByeBots — технический разбор «Июньской блокировки 2026»	7 июня 2026	Сам факт ловушки в 3x-ui 3.x.x, параметры "scMaxEachPostBytes": "1000000" и "scMinPostsIntervalMs": "30", эффект на мобильных сетях, фикс (вырезать строки из «Расширенного шаблона» и блока Extra, откат до 2.9.4).

📚 См. также

• Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026» — обзор И-триггера из трёх условий; этот случай — пробитие третьего условия (частота) кривым параметром транспорта.
• Как DPI «замораживает» VLESS+REALITY: схема июня 2026 — почему DPI смотрит на поведение соединения, а не на содержимое; выбор транспорта и фингерпринта.
• 2 Only + TLS 1.2 против ТСПУ — тот же поведенческий признак «частоты», но со стороны обычного сайта.
• 3X-UI API — управление 3x-ui программно.