может всё же кто-то подсказать?
попробуй убери порты 50000-50050 c udp и проверь останется ли проблема
если в этом хз как на вин приложении запрета решать проблему с войсами через ограничение по спискам ip, на роутере это реализуется через скрипт для дискорда где как раз прописано к каким ip применять дарение по этим портам
Убрал, проблема осталась. Вообще, отправка файлов в tg идёт по tcp же. На всякий случай почистил файл с хостами, оставил только от ютуба - тоже без изменений.
текущие настройки
C:\Soft\zapret\zapret-winws\winws.exe --wf-l3=ipv4 --wf-tcp=80,443 --wf-udp=443 --filter-tcp=80 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake,split2 --dpi-desync-fooling=md5sig --dpi-desync-autottl --new --filter-tcp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake,fakedsplit --dpi-desync-fooling=datanoack --dpi-desync-split-pos=1 --dpi-desync-fake-tls=C:\Soft\zapret\my_fakes\tls_clienthello_drive_google_com.bin --new --filter-udp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake --dpi-desync-repeats=3 --dpi-desync-fake-quic=C:\Soft\zapret\my_fakes\quic_pl_by_ori.bin
Попробуй число репитов увеличить на 10 или 20
проверил, действительно) не знаю почему всегда считал что udp
PS
батька пояснил ниже в чём проблема)
повторы там на UDP, так что тоже бестолку
От этого никуда не уйти. Перехват пакетов и пересылка их из ядра в user mode процесс - штука затратная. Если в linux есть ограничитель в ядре connbytes, то в windivert его нет, поэтому весь отсылаемый трафик по фильтру идет в winws. В последних версиях предприняты меры для смягчения этой проблемы - пустые ACK не пересылаются. Но при upload пакеты не пустые, они пойдут все. На достаточно мощном проце со скоростями <100 мбит это практически незаметно. Если проц слаб, а линк толст, то будет жрать вплоть до целого ядра.
Только в телеграм, а не битторрент, потому что обычно ставится фильтр windivert --wf-tcp=443. Телега работает по 443 порту. В броузере при аплоаде будет тоже самое.
Возможное решение - перенос zapret на роутер.
Большое спасибо за ответ 
А что вы считаете за мощный процессор в данном контексте, вот есть какой-нибудь Ryzen 7800x3d, он мощный для игр, но мощный ли он для той задачи что вы описали или надо какой-нибудь 9950x 16 ядерный непонятно, можете внести ясность от какого процессора надо считать мощность
На core i7 12 поколения 650 mbit вызывает загрузку половины одного performance ядра.
При этом более 90% приходится на kernel mode, тк сам winws практически ничего не ест. Тяжела сама пересылка из windivert. На NFQUEUE или ipdivert та же картина, это by design. Но в linux есть connbytes. В BSD будет та же самая проблема
При 100 мбит будет <10% одного ядра, а ядер более десяти и еще потоки. Даже не заметите. Причем это только на мощном upload и только в прогах на 443 порту
Если проц intel до 8-10 поколения (точно не знаю), рекомендую отключить митигацию от meltdown. Импортнуть рег файл и ребутнуться.
Это может немного охладить проц. Поскольку часто идет переключение kernel<>user
Если проц новее, рег файл на скорость не повлияет. Узнать подвержен ли проц уязвимости можно через powershell. См хабр
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverride"=dword:02000003
"FeatureSettingsOverrideMask"=dword:02000003
такую прогу юзал когда на интеле сидел, inSpectre. Там вроде 2 патча отключает которые тормозят проц, либо реестром.
Это ничего не даст уже, на современных системах от этого с погрешности разница, лучше уж 24h2/2025 поставить, где все на sse4.2 перекомпилированно с поддержкой netadaptercx для разгрузки проца
спасибо за разъяснение! когда тыкался и смог завести дискорд, то после прогрузки самого приложения, медия и голосовой чат без проблем грузились, видимо, моя udp стратегия еще рабочая, на крайний случай всегда есть vpn. но пользоваться запретом все равно нравится больше, банально удобнее, да и самому решать проблемы всегда интереснее, пускай даже за помощью иногда приходится обращаться к другим, так что еще раз спасибо за отзывчивость, в следующий раз попробую посмотреть, что там на udp происходит
Разницы не будет на системах, не подверженных атаке meltdown, поскольку ОС обнаруживает такие системы и не включает митигацию.
На подверженных будет значительная разница, когда идет частое переключение колец защиты, тк митигация сбрасывает при этом кэш в проце. Любой сисколл - сброс кэша. Падение будет до 30%
@bolvan спасибо за v70.5, теперь в хроме по h3 YT стал с первой попытки подключаться.
возвращаясь к теме с quic
да. теперь не обязательно указывать --origin-to-force-quic-on чтобы видео грузилось по h3
правда напрямую ggc так и не открывается)
множественные фейки - это имеется ввиду?
--dpi-desync-fake-quic="%~dp0fake\quic_3.bin" --dpi-desync-fake-quic="%~dp0fake\quic_2.bin" --dpi-desync-fake-quic="%~dp0fake\quic_1.bin"
Как-то так. Порядок отсылки слева направо.
Запрос был на эту функцию по TCP TLS. Там у кого-то работало из гудбай отсылка большого фейка, потом 160301
Дискорд не проходит апдейт чек, сайт не открывается, из сессии выкидывает.
Помогите разобраться пожалуйста
https://pastecode.io/s/ay5ndwvd
Скрипт лежит естественно
как сделать при аутохотслисте чтобы google.com не попадал в листы дурения, но попадали его поддомены?
в zapret-hosts-user-exclude ^google.com?