Да, заблокируют все массовое альтернативное, если только не начнется “разрядка отношений” с Западом.
штоу
Конкуре́нция — борьба между экономическими субъектами за максимально эффективное использование факторов производства, при единых правилах для всех её участников.
У кого проблемы попробуйте через any country параметр -1
Непременно заблокируют, только повода дождутся. Таким поводом, как мне кажется, станет закон о блогерах (который, по моему, вступает в действие с 1 ноября). Ютуб его исполнять конечно же не будет (думаю, что Телеграм тоже). Тут-то и появится повод для блокировки.
Но интересно все же, что ФАС ответит…
Возможно, тем, кому прописывал -1, мне не жаловались на остановки видео.
А я что конкретно вам писал? Вам не поможет кому то поможет. Какие проблемы?
Вот это и непонятно. Сами пиратят, а другим не дают. Причём пиратят фильмы, а у пользователей банят банальные перезаливы social конента. Маразм и они на это советуют переходить?
Кто-нибудь знает в чем может быть проблема при использовании xtls+reality именно для доступа к Youtube
Все заблокированные сайты моменталньо открываются.
Но при попытке зайти на ютуб часто возникает проблема- страница очень долго грузится иногда же наоброот нормально.
А куда прописывать?
-может для TPWS есть готовые параметры?
постоянные ошибки:
GET https://rr3---sn-gvnuxaxjvh-c356.googlevideo.com/generate_204 net::ERR_TIMED_OUT
POST https://rr7---sn-n8v7znlr.googlevideo.com/videoplayback?expire=1727033.....................0&fallback_count=1&rn=8 net::ERR_TIMED_OUT
base.js:1695 POST https://www.youtube.com/api/stats/qoe?......................Tk9wEAU net::ERR_BLOCKED_BY_CLIENT
| Hr | @ | base.js:1695 | |
|---|---|---|---|
| (anonymous) | @ | base.js:1702 | |
| aWa | @ | base.js:5536 | |
| (anonymous) | @ | base.js:5561 | |
| (anonymous) | @ | base.js:8390 | |
| hWa | @ | base.js:5560 | |
| (anonymous) | @ | base.js:11194 | |
| (anonymous) | @ | base.js:5565 | |
| (anonymous) | @ | base.js:1659 |
Я избавился от этой проблемы так. Пустил через vless вот эти домены:
“youtube.com”,
“googlevideo.com”,
“ytimg.com”,
“youtu.be”,
“ggpht.com”,
“googleapis.com”,
“googleusercontent.com”,
“nhacmp3youtube.com”,
“gstatic.com”,
“ytimg.l.google.com”,
“play.google.com”
и дополнительно udp-протокол на вот эти IP тоже через vless.
“8.34.208.0/20”, “8.35.192.0/20”, “23.236.48.0/20”, “23.251.128.0/19”, “34.0.0.0/15”, “34.2.0.0/16”, “34.3.0.0/23”, “34.3.3.0/24”, “34.3.4.0/24”, “34.3.8.0/21”, “34.3.16.0/20”, “34.3.32.0/19”, “34.3.64.0/18”, “34.4.0.0/14”, “34.8.0.0/13”, “34.16.0.0/12”, “34.32.0.0/11”, “34.64.0.0/10”, “34.128.0.0/10”, “35.184.0.0/13”, “35.192.0.0/14”, “35.196.0.0/15”, “35.198.0.0/16”, “35.199.0.0/17”, “35.199.128.0/18”, “35.200.0.0/13”, “35.208.0.0/12”, “35.224.0.0/12”, “35.240.0.0/13”, “57.140.192.0/18”, “64.15.112.0/20”, “64.233.160.0/19”, “66.22.228.0/23”, “66.102.0.0/20”, “66.249.64.0/19”, “70.32.128.0/19”, “72.14.192.0/18”, “74.125.0.0/16”, “104.154.0.0/15”, “104.196.0.0/14”, “104.237.160.0/19”, “107.167.160.0/19”, “107.178.192.0/18”, “108.59.80.0/20”, “108.170.192.0/18”, “108.177.0.0/17”, “130.211.0.0/16”, “136.22.160.0/20”, “136.22.176.0/21”, “136.22.184.0/23”, “136.22.186.0/24”, “142.250.0.0/15”, “146.148.0.0/17”, “152.65.208.0/22”, “152.65.214.0/23”, “152.65.218.0/23”, “152.65.222.0/23”, “152.65.224.0/19”, “162.120.128.0/17”, “162.216.148.0/22”, “162.222.176.0/21”, “172.110.32.0/21”, “172.217.0.0/16”, “172.253.0.0/16”, “173.194.0.0/16”, “173.255.112.0/20”, “192.158.28.0/22”, “192.178.0.0/15”, “193.186.4.0/24”, “199.36.154.0/23”, “199.36.156.0/24”, “199.192.112.0/22”, “199.223.232.0/21”, “207.223.160.0/20”, “208.65.152.0/22”, “208.68.108.0/22”, “208.81.188.0/22”, “208.117.224.0/19”, “209.85.128.0/17”, “216.58.192.0/19”, “216.73.80.0/20”, “216.239.32.0/19”
В противном случае tcp шло правильно, а udp шло напрямую и получалась такая же фигня, что у вас.
Как вариант, можно попробовать отключить udp на 443 порт вообще в роутере, но не уверен, что поможет
udp на 443 порт вообще в роутере
Помогает, 100%
Полный аналог отключения QUIC в браузере.
Однако это не единственная возможная причина задержек. Может быть связано с тем что например боход по ipv4 работает, а по ipv6 нет. Или наоборот.
25 Sep 2024
Йота Новосибирск
QUIC/UDP:
Данные напрямую не учавствующие в просмотре в браузере, но могут быть полезны при скачивании. Считаются пессимистичными, браузеру удаётся работать лучше, благодаря различным технологиям, вроде реконнекта и параллельной загрузки.
yt-dlp+curl+quiche/openssl теперь avg 100…120 кбайт/с (current плавает с 80…350) [раньше было avg 256 кбайт/с, а ещё раньше unlimited, но не выше 2xrealtime bitrate из-за ограничения гугла, я это учёл, выбрав высокое качество, чтобы был больше битрейт]
Через несколько десятков мб скорость уходит в 0.
curl+openssl не делает реконнект
curl+quiche иногда делает [раньше делал гораздо чаще, а в начале заварушки разрывов вообще не было]
В начале тестов приходилось несколько раз перезапускать скачивание, т.к. оно не начиналось, скорость висела на 0 [раньше перезапускать приходилось максимум 1-2 раза в самом начале]. Потом прорезалось, но нестабильно.
Скачивается с NSK и MSK GGC.
Статистика браузера показывает скорость 3000-4000…5000…6000 кбит/с
720p avc играет, один раз был затык (возможно выбрался другой сервер)
1080p avc иногда тормозит (2500), иногда нет (6000), зависит от сервера, разные куски с разных серверов качаются
173.194.179.217 Google MSK (ping), обратный hostname svo
85.26.174.204 MegaFon NSK (ping)
на втором просмотре 720p/1080p стало тормозить, нестабильно.
В общем, стало хуже.
TCP:
yt-dlp+curl скачивает файл размером 512 кбайт…1024 кбайт и скорость в 0.
Статистика браузера показывает скорость около 500 кбит/с
Играет 144p avc
360p avc тормозит
У avc больше битрейт, чем у vp9
Исследование GGC:
zapret обход на линуксе по прежнему исправляет работу по TCP, настройки не менял. на мобильном интернете им нет нужды менять правила dpi.
малопопулярное в России французское видео первый раз грузится из 74.125.111.137 Google (минимальный ping DE, возможно FR, NL, обратный hostname у IP fra16)
а потом при втором просмотре 85.26.174.204 MegaFon NSK (ping)
это значит новосибирские мегафоновцы и йотовцы его не смотрели
у этого видео максимальное качество 480p
локальный GGC кэширует 480p и 360p (два ближайших разрешения)
при запросе 240p во втором просмотре опять идёт обращение к 74.125.111.137
третий просмотр 240p опять местный 85.26.174.204
значит GGC мегафона ещё работает.
Я не совсем понял что вы хотите прописать. Если конфиг то он прописывается в файл preset Russia
А кто-то заставил работать Waujito/youtubeUnblock (v1.0.0-rc1)?
Вопрос именно в конфиге - пока никакие варианты настроек не помогли.
Вроде новая версия должна быть - но вдруг и эту можно завести.
А может ли быть такое, что обратный hostname fra16, а сервер в Германии? Вот этот IP 173.194.188.134 где?
Ping RTT (avg, мс):
Germany, Frankfurt Powered by [4VPS.su] 0,76
Germany, Nuremberg 2,70
France, Strasbourg, south Powered by [RealHosters] 3,38
Germany, Falkenstein 4,79
Или это просто у ping-admin.com инфраструктура в Германии лучше?
Подключаюсь из Нидерландов. Ролик очень редкий, приватный. Почти нет просмотров. Возможно, через французский VPN я его и заливал когда-то, а может через WARP.
Upd: возможно fra потому что я смотрел его после залива в invidious.fdn.fr. Но почему же ping не совпадает?
Frankfurt — немецкий город.
Понял. fra это Франкфурт, а не Франция. 
Однако, интересно как он туда попал. Может, правообладатель его оттуда посмотрел (был страйк) или немногочисленные зрители (выкладывал embed на форум).
Зашёл с японского VPN. GCC выбрался Сингапур.
142.251.88.39
sin10s38-in-f7.1e100.net
Это не так уж и близко к Японии. Но ping между Сингапуром и Токио порядка 70 мс. Это гораздо меньше, чем до Европы и даже США.
А вообще там в Азии маршруты могут ходить довольно дико, далеко не всегда оптимально. Ещё и всякие задержки местные, наверняка.
Например, расстояние между Сингапуром и Джакартой (Индонезия) около 1000 км - пинг 256 мс.
Расстояние между Сингапуром и Токио 5300 км - пинг 70 мс.
Вот, к примеру. Новосибирск с Японией (Proton) соединяется транзитом через США, судя по tracert и ping (380 мс).
Пинг из Японии до США около 100, до Европы около 250.
Но если запросить 1tv.ru (178.248.233.188) из Японии, то пинг вообще как местный. В промежутке некто 63.222.51.182.
Ну, и там, конечно представлены google, cloudflare рядом.
Не знаю, как известно, поддержка когерентности кэша это одна из двух сложных задач: