Приветствую всех. Ну сразу скажу, что уже неделю мониторю форум, но такую проблему, как у меня, не встретил.
Так вот в чем дело. GoodbyeDPI устанавливаю как сервис. Предпоследний раз в конце ноября у меня были проблемы, и то с зависанием в начале, поставил вот такой конфиг:

До 7 марта все работало хорошо и вот начиная с этого времени, перепробовал 100500 конфиг-вариантов, но никак не хочет работать. какой то конфиг может сработать, например кое как пару видео смотреть, но потом все, потухает. Все другие сайты нормально открывается.

Посоветовали через GoodCheck_v1.3.07 (специально для ютуба) , запустил с максимально возможными вариантами, около 30-40 мин работал и вот лог:
https://justpaste.it/ba6io

С конца пробовал минимум 10 вариантов, но все мимо.

Помогите разобраться, пожалуйста в чем дело?
ОС - windows 10
провайдер - местные барыги, не знаю у кого покупают трафик.

И еще через http tracer очень много отказов:

954×345 144 KB

заблокированы все пиринговые сервера (на которые направлена провайдерская маршрутизация), при этом доступны иностранные и местные от других провайдеров.
либо это проделка провайдера и там блок по ip:port (в таком случае анти-dpi не поможет)
либо поставлено доп.тспу, тогда можно пробить через zapret
либо пробовать играться с блокировкой недоступных ggc через hosts

я бы начал с тестирования стратегий для запрета. только убери все остальные домены (кроме Site to check: https://rr1---sn-n8v7znlk.googlevideo.com (Your ISPs Google Cache Server) ), зачем все то тестировать

Можно подробнее? что делать? не очень понял.

Вот прогонял чекером DNS от zapret:

*** - это домен нашего городского провайдера. Только не верится, что такие гиганты, как ростелеком , билайн мегафон мтс не могут блокировать, а мой какой то noname провайдер решил тотально все блокировать.

в приложенном файле протестирован рутрекер, а не указанный мной домен

Вот лог с этим доменом:

только не дождался до конца, больше часа работал, остановил. Если полюбому надо до конца, то завтра пораньше запущу.

нужно переделывать
адрес домена указывается без https
в тестировании выбирается tls1.3 остальное : no

Переделал, как сказали и ждал до конца. вот полный лог:

Сделай не quick, а standard. А лучше сразу force. Блокчек не может найти стратегии в быстром режиме.

Вот сделал в режиме force:

увы
похоже на точечный блок либо отсутствие настройки со стороны провайдера (такое уже было, не ты первый)
можешь попробовать запустить _CMD_ADMIN.cmd из папки с запретом в нем ввести:

winws --wf-tcp=443 --filter-tcp=443 --hostlist-domains=googlevideo.com --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls=0x16030102920100028e03035672ea15594162966e8a144297c497ddace5d546af7a4a0414a946fa52023cf720b0220c217abb1db321abbf01985cf3d07c61367c2ba5eff307b0f6f042448077 --dpi-desync-fooling=datanoack
и попробовать открыть этот ggc из браузера:
https://rr1---sn-n8v7znlk.googlevideo.com

при этом все остальные anti-dpi решения должны быть выключены

если не откроется, то можешь поискать на форуме как блокировать недоступные ggc, должны быть инструкции
очевидного и быстрого решения тут нет

Неа, безуспешно

При соединении с rr1---sn-n8v7znlk.googlevideo.com произошла ошибка. PR_CONNECT_RESET_ERROR

Код ошибки: PR_CONNECT_RESET_ERROR

а поможет, если настрою в системе DNS Over HTTPS ?

Если включен какой то антизапрет, то даже TOP не показывает ютуб. Приходится остановить службу, потом перезагрузть несколько раз, чтоб заработал.

сомневаюсь. проблемы не пересекаются (doh можно в браузере включить, это делается одним кликом)
возможно, тут и есть стратегии, но это надо лично смотреть, а не через форум
дальше можно пробовать либо блокировать ggc, либо использовать vpn, например, тот же warp

либо можешь поспрашивать других посетителей форума)

Нет, VPN не хочу, подожду лучше, может кто то что то другое предложит? Не думаю, что нет других вариантов
блокировать ggc - знать бы еще что это и как делать и именно что блокировать то… ? можно было пробовать

+тема к изучению (ну и вцелом поиск по форуму)

но все это нужно делать с пониманием, что именно ты делаешь.
правда с учетом того, что пиринговых серверов порядка 200 штук, я бы оставил этот вариант напоследок (но именно как поведет себя сеть ggc при блокировании я не знаю, может выдаст на определенном этапе пул ggc из франкфурта, может нет)

Хорошо было бы мне вообще понять физику/химию всего этого. Как вообще провайдеры блокруют через DPI и каким образом GDPI обходят эту защиту?
ну и как собрать эти ggc ссылки? я как понял, они у всех разные.

Там ссылка ведет в никуда, если нажать там , по переходит сюда:
https://ntc.party/t/%D0%BD%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82-%D0%BE%D0%B1%D1%85%D0%BE%D0%B4-%D0%B7%D0%B0%D0%BC%D0%B5%D0%B4%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D1%8E%D1%82%D1%83%D0%B1%D0%B0/8404/15

