Я так понял он должен иметь вид --dpi-desync-fake-tls=0x1603 ? Примерно так?
! - означает дефолтный tls фейк, ^ - ошибочный символ
Кто-нибудь устранял износ серверов Apple конкретно в плане FaceTime с помощью zapret?
Не хочется всю подсеть 17/8 в туннель заправлять
ты научился запускать запрет на ios?
добрый день кто-нибудь смог пробить open VPN Протон tcp с помощью запрета
Посмотри в сторону desync any protocol и cutoff
я уже пытался соединение идёт трафик не идёт соединe разрывается и так по кругу пробовал с помощью tls PQ fake
Кто-нибудь может подтолкнуть в нужном направлении для исправления обхода для сайтов за CDN от Cloudflare? После обновления блокировок от 26 декабря 2025 пришлось искать новые стратегии и ни одна из них не работает без --dup=1 --dup-cutoff=n2. Может быть проблема не в этом, это лишь уточнение. Вот несколько рабочих вариантов:
Спойлер
–new
–filter-tcp=80,443,1024-65535
–ipset=/opt/zapret/ipset/zapret-ip-user.txt
–dpi-desync=fake,fakedsplit
–dup=1
–dup-cutoff=n2
–dpi-desync-split-pos=1,midsld
–dpi-desync-split-seqovl=654
–dpi-desync-fake-tls=!
–dpi-desync-fooling=badseq
–new
–filter-tcp=80,443,1024-65535
–ipset=/opt/zapret/ipset/zapret-ip-user.txt
–dpi-desync=multisplit
–dpi-desync-split-pos=1
–dpi-desync-split-seqovl=654
–dpi-desync-split-seqovl-pattern=/opt/zapret/files/fake/tls_clienthello_max_ru.bin
–dup=1
–dup-cutoff=n2
Проблема в том, что периодически при работе с сайтами за CDN от Cloudflare появляется заглушка Cloudflare “SSL handshake failed Error code 525”. На некоторых сайтах не появляется совсем, на некоторых, например rutracker.org наоборот слишком часто.
Проблема на стороне сайта и к запрету отношения не имеет
к клауду никакого отношения не имеет как и к самим стратегиям - они не поменялись никак
=мудачьё навесило детект фуллингов => dup=1 помогает. ну или сами фулинги на другие сменить. ts пока не палят
А на основе hostfakesplit пробовали стратегии? Фейк в середине не так тщательно проверяется
Да, результат примерно тот же для Cloudflare, но с другими CDN может вообще не работать.
Половина сайтов с ним не пашет, ошибка ssl
Сегодня перестал работать у меня ютуб на ростелекоме, Москва. Пробовал все стратегии, результат один. На рабочем интернете все ок. У всех так или что-то у меня?
Тоже отвалился ютуб 2 недели назад. После некоторых тестов я понял, что они догадались поставить ТСПУ в разрыв между провайдерскими GGC и внешним интернетом. Теперь они не могут нормально закэшировать видео из внешней сети, чтобы уже раздавать его абонентам. Так что можно сказать, что сервера гугла действительно деградировали, но только не по вине самого гугла.
Тут либо вылавливать все IP проблемных GGC и блочить их у себя локально через hosts, чтобы гугл выдавал вам другие GGC, либо смотреть ютуб через прокси. Мне лично стало проще скачать расширение в браузер и пускать ютуб через него, а всё остальное пробивать запретом как и раньше.
Я смотрю ютуб чаще через телевизор, так что расширение для ютуба несколько не вариант 
Да и сейчас работает связка (zapret+v2ray+unbound) через рабочий интернет, пока что хватает. Но хотелось бы, конечно, найти подстраховку.
Все это какие?
Есть рабочая стратегия на Винде. Копирую её досконально в openwrt и нифига. Это вообще нормальная ситуация? ttl пробовал добавлять ниче не меняется.
чуть не по теме, но всёже… ты вроде ковырял хуавей тот что с вайваем е8372
можешь из своего опыта подтвердить или опровергнуть что именно он badsum сквозь себя не пропускает? и может знаешь как это вкл\выкл?
есть E8372 и смежный E3372s
и первый лажает если в стратегии фуллинги с badsum а второй норм
при всех прочих равных
Все - это стандартные, которые идут с 1.8.6 и 1.9.2. Есть что-то более актуальное?