Меня сия проблема тоже коснулась, опишу тут свой опыт и выводы. Провайдер скайнет, СПб.
В общем, при просмотре видосов, если смотреть через монитор сети, то видно что почти всё тянется с 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. У меня даже появилась теория, что они ослабили блокировки ютуба и гуглвидео, потому что ТСПУ не справляются с фильтрацией фейков.