я несколько обижен на админа этого форума, поэтому нет желания писать подробную инструкцию, извини.
ggc берутся из консоли браузера во время попытки просмотра видео.
удачи)

хммм
я еще раз пересмотрел твои логи блокчека, они сделаны были неправильно

• checking already running DPI bypass processes
  !!! WARNING. some dpi bypass processes already running !!!
  !!! WARNING. blockcheck requires all DPI bypass methods disabled !!!
  !!! WARNING. pls stop all dpi bypass instances that may interfere with blockcheck !!!

на момент выполнения тестирования в системе запущена anti-dpi программа или служба, соответственно тестирование не выполнялось корректно

Никак. Я пробовал блокировать ggc своего прова и магистрали. Ютуб продолжает долбиться на них. Если бы можно было без смены ip заставить ютуб использовать непровайдеровские ggc, то у меня бы лично ютуб работал без проблем, т.к. чужие ggc прекрасно обходятся. А так лишь форс quic в хроме, приправленный молитвой, чтобы подключилось с первого раза, а не с десятого.

Соглашусь. Несколько месяцев назад, в качестве эксперимента, пытался блочить проблемные GGC. По итогу пришёл к выводу, что локальная блокировка трафика не помогает. API ютуба продолжает отдавать те GGC, которые “привязаны” к подсети/провайдеру с IP которого приходит запрос. Похоже, нет механизма обратной связи между приложением/браузером и API выдающим адреса GGC, типа если видео не грузится браузер сообщает API и оно отдаёт другие GGC в этой сессии.

тут могут быть варианты, например, мой случай:
открываем видео и смотрим videoplayback , в строчке mn= видим следующее mn=sn-8ph2xajvh-3hfl,sn-n8v7znzl
в данном случае при блокировке пула sn-8ph2xajvh-3hfl видео будет грузиться с пиринговых ggc n-n8v7znzl

у автора вообще нестандартный случай, т.к у его провайдера нет собственного пула.

также пока censor tracker не поломался, можно было через него пустить проблемные ggc, в таком случае они полностью убирались из запроса. возможно, также можно сделать с другим прокси.

вариант через quic можно попробовать , да. автор прогони еще блокчек по quic.
кстати как зафорсить хром на quic я недавно писал тут:

правда в виду отсутствия собственного пула это не совсем для него актуально
в любом случае, ему нужно все тесты переделывать

По IP определяется провайдерская зона https://redirector.googlevideo.com/report_mapping?di=no
Но можно ли без смены IP зафорсить другую зону, мне неизвестно.

да , забыл отключить goodbyedpi.
Вот новый лог:

увы, можешь попробовать еще quic проверить отдельно без tls1.3 как выше порекомендовали
я посмотрю в свободное время, можно ли отдельно пропихнуть в warp конкретный ggc
из этой темы:

тогда было бы достаточно легко вопрос решить
ну либо ты можешь сам проверить.

кстати , если к тому, что я в прошлый раз просил проверить добавить wssize тоже не будет открываться ссылка?
только при условии опять же, что anti-dpi выключен и после запуска нужно перезапустить браузер
winws --wf-tcp=443 --filter-tcp=443 --hostlist-domains=googlevideo.com --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls=0x16030102920100028e03035672ea15594162966e8a144297c497ddace5d546af7a4a0414a946fa52023cf720b0220c217abb1db321abbf01985cf3d07c61367c2ba5eff307b0f6f042448077 --dpi-desync-fooling=datanoack --wssize 1:6

Вот тест только quic:

Пробовал, но нет толка:
Скрин:
https://i.ibb.co/WvD18YpY/image.jpg

This post was flagged by the community and is temporarily hidden.

Как не странно, сегодня все хорошо работает. Ничего не делал, только GDPI запустил со старым конфигом. Не пойму в чем дело

скорее всего провайдер исправил маршрутизацию.
к какому ggc теперь обращается ютуб?

А у Вас случайно не Белый IP адрес. Фиксированный

У меня были такие же проблемы Как у вас. Пока. Не перешёл. На динамический, iP адрес

Может ошибаетесь немного по терминам?
Не белый (т. е. серый IP-адрес - когда провайдер выдал тебе локальный у себя IP-адрес, а выходишь уже в интернет с другого (уже внешнего) IP. Тогда с внешнего IP, кроме тебя могут сидеть ещё несколько человек. Поэтому если у тебя серый IP, то очень велика вероятность, что порты во внешний мир пробросить не получится.

Белый - когда провайдер выдал тебе один IP, и ты же с этого IP выходишь в интернет. За этим IP сидит только твой роутер. Он может быть динамическим (провайдер не закинул тебя за CGNAT, но выдаёт любой свободный в его пуле внешний IP) и статическим (также не сидишь за CGNAT, но покупаешь у провайдера услугу, и за определённую плату он фиксирует за тобой определённый IP из его пула)

Таблица подсетей IPv4, стандарт RFC 5735
К сожалению, не все провайдеры (в частности операторы мобильной связи) следуют стандартам RFC 5735. Но “на пальцах” думаю будет немного понятно