Матрица для Windows 11, когда Chrome работает, но отдельные настольные приложения не подключаются: как сравнить браузерный Secure DNS, WinHTTP proxy и доступность конкретных HTTPS-узлов без сброса всей сети.
Опишите границу по приложениям и конечным узлам
Составьте список из одного работающего браузерного адреса и двух неработающих приложений. Для каждого запишите точный текст ошибки, время и этап: вход, обновление или постоянное соединение. Не называйте проблему общим отсутствием интернета, если новые HTTPS-страницы открываются. Одновременно не считайте приложение доказательством доступности всего сервиса: оно может использовать уже установленную сессию. Если производитель публикует домены для диагностики, используйте только их; не извлекайте токены из журналов и не публикуйте URL с параметрами входа. Повторите на второй разрешённой сети. Если набор сбоев меняется вместе с сетью, проверяйте её прокси и фильтры; если следует за ПК, переходите к системным путям.
Не переносите результат Chrome Secure DNS на всю Windows
Google объясняет, что Secure DNS в Chrome шифрует поиск имён внутри браузерной функции и позволяет выбрать поставщика. Поэтому изменение этой настройки может изменить результат Chrome, но не подтверждает, что другие приложения используют тот же механизм. В свежем сигнале fast.com начал открываться после смены Secure DNS, тогда как два настольных приложения остались офлайн — это наблюдение, а не доказательство причины. Сравните исходный и изменённый режим только в браузере и верните настройку, если она не нужна. Не меняйте одновременно системный DNS, браузерный DNS и маршрутизатор. Если браузерный результат меняется, а приложения нет, фиксируйте разные пути вместо очередного сброса.
Прочитайте WinHTTP proxy и проверьте порт
Microsoft документирует WinHTTP как API сетевых запросов, который используют некоторые приложения, и предоставляет читающую команду show proxy. Зафиксируйте текущий результат, не выполняя reset или set. Наличие прокси или обходного списка — повод сверить настройку с владельцем устройства; отсутствие прокси не исключает другие стеки. Затем Test-NetConnection позволяет проверить диагностическую информацию для конкретного имени и TCP-порта, например 443, без попытки входа. Успешный TCP-тест не подтверждает TLS, учётную запись или доступность API, а неуспешный не объясняет, кто фильтрует путь. Не тестируйте случайные адреса и не сканируйте диапазоны: используйте только официально указанный узел сервиса.
Соберите пакет, который различает уровни отказа
Для поддержки приложения передайте его версию, сборку Windows, точное время, текст ошибки, результат на второй сети, текущий WinHTTP proxy без внутренних адресов и итог одного Test-NetConnection к официальному узлу. Укажите, меняется ли только Chrome при переключении Secure DNS. Не отключайте защиту, не сбрасывайте Winsock и не переустанавливайте несколько программ до фиксации: эти действия стирают сравнение. Если два разных приложения одного издателя не работают, добавьте статус сервиса из официального канала; если не работают приложения разных издателей, полезнее системная граница. Остановитесь на управляемом компьютере: прокси, сертификаты и фильтрация могут быть политикой организации, которую должен проверять администратор.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по двум обезличенным публичным сигналам и официальной документации Google и Microsoft.
Источники и проверка
- Google Chrome Help — Manage Chrome safety and security on a computer проверено 2026-07-30
- Microsoft Learn — netsh winhttp проверено 2026-07-30
- Microsoft Learn — Test-NetConnection проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.