После обновления до 24H2 на основной машине и переустановки системы на рабочем ноутбуке обнаружилась неприятная особенность, что программы для обхода замедления общеизвестного списка ресурсов, в которых используется режим системного прокси, отказываются работать. В логах по нулям (буквально). Гуглить проблему сложно, поэтому решил написать дополнительный пост здесь.

Симптомы:

• NekoRay/NekoBox — нет подключения, почти сразу появляется всплывающее окно в духе «This action is taking a long time, try reconnecting», соединение не устанавливается
• v2RayN — подключение якобы устанавливается, соединение не работает. В статус-баре снизу «The delay: -1 ms, none», трафик не гоняется
• Hiddify — подключение якобы работает (статус «Connected»), фактически соединение не установлено, трафик никуда не идёт.

TUN во всех случаях продолжает работать, условные WARP или Amnezia WG функционируют. На Reddit пишут, что этим, в числе прочего, могут быть обусловлены рандомные ошибки NS_BINDING_ABORTED в Firefox, которым так и не нашли объяснения в соседних темах на форуме.

В процессе диагностики перепробовал буквально всё — сброс сетевых настроек (тут я был близко), манипуляции с DNS, отключение Zapret, изменение настроек внутри самих программ и много чего ещё. Ничего из вышеперечисленного не дало результата, так как виноватым, внезапно, оказался алгоритм контроля перегрузки TCP (TCP Congestion Control Provider). Issue на Гитхабе v2RayN.

При каждой переустановке системы я всегда менял его на BBR2, так как он объективно лучше стандартного CUBIC в условиях высокой нагруженности сети. На 24H2 его сделали стандартным, но при этом как-то умудрились сломать в процессе. На 23H2 использование BBR никаких проблем не вызывало, любые прокси работали идеально.

Поменять алгоритм можно так:

1. Открываем PowerShell от админа.
2. Вводим:

netsh int tcp set supplemental template=internet congestionprovider=CUBIC
netsh int tcp set supplemental template=internetcustom congestionprovider=CUBIC
netsh int tcp set supplemental template=Compat congestionprovider=NewReno
netsh int tcp set supplemental template=Datacenter congestionprovider=CUBIC
netsh int tcp set supplemental template=Datacentercustom congestionprovider=CUBIC

3. Проверяем настройки: Get-NetTCPSetting | Select SettingName, CongestionProvider

Было

BBR2697×200 3.68 KB

Стало

CUBIC & NewReno693×198 3.85 KB

При желании CUBIC можно заменить на CTCP. Он, насколько известно, чуть лучше показывает себя в процессах, чувствительных к задержкам.

FYI, для установки настройки существует командлет Set-NetTCPSetting. Просто получается неаккуратненько: устанавливаете с помощью netsh, а проверяете с помощью пошика.

Прочел статью и ввел на Win11 24H2 команду для проверки. Получил без каких-либо преобразований результат с четырьмя кубиками и одним NewReno. То есть у меня при переходе на 24H2 ничего не поменялось. Может ли это быть связанным с тем, что алгоритмы Windows меняют что-то в условиях медленной или перегруженной сети? Потому что у меня не медленная и не перегруженная, и всё как работало, так и работает.

В свежеустановленной системе по умолчанию тоже CUBIC, поэтому есть мнение, что это автор напутал и BBR у него перенёсся со старой системе.

То, что BBR сломали, это, конечно, печально, но иллюстрирует то, почему твикать всё, что твикается - чревато и менять дефолты без веской причины не стоит (возможно, на диагностику было затрачено больше ресурсов, чем получено профита от смены алгоритма)