это не ко мне вопросы. Блокировать fp chrome это полная глупость и некомпетентность того кто так пытается что-то победить.
Статья нейрослоп, можно не читать
скорее наоборот это хорошая новость для нас как для пользователей прокси. это по сути означает их капитуляцию и невозможность заблочить именно влесс отдельно от легитимного веб трафика. отсюда эти нелепые фильтры по количеству сессий и фингерпринту - пытаются зацепиться хоть за какую-то характеристику. подстроиться под это нет особой проблемы - главное не иметь дефолтный копи-паст конфиг “как у всех”
Для меня на мобильном билайне блокируются все значения fingerprint в v2rayNG кроме firefox, safari и randomized, а также OkHttp в Browser Dialer (WebView же блокируется). Причём блокировка касается только некоторых подсетей, и неважно, какое значение maxConnections стоит. С QUIC нет подобных блокировок.
Тестировал ещё с Exclave, из браузерных блокируются hellochrome_83, hellochrome_87, hellochrome_96, hellochrome_100, hellochrome_102, hellochrome_133, helloedge_85, helloedge_106, helloios_13, helloqq_11_1 и hellosafari_16_0.
статья вброс.
Блоки по chrome как-то тестируют регионами.
Вроде была новость, что это оставили только на зарубежный трафик
такой блок влияет и на mt-proto и троян tcp, а не только влесс xhttp как в статье
trusttunnel подними, настройка буквально 10 минут составляет, правда у меня их quic вариант не работает на мегафоне мобильном, только https подобный трафик. сам впн у них шустрый, в клиенте есть тоже маршрутизация.
Безопасно, просто надо клиент обновлять иногда. В issues писали, что фп меняется не с каждой версией, это радует.
Firefox, наверное, не банят из-за долговечной ESR, но это мое предположение
что вы добьетесь обновлением клиента? хром последней версии блокируется, реальный браузер. firefox и остальные не тронуты (ну кроме сафари, где тоже были проблемы с реальным браузером, за что его хз) т.к. не являются дефолтными фингерпринтами в прокси клиентах
На случай полной блокировки старых версий фп. Видел про блок chrome 120, но хз полный ли это блок или только по количеству соединений - https://github.com/XTLS/Xray-core/pull/6181#issuecomment-4567373533
Ядра делаются китайцами в своей реальности, для китайского gfw блокировать chrome и другие браузеры по отпечатку - недопустимый collateral, поэтому китайцы успешно прикрываются им. Для отечественных чебурнетчиков понятия недопустимого по всей видимости не существует - стало понятно еще в прошлом году после блокировки всех CDN. Их единственный ограничитель - ресурс ТСПУ, и такие ковровые фильтры как по отпечатку помогают его здорово экономить блокируя кучу трафика почти бесплатно, разгружая более тяжелые нижестоящие модули.
Summary
Заметили, что одновременно с блоками по ja4 ТСПУ начал более эффективно сопротивляться zapret-у?
Я это все к тому, что не следует натягивать сову на глобус (китайские инструменты на суровую российскую реальность) или думать, что firefox или chrome 120 чем-то защищен от блокировок. Сейчас массовый пользователь поменяет fp на лису в своих конфигах, и в следующем обновлении ТСПУ он также отлетит в блок. Лучше думать, как сделать свой сетап уникальным - например не притворяться браузером.
У последней версии по сути тот же сиб блок сейчас? То есть ограничение в xmux решает проблему. Но да, им ничего не стоит полностью банить старые отпечатки после выхода новых. Все равно большинство браузеров уже обновится и ущерб минимален.
fingerprint: randomized в xray?
Я такого не наблюдаю, у меня блокировка по отпечаткам вне зависимости от значения maxConnections.
Есть Win 7 с хромом 109 и выше он на ней не станет, а также скрепные ОС где браузер тоже обновляется не часто.
Проблемы индейцев шерифа не волнуют, выше уже писали что РКН хуже китайского фаервола в этом плане
Я такого не наблюдаю, у меня блокировка по отпечаткам вне зависимости от значения
maxConnections.
У Вас вообще не открываются сайты на этом хостинге через Chrome последней версии? Или fingerprint в utls отстаёт от последней версии Chrome и обновление решит проблему? Или же блокировка по fingerprint chrome + что-то ещё, что здесь пока не упомянуто?
На более старой версии (132.x тестировал) происходит временная блокировка, которая блокирует соединения в том числе и на новой версии Chrome. Поскольку блокировка является триггерной, я не успел проверить, появляется ли блокировка на новой версии Chrome без участия старой версии.
Триггер я не знаю, но это не github.com (конкретно в моём случае).
Без участия старой версии новая версия Chrome не вызывает триггерную блокировку. Заблокированный триггером сайт открывается без проблем на Firefox и curl, но не через новую версию Chrome, как уже говорил в предыдущем посте.
Что это значит?
Если уже сработал триггер (например, через отпечаток Chrome от uTLS или Chrome 132.x), то сайт не открывается на новой версии Chrome (но зато открывается спокойно на Firefox и загружается через curl). Если триггер ещё не сработал, то он открывается на новой версии Chrome и он не вызовёт триггер.
Edit: Chrome 134.x также вызывает блокировку.
С сегодняшнего дня заметил следующее. Использовал цепочку Ru → Fr сервер. Западный сервер не был проплачен на июнь и до человека, который может это сделать, не достучаться пока. И я не использовал VPN вообще. НО с сегодняшнего дня я заметил, что теперь сайт (через который работал VPN по протоколу HTTPUpgrade) отваливается через несколько минут после подключения мобильного интернета (переподключение помогает). Блокируется всё, включая 22 порт. То есть сайт невозможно администрировать. Ping Admin показывает, что всё норм. Если открывать сайт с Теле2, то проблем нет, такой странной блокировки нет. Это что за приколы такие. Оператор Yota.