Стабильно блок висит, периодически проверяю, возможно конечно оживает на очень короткий срок, но больше похоже на постоянку, в сап хоста не писал, вряд ли они скажут что-то отличное от - не меняли ничего у себя
А как на винде этот список внести?
fuckRKN.ps1 (2.5 KB)
Нейросеть помогла мне сделать такое, суть такая же, что и у скриптов для linux, но сделано на powershell и встроенном брандмауере винды, должно работать, только что проверял. Только надо разрешить запуск неподписанных скриптов в powershell
У меня около пары часов назад произошел отвал vless, хотя до этого работало всегда идеально. Через старую версию nekoray 3.26 чекнул логи, а там прикол
2025/12/06 16:55:35 127.0.0.1:53501 accepted //www.youtube.com:443 [http-in -> proxy]
2025/12/06 16:55:37 [Warning] [1996478276] app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: failed to find an available destination > common/retry: [transport/internet/grpc: failed to dial gRPC > transport/internet/grpc: Cannot dial gRPC > rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: x509: certificate is valid for *.max.ru, max.ru, not telegram.org"] > common/retry: all retry attempts failed
Исходя из этого поменял SNI в настройках vless
Dest (Target): max.ru:443
SNI: max.ru,www.max.ru
Как бы смешно это не было, но все заработало как раньше
Сервер ваш или чужой? Выглядит так, что кто-то поменял SNI в настройках сервера.
мой конечно, у меня изначально SNI был на отвали поставлен, но раньше работало)
когда поменял на макс так сразу завелось обратно
В панели кто-то поменял sni для реалити конфига на max, либо домен который был прописан сам используется для реалити и владелец поставил маскировку под макс
Если напишете какой домен был прописан то это легко проверить
я еще раз говорю, сервер мой и меняю все только я. отвал был не из-за того что я поменял что-то, а просто так. вылечил я отвал тем, что указал сайт макса как sni
прочитайте вторую часть сообщения
Я бы на вашем месте… Поменял все пароли…
Либо дело не во взломе панели, а провайдер/ТСПУ занимается переадресацией если в SNI находит telegram.org
нет. ни разу не udp триггер это. после нескольних дней тестов и полном выключение udp трафика, а также дампом tcpdump с захватом всего udp трафика (чтобы наверняка) с тотечными тайм стемпами и курлированием while true на условный домен который вырубается (а с ним и пол интернета) показало, что блокировака по времени происходит БЕЗ УЧАСТИЯ UDP ТРАФИКА НА МОМЕНТ БЛОКИРОВКИ
еще также замечено что этот тспу модуль работает в режиме overwrite. то есть он работает даже поверх черного списка. есть ресурс который заблокирован и открывается через zapret1, когда приходит блок с временного модуля, ресурс больше не работает на старой стратегии. это НЕ IP блок! пинги и 3-way handshake и предположительно ssh (голый ssh не стал проверять к своему серверу, может этого они и ждут от меня) тоже работает. блокируются точно весь http и чистый http и tls 1.2. blockcheck для zapret1 стратегий не находит ни на http ни на tls
кстати длятся эти блоки уже не 1-5 минут, а 20.
С ~ 2025-12-09T13:00:00Z подтвержденная блокировка VLESS-XTLS-Vision-Reality на РТ провод, Западная Сибирь.
Блокировка срабатывает на 1-м провайдерском хопе (тспу стоит?). Весь исходящий трафик в сторону сервера блокируется. Tracert дальше 1 хопа так же не ходит. Снимается блок спустя 15 минут.
Спойлер
Ловят по ?fingerprint?, смена помогает, но не на долго.
upd: кол-во соединений к серверу похоже так же имеет значение на срабатывание блокировки.
Уже открытые соединения продолжают работать какое-то время. Новые соединения не устанавливаются.
dest, sni под self-host, зарубежный VPS.
какая версия сервера и клиента? там вроде была проблема с TLS фингерпринтом у x-ray младше v25.10.15 и sing-box < 1.12.12
Xray 25.12.8 и там и там.
Второй раз ловлю блок, когда загружаются вот это большое кол-во картинок на этом сайте.
Спойлер
Причём триггер блокировки срабатывает на одном физ. подключении РТ и одновременно на двух разных физических подключениях РТ, сервер так же перестает быть доступным на 15 минут. Все физ подключения разнесены на пару 10 км друг от друга.
Я ещё пол года назад когда изучал так называемый udp dht триггер, который тогда банил ovh/hetzner и т.д., пришел к выводу что никакой он не dht, и никакой он не udp, там просто список айпишников на которые нельзя обращаться, после обращения на которые банятся айпишники всего хостера, и тогда это длилось ровно 10 минут. И не важно какой пакет, и не важно его длина, для udp это был просто пакет, а для tcp это был именно факт установившегося соединения, за попытку соединения не срабатывал блок, но ip на которые нельзя было обращаться были одни и те же и для tcp и для udp
@the-d-kid прав, триггерят не только udp пакеты, но и установившиеся tcp сессии. Просто большинство триггеров были найдены через udp, поэтому изначально возникла такая неверная теория. Пруф tcp был описан лично мной тут: Блокировка OVH после отправки UDP-пакетов DHT-пирам - #60 by xActo
Давай выполним простой эксперимент - когда у тебя нет активного блока, сделай telnet 82.198.246.97 180. Это тот самый публичный прокси, про который я писал. У меня это триггерит блок OVH, Scaleway и всего прочего.
Можно ещё проще:
https://www.rarlab.com/okhttps://test-ipv6.com/???https://www.rarlab.com/???
РТК на проводе стал жестко закручивать VLESS последние дни, сначала день был rate limit по кол-ву запросов к одному серверу (даже без впн) - при включении Mux в клиентах на время пофиксило
сейчас даже это начало троттлить (или моя сигнатура проявилась), в общем видимо всем скоро придется переходить на последний вариант - xhttp (даже на реверсе), с ним залетало, будто без впн
Так по дефолту он очень слабый, все равно много соединений открывает, легкий вариант это поменять конфиг на grpc