VLESS+Reality на VPS. Про то какой VPS выбирать можете почитать здесь:
Меня сия проблема тоже коснулась, опишу тут свой опыт и выводы. Провайдер скайнет, СПб.
В общем, при просмотре видосов, если смотреть через монитор сети, то видно что почти всё тянется с 2-х видов адресов, скайнетовских ---sn-n3toxu-axql и каких-то ещё из СПб ---sn-axq7sn7l. Другие адреса проскакивают, но очень редко.
Если видос популярный, он тянется со скайнетовских GGC ---sn-n3toxu-axql, без задержек при перемотке и т.п. В процессе выяснилось, что эти серваки вообще до ТСПУ расположены.
Однако, если видос непопулярный, то скайнетовские GGC начинают таймаутиться, постоянно валятся NS_BINDING_ABORTED и т.д. Что довольно странно. Именно таймауты в итоге и приводят к жутким паузам при перемотке. А реальный трафик вообще идет с серверов ---sn-axq7sn7l, расположенных за ТСПУ.
Поначалу думал, что может фейки вызывают ошибки, т.к. доходят до сервера. Но на практике даже без gdpi/zapret ситуация не меняется и никакие варианты настроек ничего не дают.
Наигравшись в браузере, я пошел проверять как дела обстоят в yt-dlp. Если запустить с флагом --get-url, то видно, что yt-dlp обращается к youtube.com, а тот возвращает скайнетовские ---sn-n3toxu-axql. При попытке скачать популярное видео проблем нет. При попытке скачать непопулярное видео наблюдается интересная ситуация: пара мегабайт скачивается, потом 5 секунд пауза, пара мегабайт скачивается, снова пауза, и так по кругу. Если прервать закачку на 50%, удалить то, что успелось закачаться и начать снова - то эти 50% закачаются за секунды с максимальной скоростью. Т.е. они закэшировались на сервере и отдаются оттуда без проблем. А начиная с 50% закачка опять начнет ползти как черепаха.
Исходя из всего этого можно сделать вывод, что проблем на канале между клиентом и GGC скайнета нет - если видео уже лежит там в кэше, то оно отдается мгновенно. Реальная проблема между GGC провайдера и внешней сетью. То ли там искуственно скорость режут, то ли тупо канал не выдерживает нагрузку, т.к. из-за ТСПУ, отрезающего доступ к внешним GGC, все запросы идут на внутрипровайдерные сервера в основном, то ли ещё что. Ну и как следствие, манипуляции с пакетами тут без толку.
Ещё интересный момент. Недавно, с 30 августа по примерно 3 сентября, на скайнете ютуб вообще почти не работал - ни gdpi, ни zapret практически не помогали. Связано это было как раз с тем, что сервера ---sn-axq7sn7l не работали вообще. То есть ситуация: сервера до ТСПУ лагают безбожно, а ближайшие за ТСПУ не пашут. В итоге ютуб тупо встал.
Какие тут есть решения? Ну, в браузере всё просто: заблочить провайдерские GGC в том же uBlock:
Спойлер
www.youtube.com rr1---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr2---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr3---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr4---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr5---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr6---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr7---sn-n3toxu-axql.googlevideo.com * block
www.youtube.com rr8---sn-n3toxu-axql.googlevideo.com * block
В результате задержки полностью пропадают, т.к. видосы тянутся с внешних GGC, которые сейчас работают норм и достать до них можно без проблем через gdpi/zapret. Правда, неизвестно, когда они вновь отключатся - раз уже был прецедент.
А вот с yt-dlp ситуация сложнее. Если заблочить эти адреса в hosts, то yt-dlp тупо вываливается с ошибкой. Там вроде как есть флаги типа --xff и --geo-verification-proxy, но они не работают (из-за обнов ютуба?), что легко проверить через --get-url. Хоть ты тресни, но присылает ссылку на скайнетовский GGC. Единственный вариант - полностью пустить трафик через прокси флагом --proxy.
Однако, есть ещё один любопытный момент. При использовании yt-dlp в связке с медиаплеерами, типа mpv или mpc-hc, yt-dlp используется только для получения url-адресов. А сами данные качаются через ffmpeg/lav которые прокси не используют. То есть вы можете пустить yt-dlp через какой-нибудь бесплатный, медленный или даже небезопасный прокси (т.к. вы, фактически, никаких данных кроме url-адреса видоса не отправляете), а сам поток будет тянуться плеером напрямую, через gdpi/zapret, не используя прокси.
А ещё в качестве прокси можно использовать Тор Браузер (socks5h://127.0.0.1:9150). Сам он довольно медленный, но так как мы через него только url-адрес получаем, то пофиг. + Можно самому нужную страну для GGC настроить, вписав в torrc что-нибудь типа ExitNodes {RU} StrictNodes 1.
В чем смысл всей этой дичи? Я хз 
PS: кому интересно, для googlevideo.com на скайнете сейчас работает вариант -e 1 --reverse-frag для gdpi и --dpi-desync=disorder2 для zapret. Даже фейки не нужны. Причем достаёт даже до ростелекомовских GGC. У меня даже появилась теория, что они ослабили блокировки ютуба и гуглвидео, потому что ТСПУ не справляются с фильтрацией фейков.
Какие тут есть решения? Ну, в браузере всё просто: заблочить провайдерские GGC в том же uBlock:
Я попробовал это, но у меня совсем перестали работать все видео. Обычно, если это не популярное видео, то мне нужно перезагрузить страницу несколько раз, чтобы загрузка началась, и сама загрузка медленная, т.е. когда доходит до конца то будет пауза на некоторое время, но перемотка на незагрженные фрагменты идет с большой задержкой. Я менял DNS на cloudflare, google, opendns, использовал /flushdns и перезапуск браузера естественно, но вся та же фигня.
Ну, у разных провайдеров ситуация разная и то, что помогло мне - может не помочь вам.
Короче, я сейчас распишу всю свою последовательность действий, возможно кому пригодится.
- Ставим в браузере режим строгого https, настраиваем doh, отключаем kyber и quic. Делаем ipconfig /flushdns На этом этапе в etc/hosts и в блокировщике рекламы у вас не должны быть заблочены никакие гуглвидео-серваки. Также убедитесь, что выключены всякие браузерные ВПН/ускорители/цензортрекеры.
- Открываем (с gdpi и без) популярное русскоязычное видео, нажимаем F12, раздел сеть/network, смотрим запросы xhr/fetch адресованные к
googlevideo.com/videoplayback, выписываем адреса себе в блокнот. Повторяем с несколькими видео. - Проделываем (с gdpi и без) тоже самое, но с непопулярным англоязычным видео до 5к просмотров.
- Теперь отключаем gdpi, открываем командную строку и проверяем доступность серверов из списка командой наподобие такой:
curl -sv -o NUL https://rr1---sn-n3toxu-axql.googlevideo.com
Обратите внимание, подключение должно быть по https. Если у вас пишет что-то в духе schannel: disabled, то вам надо обновить curl. Я с такой проблемой столкнулся на ltsc винде с отключенными обновлениями. Ещё есть опасность, что будет редирект, так что смотрите чтобы сертификат был от googlevideo. - На предыдущем шаге выписываем, какие сервера доступны без обхода (они скорее всего принадлежат вашей сети или типа того) и какие сервера таймаутятся на этапе server hello.
- Запускаем gdpi и проверяем все сервера снова. Важно, чтобы те сервера, что были доступны без обхода не начали возвращать ошибки типа SSL что-то-там. А те, что таймаутились теперь должны отвечать. Настраиваете стратегию gdpi при необходимости, пока не найдем рабочую. На моем провайдере было достаточно
goodbyedpi.exe -e 1 --reverse-frag - Теперь проверяем эти сервера на https://www.nslookup.io/ С теми серверами, которые не находятся в вашем городе, больше делать ничего не надо.
- Теперь, с включенным gdpi, находим малопопулярное видео и вбиваем его в yt-dlp с флагом --get-url. Вам должно подсунуть ближайшие GGC. Запоминаем какие. Попробуйте несколько видосов.
- Теперь, пробуем скачать видео через yt-dlp. Важно брать новые видео, которое вы не смотрели до этого, т.к. просмотренные могли закэшироваться на провайдерских GGC. Оцениваем скорость. Если видите, что происходит нечто аномальное, типа того, о чем я писал в прошлом посте, то возможно вам мой метод поможет. В противном случае - хз.
- Допустим, после предыдущих тестов, у вас есть 2 группы серверов из вашего города. Одна принадлежит вашему провайдеру, вторая кому-то ещё (соседнему провайдеру, например). Пробуем сначала заблочить свои внутрипровайдерские GGC.
- Определяем диапозон адресов для блокировки командой ping, по аналогии:
ping rr1---sn-n3toxu-axql.googlevideo.com
ping rr2---sn-n3toxu-axql.googlevideo.com
ping rr3---sn-n3toxu-axql.googlevideo.com
и т.д. пока не начнёт возвращать ошибки. - Теперь пробуем их заблочить. Я рекомендую через uBlock/uMatrix, т.к. etc/hosts вроде игнорится при включенном doh.
- На примере uBlock. Идем в настройки, раздел “мои фильтры” и блочим вот таким образом:
||rr1---sn-n3toxu-axql.googlevideo.com
||rr2---sn-n3toxu-axql.googlevideo.com
Нажимаем применить изменения. - Обновляем ютуб через ctrl+F5 и тестим (с включенным gdpi, естественно).
- Если нет результата или ситуация только ухудшилась - разблокируем заблоченные адреса и возвращаемся к пункту 11. Повторяем шаги для другой группы адресов из вашего города - возможно к проблемам приводит она. Т.е. например, задержки могут вызывать не GGC вашего провайдера, а GGC провайдера по соседству.
А куда пропала тема про скайнет? Там нашли способ убрать эти задержки в 3-5 секунд именно на этом провайдере?
Я как понимаю был откат сайта по какой-то причине, потому что мой аккаунт тоже удалился, который я создавал за день до него
Нашли, но не там. И не тот.
Тут посмотрите, выше и ниже.
74.125.110.218 пинг 13 - отказ
74.125.110.167 пинг 30 - грузит
173.194.181.162 пинг 13 - отказ
173.194.187.200 пинг 54 - грузит
И точно так-же, для остальных.
Если пингуется хорошо - встаёт штыком и отказывается работать.
Через tracert.
Всё, что пропадает, идёт в
svo*s*-in-f*.1e100.net
А удачные в
arn*s*-in-f*.1e100.net
bud*s*-in-f*.1e100.net
fra*s*-in-f*.1e100.net
В проге на android данный баг фиксится настройками в самом приложении без всяких блокировок ip ggc.
Использую ByeDPI. Он создаёт VPN сервер прямо в телефоне и сразу же подключается к нему, видимо, чтобы получить доступ к пакетам, иначе в Android нельзя.
Была такая же проблема. Некоторые видео начинали воспроизводиться после паузы, а некоторые не воспроизводились совсем, как в приложении youtube, так и на сайте.
Нашёл статью на Хабре с правильными настройками. Вот её адрес, но нужно заходить через VPN, потому что Хабр выпилил её по требованию РКН Хабр (habr.com)
Поменял настройки, Youtube заработал отлично. Проверял в приложении, на сайте через мобилу, раздал на комп через Wi-Fi, проверил у трёх разных провайдеров. Всё работает идеально, никакой задержки, все видео воспроизводятся и на телефоне, и на компе.
Есть нюанс. Чтобы работал Instagram, нужно возвращать настройки на дефолтные.
ValdikSS писал, что программа бессильна, потому что РКН банит какие-то ip, а не фильтрует пакеты. Похоже, что это не так. Похоже, что можно как-то подшаманить обход DPI, чтобы Youtube работал нормально.
Можно подшаманить, например используя DoH, а не DNS провайдера. Power Tunnel Android такую возможность имеет, не знаю имеет ли ByeDPI
Это всё равно разрушает теорию о том, что РКН банит ip ggc
Я нигде и не сказал, что ТСПУ банят какие-то GGC по IP - потому что этого нет. Я про остальные нельзясайты говорил.
У меня при помощи GoodbyeDPI при любых настройках бесконечная загрузка видео. Причем через curl видно, что GoodbyeDPI работает: скорость неограниченная, но на деле видео грузить не хочет.
Иногда помогает перезагрузить роутер, чтобы IP сменился. Меняется маршрут подключения к googlevideo.com и ютуб использует другие GGC-сервера, которые работают. Через несколько дней провайдер меняет IP, и если снова попадется “плохой”, снова приходится искать “правильный”, перезагружая роутер. Проще через прокси ютуб пропустить, что я и делаю.
На моём провайдере с GoodbyeDPI помогает несколько раз обновить страницу с видео. После 2-7 обновлений видео запускается.
У меня это не помогает, если IP плохой.
[quote=“blanche.hermine, post:96, topic:8395”]Проще через прокси ютуб пропустить, что я и делаю.
[/quote]
Ага, а потом ютуб тебе пишет - Зарегистрирован подозрительный трафик, исходящий из вашей сети. Докажи, что ты не бот )
Увы, но даже так не работает.
Даже через ByeDPI есть шанс, что отправит на московские AS15169. И опять начинается рулетка, сидишь, перезагружаешь страницу пока не выпадет европа для подключения.
Вот донести бы до Гугла, чтобы он эти серверы мне никогда не предлагал и жизнь пойдёт.
Где я только не пытался блокировать сервера, и в хосте, и в хроме, и расширениями.
Сейчас проверил схему. Костыль, конечно, но работает. Если очень хочется посмотреть Youtube, то поможет.
Ставим на Android ByeDPI, применяем настройки из этой статьи Хабр (habr.com), подключаем мобилу к роутеру по Wi-Fi, раздаём на комп по USB.
Всё работает.
По всей видимости в ByeDPI есть какой-то то ли баг, то ли особенность. В какой-то момент он начинает работать как бы “на половину” или вообще отваливается, хотя соединение VPN при этом установлено. Нужно зайти в приложение, нажать Disconnect, дождаться, когда отвалится VPN соединение, потом опять нажать Connect.
Иногда нужно сделать так пару раз или даже перезапустить приложение, а в редких случаях сбросить настройки на дефолтные, потом опять поставить “правильные”.
Может быть, из-за этого не получилось. Потому что по этой моей схеме у всех моих знакомых в разных регионах всё работает отлично.
Моск область если кто искал, провайдер RNC - (Региональные Сети)
Заблочить надо эти хосты:
https://rr2---sn-4pvgq-n8vs.googlevideo.com
https://rr5---sn-4pvgq-n8vs.googlevideo.com
https://rr4---sn-4pvgq-n8v6.googlevideo.com
https://rr1---sn-4pvgq-n8v6.googlevideo.com
https://rr9---sn-4pvgq-n8v6.googlevideo.com
https://rr10---sn-n8v7znze.googlevideo.com
Без этого действия задержка 6-10 секунд, сейчас норм, в Network(Хром) оранжевым вылетает rr3, но без задержек запускает. А вот перечисленные красным с задержкой