Для quic нужен свой пэйлоад от гугла (quic initial или его кусок), по другому там не проходит. Потому и блокчек ничего не находит.
--dpi-desync=fake --dpi-desync-repeats=2 --dpi-desync-fake-quic="quic_ietf_google_com_2.bin"
quic_ietf_google_com_2.bin (1,2 КБ)
Проверять так:
curl -svo NUL --http3-only https://rr....
Может понадобиться обновленный курл. Не знаю есть ли в дефолтном виндоусовском поддержка http3.
Что-то провайдер, вернее ркн с настройками играется сильно часто, утром еще блочилось а сейчас уже нет, запущу еще раз проверку…
Благодарю!
Можете запустить _CMD_ADMIN.cmd из папки zapret-winws, вставьте туда свою стратегию, проверьте ютуб ( к стратегии можно еще добавить --dpi-desync-fake-tls=tls_clienthello_www_google_com.bin, файл tls_clienthello_www_google_com.bin должен лежать в той же папке)
Нет, не путаю.
HTTP/3, который использует транспортный протокол QUIC, работает тоже по HTTPS.
Это так себе метод. В консоли как проверить?
А причем тут quic, который по udp и tls 1.3, который по tcp?
Что-то не догоняю вопроса) Это же и есть консоль. Какую вам zapret выдал стратегию?
Проверять работоспособность в консоли как? Открывать браузер и проверять глазами так себе метод.
Так вам не ютуб нужен? А метод проверки из консоли? Ну через curl тогда видимо. Как выше написали
curl -kv -o NUL https://rrбла-бла.googlevideo.com
А для чего, если не секрет?
Ютуб нужен. Для достоверного тестирования работоспособности. Хочу скрипт написать, который будет сразу работоспособную стратегию применять.
curl -kv -o NUL https://rrбла-бла.googlevideo.com не позволяет достоверно определить работоспособность.
Значит, самое достоверное - это таки
))
А в скрипт вы можете просто вставить копирование в .cmd рабочей стратегии из лога блокчека и запуск. Или перебор стратегий, если их несколько.
С чего бы это не позволяет? Разве что -k убрать на всякий случай. Можете ещё -X POST прикрутить, если боитесь ошибок 403. Хотя смысла 0, имхо.
Попробуйте подольше потестировать, Сколько раз наблюдал, видео в браузере не грузится, запросы в network красные, а curl проходит.
Никогда с таким не сталкивался. А тестировал я очень много. Вы точно https:// не забывали указывать в курле? Единственные 2 исключения: ошибки 403 и провайдерские сервера. С 403 понятно, а с провайдерскими серверами проблема не на канале между клиентом и сервером, а между сервером и внешней сетью. Поэтому эта проблема со стороны клиента неразрешима. Только блочить такие сервера.
Конечно указывал.
Ну не знаю. Как правило ТСПУ останавливает на хэндшейке. Если он проходит, то дальше и проблем нет.
Не встречался с ситуациями чтобы в браузере не работал сервер, а в курле работал.
Разве что с самим сервером проблемы.
Один раз curl проходит, через секунду нет, просто висит и таймер тикает
Также есть сервера googlevideo, которые возвращают статус 200, но делают это с задержкой 5-10 секунд, что фактически говорит о том, что GoodbyeDPI на этот сервер не работает должным образом и блокировку не обходит.
Как такие тестировать?
А как этот пэйлоад к блокчеку прикрутить, чтобы он начал его использовать?