Windows 11 24H2 (BBR2) — проблемы с работой программ в режиме системного прокси [Решение]

[Rodcrit]

После обновления до 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 в условиях высокой нагруженности сети. Каких-либо несовместимостей это не вызывало, поэтому на первый взгляд взаимосвязь с неработоспособностью системных прокси была неочевидна. Например, на 23H2 такое поведение не наблюдается.

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

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

Было

Стало

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

UPD1: незначительное изменение формулировок, удаление фактически неверной информации.

[dartraiden]

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

[alk2ntc]

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

[dartraiden]

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

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

[Rodcrit]

@dartraiden

FYI, для установки настройки существует командлет Set-NetTCPSetting

Да, можно и так, но на практике работает через раз — атрибут CongestionProvider в read-only для всех групп, и это, видимо, считается ожидаемым поведением. Через netsh всё меняется без проблем.

Set-NetTCPSetting и netsh

Set-NetTCPSetting:

netsh:

@alk2ntc

То есть у меня при переходе на 24H2 ничего не поменялось.

@dartraiden

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

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

А автор и правда напутал — на полностью свежей системе действительно используются CUBIC + NewReno, так что проблем без дополнительных модификаций, как в моём случае, быть не должно. Инфа про изменённые дефолты была взята из найденных постов по проблеме, в части из которых ошибочно утверждалось, что в 24H2 BBR2 якобы «используется из коробки». Уберу этот момент из шапки, спасибо за информацию.

@dartraiden

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

И то верно. К тому же, как выяснилось при диагностике, кнопка в «Параметрах», которая, казалось бы, должна возвращать все параметры до дефолтных значений, делает это не до конца.

Network Reset

После якобы «полного» сброса настроек — как видно, Compat и Internet по-прежнему не на дефолтных значениях:

Если бы функциональность действительно соответствовала описанию, то всё могло бы свестись к паре кликов и перезагрузке. К продуктам Microsoft это утверждение, увы, часто неприменимо, — таков путь.