китайцы вообще для оптимизации, если сами что-то рожают, отклоняются от стандартов, поэтому можете ожидать, что угодно
видел их оборудование, которое с частью оборудования по 100-1000BASE линк толком не могли поднять
HDMI порты без питания
вероятно и с ip у них может упрощено до минимума, чтобы работало только в идеальных условиях
мой совет на будущее, берите просто хороший ТВ, а смарт к нему докупайте в виде Андроид (кому и яблоко) ТВ приставки, только опять же не лютый китай, а нормальные, я для себя выделил Mi Box (да, Китай, но качественный), родные от Google и т.п.
либо (я так понял ОС linux) ищите способ зайти как-то в его консоль (как это по нашему) и поставить запрет прям на телек )
Ну а смысл у некоторых людей и на lg и на самсунгах обходы не работают
я имею ввиду просто хороший ТВ (матрица, звук, но без смарт)… хотя не уверен, есть ли сейчас такие
но даже если у вас со смарт, никто не запрещает добавить ТВ box и пользоваться им, вместо встроенного
хотя, даже у родной гугл приставки я нашел косяк (видимо разные бригады работают) ipv4 протокол приоритетней чем ipv6
@bolvan Подскажите, пожалуйста, можно ли подобрать через blockcheck стратегию обхода для конкретного GGC (типа rr…googlevideo.com)? И если да - верно ли написана инcтрукция https://ntc.party/t/подбор-рабочего-конфига-для-ggc-ютуба-через-blockcheck/ ?
у меня сейчас ютуб работает с такими параметрами --dpi-desync=disorder2 --dpi-desync-split-pos=1 --dpi-desync-any-protocol. Если убрать --dpi-desync-any-protocol, то сайт зависает при открытии. Если это не quic, то на какой протокол срабатывает этот параметр?
Помогите понять картину. Сегодня при разных стратегиях zapret наблюдаю следующее:
Грузится где-то каждое пятое видео, может реже.
Если для видео предлагается хотя бы один GCS вида rrN—sn-5goXXX, то видео проигрывается. Например:
rr1---sn-5goeenes.googlevideo.com 74.125.108.230
rr1---sn-5go7ynlk.googlevideo.com 173.194.6.6
rr1---sn-5go7ynl6.googlevideo.com 74.125.111.38
rr2---sn-5go7ynlk.googlevideo.com 173.194.6.7
rr3---sn-5goeenes.googlevideo.com 74.125.108.232
rr3---sn-5go7ynld.googlevideo.com 74.125.111.72
rr4---sn-5go7ynl6.googlevideo.com 74.125.111.41
Если оба предложенных GCS имеют вид rrN—n8v7XXXX, то видео не проигрывается. Запросы висят несколько секунд и дропаются по таймауту. Например:
rr15---sn-n8v7knel.googlevideo.com 173.194.180.97
rr12---sn-n8v7znzl.googlevideo.com 74.125.153.156
rr12---sn-n8v7kne7.googlevideo.com 173.194.177.222
rr1---sn-n8v7knee.googlevideo.com 173.194.178.19
rr10---sn-n8v7znly.googlevideo.com 173.194.178.220
rr9---sn-n8v7zns7.googlevideo.com 173.194.179.27
rr9---sn-n8v7knes.googlevideo.com 173.194.180.155
rr6---sn-n8v7znly.googlevideo.com 173.194.178.216
Причем, если пинговать адреса из первой группы, с которыми все ок, то для них всех из России пинги ~20мс, из Голландии ~25мс.
Если пинговать проблемные адреса, то из России пинги <3мс, а из Голландии >40мс.
ip у всех вроде американские.
Вчера все работало нормально.
А почему вам вообще адреса из Швеции подсовывает? Вы какой-нибудь ВПН или цензортрекер используете?
Попробуйте через командную строку curl -sv -o NUL https://rr и сюда пару адресов из первой группы и пару из второй.
Нет, не американские. В первой группе у вас Швеция, во второй - Москва.
https://www.nslookup.io/domains/rr1—sn-5goeenes.googlevideo.com/dns-records/
Попробуйте стратегии из вот этого поста.
На адресах ggc стоящих в рф и стыках google в РФ они включили тот самый фильтр что режет фейки. До адресов вне РФ у них руки не дошли.
Поэтому адреса в РФ пробиваются одной стратегией, адреса вне РФ другой.
У меня вообще адреса из обоих списков без обхода достаются 
Хорошие:
rr1---sn-5goeenes
curl -sv -o NUL https://rr1---sn-5goeenes.googlevideo.com
* Host rr1---sn-5goeenes.googlevideo.com:443 was resolved.
* IPv6: 2a00:1450:400f::6
* IPv4: 74.125.108.230
* Trying 74.125.108.230:443...
* Connected to rr1---sn-5goeenes.googlevideo.com (74.125.108.230) port 443
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* found 171 certificates in /etc/ssl/certs/ca-certificates.crt
* found 515 certificates in /etc/ssl/certs
* SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: *.c.docs.google.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: EC/ECDSA
* certificate version: #3
* subject: CN=*.c.docs.google.com
* start date: Tue, 27 Aug 2024 14:31:13 GMT
* expire date: Tue, 05 Nov 2024 14:31:12 GMT
* issuer: C=US,O=Google Trust Services,CN=WR2
* ALPN: server did not agree on a protocol. Uses default.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: rr1---sn-5goeenes.googlevideo.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Date: Fri, 13 Sep 2024 23:25:14 GMT
< Content-Type: text/html; charset=UTF-8
< Server: gvs 1.0
< Content-Length: 1561
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
<
{ [1561 bytes data]
* Connection #0 to host rr1---sn-5goeenes.googlevideo.com left intact
rr1---sn-5go7ynlk
curl -sv -o NUL https://rr1---sn-5go7ynlk.googlevideo.com
* Host rr1---sn-5go7ynlk.googlevideo.com:443 was resolved.
* IPv6: 2a00:1450:400f:8::6
* IPv4: 173.194.6.6
* Trying 173.194.6.6:443...
* Connected to rr1---sn-5go7ynlk.googlevideo.com (173.194.6.6) port 443
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* found 171 certificates in /etc/ssl/certs/ca-certificates.crt
* found 515 certificates in /etc/ssl/certs
* SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: *.c.docs.google.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: EC/ECDSA
* certificate version: #3
* subject: CN=*.c.docs.google.com
* start date: Tue, 27 Aug 2024 14:31:13 GMT
* expire date: Tue, 05 Nov 2024 14:31:12 GMT
* issuer: C=US,O=Google Trust Services,CN=WR2
* ALPN: server did not agree on a protocol. Uses default.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: rr1---sn-5go7ynlk.googlevideo.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Date: Fri, 13 Sep 2024 23:25:19 GMT
< Content-Type: text/html; charset=UTF-8
< Server: gvs 1.0
< Content-Length: 1561
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
<
{ [1561 bytes data]
* Connection #0 to host rr1---sn-5go7ynlk.googlevideo.com left intact
Плохие:
http://rr15---sn-n8v7knel
curl -sv -o NUL https://rr15---sn-n8v7knel.googlevideo.com
* Host rr15---sn-n8v7knel.googlevideo.com:443 was resolved.
* IPv6: 2a00:1450:4011:4f::21
* IPv4: 173.194.180.97
* Trying 173.194.180.97:443...
* Connected to rr15---sn-n8v7knel.googlevideo.com (173.194.180.97) port 443
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* found 171 certificates in /etc/ssl/certs/ca-certificates.crt
* found 515 certificates in /etc/ssl/certs
http://rr12---sn-n8v7znzl
curl -sv -o NUL https://rr12---sn-n8v7znzl.googlevideo.com
* Host rr12---sn-n8v7znzl.googlevideo.com:443 was resolved.
* IPv6: 2a00:1450:4011:38::1c
* IPv4: 74.125.153.156
* Trying 74.125.153.156:443...
* Connected to rr12---sn-n8v7znzl.googlevideo.com (74.125.153.156) port 443
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* found 171 certificates in /etc/ssl/certs/ca-certificates.crt
* found 515 certificates in /etc/ssl/certs
У меня настроена раздельная маршрутизация, и youtube идет не через vpn.
Ну это не объясняет почему вам выдаются серваки из Швеции и из Москвы одновременно. Я такое наблюдал, когда youtube.com пустил через прокси, а googlevideo.com напрямую.
Попробуйте стратегию --dpi-desync=disorder2 или --dpi-desync=split2 --dpi-desync-split-seqovl=1 без всего остального. Там начали фейки блочить недавно, так что у большинства работает только без них.
Попробовал эти две стратегии и все стратегии из вашего поста выше.
Картина везде одинаковая.
Редкие видео грузятся, когда из двух предложенных адресов GCS один “шведский”, а второй “московский”.
Почему он предлагает их одновременно, не знаю.
До вчерашнего дня все работало с параметрами
--dpi-desync=fake,disorder2 --dpi-desync-split-pos=1 --dpi-desync-fooling=md5sig
А если rst вместо fake в вашу прошлую стратегию запихнуть. Ещё можно фейковый пейлоад свой попробовать. Я пейлоад от гугл диска использую и он вроде проходит. Вот тут написано как.
Если не помогает - проверить нерабочий сервер через blockcheck.
Если всё еще не помогает - заблочить нерабочие сервера через ublock/adblock вот по такой схеме:
||rr*---sn-n8v7*.googlevideo.com^
Возможно, станет лучше.
C rst картина аналогичная.
Про пейлоады вроде выше bol-van писал, что это нерабочая тема.
Пробовал с госуслугами и кастомным google.com с аналогичным результатом, а точнее его отсутствием.
blockcheck предлагает просто disorder2.
Про блокировку через ublock тред читал, но как я понимаю, это поможет только, если в видео хотя бы один из двух предлагаемых GCS адресов рабочий. Второй будет отваливаться быстрее по ublockу, и видео будет грузиться с рабочего. Когда почти в каждом видео оба адреса нерабочие, то это не поможет. Но может я неправильно это понимаю.
К тому же у вас, как я понял, дело решилось добавлением двух блоков из 8 адресов в правила ublock. Я пинговал неработающие адреса и соседние по нумерации, и там счет быстро перевалил за 100.
Может завтра сутра свежим взглядом увижу, чего не замечаю.
У меня вариант с кастомным пэйлоадом пока работает, хз.
Пустите сам youtube.com через впн, вам должно больше иностранных серверов начать подкидывать. Трафик идет с googlevideo.com, так что на ВПНе не скажется.
Ну или можно извратиться и смотреть через внешний плеер, если прокси сделать. В mpv, например, прописываете в conf файл:
script-opts=ytdl_hook-ytdl_path=D:\Soft\YT-DLP\yt-dlp.exe
ytdl-raw-options=proxy=[socks5h://127.0.0.1:8888]
ytdl-format='bestvideo+bestaudio/best'
rtsp-transport=tcp
hwdec=auto
Он будет получать ссылки через прокси, а тянуть напрямую.
В mpc-hc тоже можно сделать. Про другие плееры не знаю, не пробовал.
Как это с раздельной маршрутизацией реализуется хз.
На этом мои предложения всё.
2 день не могу победить МТС - вроде бы пишут что эта рабочая-
NFQWS_OPT_DESYNC=“–dpi-desync=fake,disorder2 --dpi-desync-split-pos=1 --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --dpi-desync-repeats=6 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync-fake-tls=/opt/zapret/files/fake/dtls_clienthello_w3_org.bin”
Но и она не помогла. Вроде бы уже все перебрал, до 12 работало все идеально. Меняя параметры то рутрекер работает, то нет, но ютюб все 2 дня одинаково не работает (либо вообще сайт не открывается, либо открывается со скрипом но видео не грузит).
Жесть ты нагородил. Это до ненужного усложненная стратегия. Попробуй вот из этого поста.
А вообще, просто ищите несколько заблоченных сайтов, прогоняете их через блокчек и пытаетесь совместить найденные стратегии. Касаемо ютуба, под него лучше отдельную стратегию без фейков, тупо disorder2, например. Потому что там нынче блочатся фейки.
Почему до ненужного? У меня как раз такая сейчас работает, только со стандартным пейлоадом. Для многих ресурсов мне хватает --dpi-desync=disorder2 --dpi-desync-split-pos=1 --dpi-desync-any-protocol, но некоторые эта стратегия ломает. А с вышеуказанной работает почти все, в т.ч. и инста. Совет с блокчеком правильный, вот только знать бы еще как совместить несколько результатов в одном чтобы работало все. )
Попробовал все 6 из поста сейчас - рутрекер открывается, а ютюб нет, либо со скрипом загружает превьюхи, а самое видео нет.
Какие я только не пробовал за 2 дня, просто все тут не перечислю, по ютюбу результат нулевой. А вот рутрекер то отваливался то работал при переборе стратегий.
Пока перебирал так этот сайт отвалился, так как он в списке есть. Пока вернул старую
Инста по айпи заблочена на большей части территории. Она открывается если тебе dns другой айпи подсовывает. От gdpi это не зависит. Я уже об этом писал.
Стратегия реально слишком сложная. --dpi-desync=fake,disorder2 --dpi-desync-fooling=badseq должно хватать. Если badseq блочится, то md5sig. Если фейк блочится, то rst. Или кастомный пейлоад. Или --dpi-desync-fake-tls=0x00000000
Для googlevideo.com отдельный инстанс с --dpi-desync=disorder2 без всего.