net4people
[Russia] TLS connection-based policing applied on some home ISPs. VLESS with most of it variants stopped working as the result
Issue
There is growing evidence that some home internet providers in Russia are testing a new method of TLS policing, that mostly affects VLESS + Reality + vision and possibly other TLS proxies.
There is not much information yet, and this is not a widespread issue. It also does not affect my own providers directly, so obtaining reliable data is difficult because for me it requires using remote desktop software to make any tests.
So I hope this Topic will be a starting point.
Also this is not an issue described in issue #490, as this tried on many different ASNs (50+) as well as SNIs (also tried with own certificates and so-called "self steal").
ISPs affected so far
- MTS / MGTS (Moscow) — partially affected (issue temporarily fixed after router reboot)
- JustLan — partially affected
- LanInterCom — unclear how many users are affected
All this cases started at 12th November.
There's also one evidence on RTK at Izhevsk dated 1st November.
Symptomatic
The connection stops working entirely as soon as actual data starts flowing through the tunnel. The more traffic goes through, the sooner the disconnection happens (1) — doesn't seems to be based on bandwidth, rather on TLS connections being open and active with endpoint.
curl requests or opening the endpoint in a browser still works, even when the proxy is unusable.
After approximately 60 seconds, it becomes possible to reconnect to the same endpoint again.
Other TLS connections — normal HTTPS browsing and general internet usage — seem mostly unaffected.
What already have been tested by me and doesn't help with VLESS-TCP-Reality
- Disabling/enabling flow (
xtls-rprx-vision). - Fragmentation (need further testing for different values, could work?)
- DNS tweaks (connecting through IP instead of a domain name doesn't change anything)
What currently works for VLESS-TCP-Reality
- Changing port to any besides 443
- To keep 443 port operational — remove flow (xtls-rprx-vision) and add mux.
- XHTTP (or legacy H2/H3) should also work if used with mux.
- Routing only specific “needed” destinations through the proxy, while all other traffic goes directly — not as reliable as for reason described in (1)
- Any non-TLS protocol that isn’t blocked (e.g., ShadowSocks 2022 works) — not reliable because was already temporarily blocked or could be easily detected as "unknown" encrypted traffic
Notes
Any information appreciated
Update on 15.11:
- This issue is only on port 443
- Shaping policy applied by a provider on reaching unknown simultaneous connections with endpoint. For VLESS-TCP-Reality, to keep connection operational on port 443: flow (xtls-rprx-vision) should be removed, as well as mux should be applied. Other technics that reduce amount of TLS connections should also work.
Update on 22.11
Enrolled on more providers (based on regions). Mux/XHTTP also doesn't help much, at least not for all users.
телеграм есть? (только если готов показывать экран, дать ssh, делать все тесты что попрошу)
Do you have Telegram? (Only if you're willing to share your screen, provide SSH access, and do all the tests I ask)
телеграм есть? (только если готов показывать экран, дать ssh, делать все тесты что попрошу)
Вроде написал же, что проблема меня, к сожалению, не затронула.
Можно накидать сюда, что проверить стоит и потестить. По мере появления новой информация от меня и кого-то другого буду дополнять пост.
I think I wrote that the problem, unfortunately, didn't affect me.
You can share here what's worth checking and testing. As new information from me and others comes in, I'll update the post.
Hello. I already stumbled upon this issue some time ago. In my case it was a Tor obfs4 bridge, I thought that now home ISPs have the same method for blocking obfs4 connections as on mobile networks, but now it seems I've been wrong because if I took another set of obfs4 bridges, they would work without issues. (which means that it's an IP-range affected block?) IP range or fingerprint block... (not so sure about the fingerprint part - can obfs4 bridges have different connection fingerprints?) 🤔 It's affected on ports other than 443. My Tor connection would not connect and it would get stuck with those specific set of bridges, there is indeed a cooldown of around a minute before the 'block' gets lifted - is it similar to the GFW? As my post says, I was (and still am) able to use ByeDPI in conjunction with those 'affected' obfs4 bridges - and the connection works flawlessly! So if you first try to connect with the ByeDPI argument - the connection will work. (without any blocking) If, after that, you try to 'reconnect' without using the ByeDPI proxy - you won't be able to connect, if you try to connect RIGHT AFTER TRYING TO CONNECT WITHOUT BYEDPI - but using ByeDPI once again - the connection doesn't work (right away) - as if the 'firewall' remembers the 'connection that needs to be blocked' (when I tried to connect without ByeDPI) and I have to wait for a cooldown of around a minute or so to be able to connect flawlessly using ByeDPI again. (And then I guess, after pinging it with a 'bad' request, it blocks ALL TCP connections to that IP for a minute.) So, yes, I think that it affects some 'foreign' IP ranges or something... If you have this block - and the ability to use ByeDPI - I would suggest you to try to 'create' an argument for yourself. You can read the available options, the explanations and just make some gibberish/random argument (or try making multiple, etc...) and it might work, I don't really think that it'd be cool if I shared the exact ByeDPI argument I used here, because the censor would maybe be able to 'block' connections that are bypassing using that argument - too.
Есть те кто может помочь настроить обход через белый список на мобильных операторах? если что пишите https://t.me/joodjoy я в долгу не останусь
Is there anyone who can help set up a whitelist bypass on mobile operators? If so, please write to https://t.me/joodjoy. I will be indebted to you.
@0x3mp7y А моя описанная проблема здесь выше же связанна с этой блокировкой? Просто может нужно больше информации про это...
Is the problem I described above related to this block? Maybe I just need more information about it...
@someone2037492034 у меня Tor-мосты рабочие только из рандомных каналов в Telegram (не GetBridgesBot! оттуда мосты у меня не работают), к другим никак не подключиться, с VPN всё норм. В чём именно проблема не выяснял и DPI-байпасилки не пробовал (потому что они у меня с зимы 2025 не работают), но скорее всего просто автоматом блокаются айпишники известных мостов, что очевидно. Иногда мосты у меня перестают работать через минуту, но я заметил, что у меня так также с некоторыми публичными VPN-серверами, скорее всего как-то быстро обнаруживают, что это Tor-мост или VPN.
Кстати, для инфы, Shadowsocks у меня с начала 2024 уже не работает на Билайне (Сыктывкар), вне зависимо от того, какой сервер не подбери и что с протоколом не сделаешь. Удивляюсь, что у других он до сих пор работает.
Tor bridges only work when I get them from random Telegram channels (not the GetBridgesBot!—the bridges from there don't work for me), and I can't connect to any others. Everything works fine with a VPN, though. I haven't investigated the exact cause and haven't tried DPI bypass tools (since they don't properly work for me since winter of 2025), but I suspect it's likely that the IP addresses of well-known bridges are simply being automatically blocked, which seems obvious. Sometimes my bridges stop working after just a minute. I've also noticed similar behavior with some public VPN servers—likely they're quickly detected as either Tor bridges or VPNs.
Fyi Shadowsocks has stopped working for me on Beeline (Syktyvkar) since early 2024, regardless of the server chosen or any modifications made to the protocol settings. I'm surprised it still works for others.
у меня Tor-мосты рабочие только из рандомных каналов в Telegram (не GetBridgesBot! оттуда мосты у меня не работают)
Возможно потому что те мосты из рандомных каналов - 'частные мосты' или публичные, но до которых ещё не добрались. GetBridgesBot выдаёт мосты судя по дате основания Телеграм аккаунта из своей базы. Из опыта у мостов obfs4 (которые выдаёт бот) нет ротации почему-то. Вот все способы получения публичных мостов официально. На мобильных сетях есть другая блокировка - блокировка 'всех полностью зашифрованных протоколов' - из-за этого блока могут возникать в некоторых местах проблемы с подключением к мостам obfs4 - независимо от того блокировали их вручную или нет. Кстати из-за этой же блокировки 'всех зашиф. протоколов' на моб. сетях не работает Shadowsocks. (из коробки)
Perhaps because those bridges from random channels are ‘private bridges’ or public ones that haven't been reached yet. GetBridgesBot outputs bridges based on the date of creation of the Telegram account from its database. From experience, obfs4 bridges (which the bot outputs) do not rotate for some reason. Here are all the official ways to get public bridges. On mobile networks, there is another block - a block on ‘all fully encrypted protocols’ - because of this block, problems with connecting to obfs4 bridges may arise in some places, regardless of whether they were blocked manually or not. Incidentally, because of this same block on ‘all encrypted protocols’ on mobile networks, Shadowsocks does not work (out of the box).
но скорее всего просто автоматом блокаются айпишники известных мостов, что очевидно.
Возможно, что многие obfs4 мосты заблокированы по IP адресу, подтверждаю - это происходит, но такое не происходит с мостами WebTunnel - https-имитирующий вид моста, там применяется именно SNI-фильтрование, то есть с DPI spoofing можно обойти, некоторые из этих мостов поддерживают смену SNI полностью для подключения, но этот функционал ещё официально не добавлен в Tor Browser.
It is possible that many obfs4 bridges are blocked by IP address, I confirm that this happens, but this does not happen with WebTunnel bridges - an HTTPS-imitating type of bridge, where SNI filtering is used, meaning that DPI spoofing can be bypassed. Some of these bridges support complete SNI change for connection, but this feature has not yet been officially added to Tor Browser.
Иногда мосты у меня перестают работать через минуту, скорее всего как-то быстро обнаруживают, что это Tor-мост или VPN.
Незнаю, на билайне говорили что будут ставить какой-то DPI, который может "угадать" категорию сайта, к которому вы подключаетесь, хотя при чём здесь SNI, если мост (например obfs4, не WebTunnel) без него? Может быть какой-то блокировкой, которую можно обойти с помощью DPI spoofing или если нет. Странно... Ещё есть возможность, что такие проблемы - именно из-за похожих блокировок на этот тикет, блокировка определённых TLS/TCP соединений с кулдауном, от именно такой блокировки у меня есть byedpi команда, которая помогает с этим тоже, если надо могу дать в личке.
I don't know, Beeline said that they would install some kind of DPI that can “guess” the category of the site you are connecting to, but what does SNI have to do with it if the bridge (for example, obfs4, not WebTunnel) doesn't have it? Maybe some kind of block that can be bypassed with DPI spoofing, or maybe not. Strange... There is also a possibility that such problems are caused by similar blocks to this ticket, blocking certain TLS/TCP connections with a cool down. I have a byedpi command that helps with this kind of block, and I can send it to you in a private message if you need it.
DPI-байпасилки не пробовал (потому что они у меня с зимы 2025 не работают)
DPI-spoofing можно настраивать по-разному, поэтому может быть другой результат, если пробовать изменение конфигурации.
Если есть желание, можно попробовать такие аргументы ByeDPI (устновить можно оригинал или приложение для Android):
-s1 +s +h 1:0.7:3 --ttl 8 --tlsrec 1+s
-s1 +s +h 1:0.7:3 7:4:2 --ttl 8 --tlsrec 1+s
и уже дальше кастомизировать по-своему. (если будет работать, то должно чинить обычные сайты (также заблоканные WebTunnel мосты, получается) и обходить блок ТГ и WhatsApp звонков - хотя требует для этой цели чтобы у обоих собеседников был какой-то вид 'обхода')
DPI spoofing can be configured in different ways, so you may get different results if you try changing the configuration.
If you wish, you can try the following ByeDPI arguments (you can install the original or the Android app):
-s1 +s +h 1:0.7:3 --ttl 8 --tlsrec 1+s
-s1 +s +h 1:0.7:3 7:4:2 --ttl 8 --tlsrec 1+s
and then customize it to your liking. (If it works, it should fix regular websites (including blocked WebTunnel bridges, it turns out) and bypass the block on Telegram and WhatsApp calls—although this requires both parties to have some kind of “workaround”).
@someone2037492034 что ещё за "блокировка всех зашифр. протоколов"? SS на моб сети не работает из-за tls-in-tls или чего-то подобного т.к. http запросы через туннель проходят, но не https
What else is “blocking all encrypted protocols”? SS does not work on mobile networks due to tls-in-tls or something similar, because http requests pass through the tunnel, but https does not.
@someone2037492034 что ещё за "блокировка всех зашифр. протоколов"? SS на моб сети не работает из-за tls-in-tls или чего-то подобного т.к. http запросы через туннель проходят, но не https
Понятно. Почему же тогда любые obfs4 подключения имеют проблемы с подключением на мобильных сетях если он использует TCP?
I see. Why then do any obfs4 connections have problems connecting on mobile networks if it uses TCP?
Окей, почему тогда всё оживает если выбран SNI из белого списка и IP машины тоже из белых списков ? Тот же самый протокол, просто другой сервер и SNI.
Казань, Челябинск и другие города сразу оживают. Т.е как бы есть некий микс блокировок ?
Okay, why does everything come back to life if SNI is selected from the whitelist and the machine's IP is also from the whitelists? It's the same protocol, just a different server and SNI.
Kazan, Chelyabinsk, and other cities immediately come back to life. So, is there some kind of mix of blocks?
Окей, почему тогда всё оживает если выбран SNI из белого списка и IP машины тоже из белых списков ? Тот же самый протокол, просто другой сервер и SNI.
Казань, Челябинск и другие города сразу оживают. Т.е как бы есть некий микс блокировок ?
Потому что все что из ВЛ не подлежит фильтрации. Подтянут CIDR постепенно да и все, потом и уберут проверку на ВЛ. Поэтому это не релевантный способ и не относится никак к проблеме. Потому что все веб ресурсы не из ВЛ работают в основном без проблем.
Because everything from the whitelist is not subject to filtering. They will gradually tighten up CIDR and that's it, then they will remove the whitelist check. Therefore, this is not a relevant method and does not apply to the problem in any way. Because all web resources that are not from the whitelist work mostly without problems.
Окей, почему тогда всё оживает если выбран SNI из белого списка и IP машины тоже из белых списков ? Тот же самый протокол, просто другой сервер и SNI. Казань, Челябинск и другие города сразу оживают. Т.е как бы есть некий микс блокировок ?
Потому что все что из ВЛ не подлежит фильтрации. Подтянут CIDR постепенно да и все, потом и уберут проверку на ВЛ. Поэтому это не релевантный способ и не относится никак к проблеме. Потому что все веб ресурсы не из ВЛ работают в основном без проблем.
Понял. Есть идеи, какое решение на данный момент будет самым лучшим или всё это гадания сейчас ? Многие ломанулись на SS, который давно успешно блокируют. Вариант с белым списком пока всё ещё выглядит самым надёжным, но очень дорогим.
Got it. Any ideas on what the best solution would be at this point, or is it all just guesswork right now? Many people rushed to SS, which has been successfully blocked for a long time. The whitelist option still seems to be the most reliable, but it's very expensive.
Окей, почему тогда всё оживает если выбран SNI из белого списка и IP машины тоже из белых списков ? Тот же самый протокол, просто другой сервер и SNI. Казань, Челябинск и другие города сразу оживают. Т.е как бы есть некий микс блокировок ?
Потому что все что из ВЛ не подлежит фильтрации. Подтянут CIDR постепенно да и все, потом и уберут проверку на ВЛ. Поэтому это не релевантный способ и не относится никак к проблеме. Потому что все веб ресурсы не из ВЛ работают в основном без проблем.
Понял. Есть идеи, какое решение на данный момент будет самым лучшим или всё это гадания сейчас ? Многие ломанулись на SS, который давно успешно блокируют. Вариант с белым списком пока всё ещё выглядит самым надёжным, но очень дорогим.
Да, вы, безусловно, правы на счёт SS
За SS могу сказать что SS 2022 несмотря на все работал и блокировался только тогда, когда блокировались все шифрованные соединения вообще.
Обычный SS, к сожалению, действительно не стоит рассматривать, его умеют блокировать а т.ч. в РФ по характеристикам.
По БС вариант нормальный, но не могу сказать что в долгосрок стоит рассматривать. Вопрос времени когда это все подтянут. Я его для себя не рассматриваю по другим соображениям (как и многие другие)
Yes, you are absolutely right about SS.
As for SS, I can say that SS 2022 worked despite everything and was blocked only when all encrypted connections were blocked in general.
Unfortunately, regular SS is really not worth considering, as it can be blocked, including in Russia, due to its characteristics.
The whitelist option is acceptable, but I cannot say that it is worth considering in the long term. It is a matter of time before everything is updated. I do not consider it for myself for other reasons (as do many others).
протестил в новосибе сегодня на кабельном мтс: блочится почти любой HTTPS трафик, даже на ру серверы с .ru доменами, блок срабатывает на одновременное открытие ~12 потоков, это откатят 90% т.к. блок слишком жесткий
translate: I tested in Novosibirsk today on MTS cable: The block is triggered by opening of ~12 TLS connections in a short time range, even to Russian servers with .ru domains, even from real web browsers to real websites. 90% this will be rolled back because the block is too strict.
more details here https://ntc.party/t/16061/644 (ipv6-only website)
Мой сервак тоже блочат. Использую VLESS-TCP-XTLS-Vision (без REALITY). Некоторые соединения никогда не заканчиваются, обрывается только по тайм-ауту. Что странно, после нескольких попыток конкретный домен загружается, и продолжают загружаться (!) где-то 10 минут, а другие домены нет. Не знаю, может какая-то причуда v2rayN (клиент), когда много соединений "висят" без нормального обрыва.
Сам сервер пингуется нормально, и главная страница сайта сервера тоже открывается нормально.
это откатят 90% т.к. блок слишком жесткий
Сомневаюсь, они спят и видят "суверенный интернет" с цифровым железным занавесом, как в Северной Корее.
I have this issue. I'm using VLESS-TCP-XTLS-Vision (without REALITY). When being blocked, connections do not end, they simply hang until timout. What's weird is that when attempting to load a concrete domain several times it starts working for ~10 minutes, but not other domains. I dunno, maybe it's a quirk of v2rayN (client) that happens when too many connections "hang" instead of ending properly.
The server itself responds to pings from my PC just fine, and server's homepage also opens just fine.
90% this will be rolled back because the block is too strict.
Doubtful, this is likely "discouragement" tactic used to gradually stop regular people from trying to access wider Internet, so that eventually they could block everything except local connections.
HTTP Request Flood Test данный тест должен зависать если у вас есть новая сибирская блокировка, у меня зависает рандомно то на 12 то на 24
This test should freeze if you have this new Siberian blocking. Mine freezes randomly, sometimes at 12, sometimes at 24.
А сколько разных видов 'блокировок' здесь замешано? Выглядет как будто здесь несколько разных видов блокировок если честно. С TCP и TLS... Блокировка: 1. на некоторых ISP есть проблемы с доступом некоторых IP-зон: заключается в том, что есть проблемы с подключением через obfs4 и VLESS с кулдауном в одну минуту. Блокировка 2. Новая проблема, которая возникла в Сибири: частично блокируется https трафик.
How many different types of 'blocks' are used here? It seems as if there are multiple different blocks involved here, no? With TCP and TLS... The on-some-ISPs-accessing-some-IP-ranges-have-a-new-block-with-a-cooldown-of-1-minute, the VLESS problem seems similar to that and a new (and different, it seems) block in Siberia that 'meddles' with https?
А сколько разных видов 'блокировок' здесь замешано? Выглядет как будто здесь несколько разных видов блокировок если честно. С TCP и TLS...
How many different types of 'blocks' are used here? It seems as if there are multiple different blocks involved here, no? With TCP and TLS...
Так и есть. Нужен SNI из белого списка, плюс хороший сервер, не из крупных провайдеров и xhttp. Желательно кучу разных конфигураций.
That's right. You need SNI from the whitelist, plus a good server that isn't from a major provider, and xhttp. It's preferable to have a bunch of different configurations.
Так и есть. Нужен SNI из белого списка, плюс хороший сервер, не из крупных провайдеров и xhttp. Желательно кучу разных конфигураций.
Ну повторюсь про 'свою' блокировку obfs4 с кулдауном - её можно обойти через запутывание DPI.
Well, I'll repeat myself about ‘my’ obfs4 block with a cooldown—it can be bypassed by confusing the DPI.
Changing port/protocol is exactly what censors want you to do in order to enumirate you! DO NOT DO IT!!! It's extremely obvious that your webpage is not real webpage if suddenly your server start making connections over weird protocols/ports it never done before. It's how they gonna find you and potentially fine/jail you especially with recent laws they implemented about fining people if they find out you used vpn, or simply ip ban your server because you stuck out like sore thumb with that ss2022
@anon87103946482 reality proxies were obvious for years already because people set their dest to google, yahoo, etc... on vps servers which don't belong to google or yahoo. It's easier to find a reality proxy than most other proxy protocols
Changing port/protocol is exactly what censors want you to do in order to enumirate you! DO NOT DO IT!!! It's extremely obvious that your webpage is not real webpage if suddenly your server start making connections over weird protocols/ports it never done before. It's how they gonna find you and potentially fine/jail you especially with recent laws they implemented about fining people if they find out you used vpn, or simply ip ban your server because you stuck out like sore thumb with that ss2022
reality proxies were obvious for years already because people set their dest to google, yahoo, etc... on vps servers which don't belong to google or yahoo. It's easier to find a reality proxy than most other proxy protocols
Yeah, that's why people should understand basics and learn how to adapt and resolve new barriers instead of just using silly solutions :)
Changing port/protocol is exactly what censors want you to do in order to enumirate you! DO NOT DO IT!!! It's extremely obvious that your webpage is not real webpage if suddenly your server start making connections over weird protocols/ports it never done before. It's how they gonna find you and potentially fine/jail you especially with recent laws they implemented about fining people if they find out you used vpn, or simply ip ban your server because you stuck out like sore thumb with that ss2022
reality proxies were obvious for years already because people set their dest to google, yahoo, etc... on vps servers which don't belong to google or yahoo. It's easier to find a reality proxy than most other proxy protocols
Yeah, that's why people should understand basics and learn how to adapt and resolve new barriers instead of just using silly solutions :)
Блокировки откатили, но на будущее, неужели reality xhttp с кастомным портом, такая плохая идея при таких блокировках ?
The blocks have been rolled back, but for the future, is reality xhttp with a custom port really such a bad idea with these kinds of blocks?
@4erdenko точечно реалити ещё не блокировали
pointwise reality has not yet been blocked.
Changing port/protocol is exactly what censors want you to do in order to enumirate you! DO NOT DO IT!!! It's extremely obvious that your webpage is not real webpage if suddenly your server start making connections over weird protocols/ports it never done before. It's how they gonna find you and potentially fine/jail you especially with recent laws they implemented about fining people if they find out you used vpn, or simply ip ban your server because you stuck out like sore thumb with that ss2022
reality proxies were obvious for years already because people set their dest to google, yahoo, etc... on vps servers which don't belong to google or yahoo. It's easier to find a reality proxy than most other proxy protocols
Yeah, that's why people should understand basics and learn how to adapt and resolve new barriers instead of just using silly solutions :)
Блокировки откатили, но на будущее, неужели reality xhttp с кастомным портом, такая плохая идея при таких блокировках ?
Нет, но порт менять не стоит. К слову в принципе все вышло как и было написано в ишью, основным решением было просто уменьшить количество TLS соединений с хостом
No, but you shouldn't change the port. By the way, everything turned out as described in the issue. The main solution was simply to reduce the number of TLS connections to the host.
Just to add my 5 cents, I reside in one of the affected regions and experienced these blockages; disabling xtls-rprx-vision worked as the author suggested, as well as using a non-standard port. Apart from that, gRPC and xHTTP Xray connections also worked at that time.
They rolled back the blockage around the 25th of November.
The blocks have been rolled back, but for the future, is reality xhttp with a custom port really such a bad idea with these kinds of blocks?
Making yourself visible is a bad idea in general.
The block wasn't lifted for everyone, there is 1 person who reported that my http test triggers the block at 9 requests
Я вроде бы перепробовал всё, что описано тут Ничего не помогло
I've seen some of what's been described here Nothing helped
