---

Да. Раз SFC/DISM уже отработали, а картина стабильная — DNS работает, TCP:443 работает, но TLS handshake обрывается, — я бы уже перестал делать обычные netsh reset.

Причём код 0x80090302, который ты видел раньше, в документации Microsoft соответствует SEC_E_UNSUPPORTED_FUNCTION и может появляться при TLS alert protocol_version. 

Давай сделаем нормальную глубокую диагностику, практически как сетевой инженер. Ничего пока не будем менять.

1. Сначала посмотрим, какие TLS-протоколы реально включены

PowerShell от имени администратора:

Get-TlsCipherSuite | Select-Object Name

И:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\*" -ErrorAction SilentlyContinue

И:

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" -Recurse -ErrorAction SilentlyContinue |
Get-ItemProperty -ErrorAction SilentlyContinue |
Select-Object PSPath,Enabled,DisabledByDefault

Скинь мне результат.


---

2. Посмотрим, что именно говорит Windows о TLS

Выполни:

Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Schannel'
    StartTime=(Get-Date).AddHours(-2)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated,Id,LevelDisplayName,Message |
Format-List

Вот это очень важно.

Если Windows сама пишет что-нибудь вроде:

TLS handshake failed

protocol version

fatal alert

cipher

certificate

Schannel


— мы практически получим диагноз.


---

3. Проверим TLS разных версий

Выполни по очереди:

curl.exe -vk --tlsv1.2 --tls-max 1.2 https://google.com

затем:

curl.exe -vk --tlsv1.3 https://google.com

и:

curl.exe -vk --tlsv1.2 --tls-max 1.2 https://example.com

Мне нужен результат всех трёх.


---

4. А вот это уже будет совсем серьёзная диагностика

Windows умеет сама записывать полный сетевой trace с пакетами, без установки каких-либо программ. Microsoft специально предоставляет netsh trace для таких случаев. 

Создай папку:

mkdir C:\NetTrace

Запусти запись:

netsh trace start scenario=InternetClient capture=yes report=yes tracefile=C:\NetTrace\internet.etl

После сообщения, что трассировка запущена, ничего больше не делай и выполни:

curl.exe -vk https://google.com

Дождись ошибки.

После этого:

netsh trace stop

Windows создаст .etl и диагностический .cab; Microsoft описывает именно такой способ сбора сетевого trace. 

Вот этот trace уже позволит понять, что происходит с TLS ClientHello/ServerHello/Alert, то есть можно будет увидеть, кто именно рвёт соединение. Анализ TLS handshake по сетевой трассировке — стандартный способ диагностики такой проблемы. 


---

Но я бы пока сделал ещё одну вещь

Выполни:

curl.exe -V

и:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber

Пришли мне одним сообщением скрины пунктов 1–3 + curl -V.

А если хочешь пойти совсем до конца, после этого сделаем netsh trace, и ты сможешь прикрепить сюда получившийся .etl/.cab. Тогда мы будем искать проблему уже не методом тыка, а по реальному сетевому обмену.

Пока ничего вроде Hyper-V, BIOS, реестра Schannel или брандмауэра не отключай. Сейчас у нас достаточно данных, чтобы сначала точно определить, какой именно этап TLS ломается.