Виправити «Немає інтернету, захищено», скинувши потрібний мережевий адаптер

February 6, 2026 • February 6, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви підключені по Wi‑Fi. Сигнал виглядає нормально. Windows ввічливо каже «Немає інтернету, захищено», ніби робить вам послугу. Тим часом браузер крутиться, VPN-клієнт сумує, Teams каже, що «намагається підключитися», а ваша кава остигає в реальному часі.

Зазвичай це не проблема «інтернет впав». Це проблема «машина вирішила, який адаптер треба використовувати, і в цьому помилилася». Виправлення часто просте: скиньте потрібний мережевий адаптер і стек навколо нього. Складніше — зрозуміти, який адаптер фактично задіяний і який побічний ефект ви викличете.

Що насправді означає «Немає інтернету, захищено»

Windows дивиться не лише на значок замка Wi‑Fi. Він виконує перевірки доступності та оцінює, чи може дістатися до широкого інтернету. Коли він каже «Немає інтернету, захищено», це зазвичай означає:

Ви асоційовані з точкою доступу (процес безпечного з’єднання пройшов успішно).
У вас є якась IP-конфігурація (може бути дійсна, а може бути безглузда).
Проба доступності Windows провалилася, або ваш маршрут за замовчуванням/шлях DNS зламані.

Тому інколи ви все ще можете отримати доступ до внутрішніх ресурсів (принтер, NAS або корпоративний інтранет), поки Windows наполягає, що інтернету немає. Частина «захищено» стосується шифрування Wi‑Fi, а не безпеки вашого перегляду, корпоративного проксі чи вашого морального обличчя.

З погляду SRE, машина каже: «Рівень 2 (канальний) виглядає добре, але рівні 3/4/7 викликають підозру». Виправлення — не повторювати натискання на іконку Wi‑Fi у надії покращити таблиці маршрутів через атмосферу.

Швидкий план діагностики (перший/другий/третій)

Якщо ви нічого більше не зробите — зробіть це. Це найкоротший шлях до виявлення вузького місця.

Перший: визначте активний шлях (адаптер, IP, шлюз)

Знайдіть адаптер, який має шлюз за замовчуванням.
Підтвердьте, що IP знаходиться в очікуваному підмережі для цієї мережі.
Перевірте, чи випадково не маршрутизуються через VPN/віртуальний адаптер.

Рішення: якщо маршрут за замовчуванням вказує на невірний адаптер — спочатку скиньте/відключіть невірний. Не «скидайте все», поки не зрозумієте, чому Windows обрав саме його.

Другий: протестуйте DNS чи маршрути (розділіть проблему)

Ping до шлюзу (локальна маршрутизація).
Розв’язання імені (DNS).
Підключення до IP напряму (обхід DNS).

Рішення: якщо IP-зв’язок працює, але розв’язання імен не працює — виправляйте DNS/проксі, а не Wi‑Fi.

Третій: перевірте стан мережевого стеку Windows (Winsock, брандмауер, драйвери)

Перевірте, чи VPN, агент безпеки або фільтруючий драйвер не перехоплює трафік.
Скидайте Winsock/TCP/IP лише коли впевнилися в проблемі стеку.
Оновіть або відкотіть драйвер Wi‑Fi, якщо симптоми корелюють зі сном/пробудженням або недавніми оновленнями.

Рішення: уникайте «ядерних» скидань у робочий день, якщо ви покладаєтеся на спеціалізовані профілі VPN або корпоративні сертифікати, які можуть потребувати повторної реєстрації.

Цікаві факти та коротка історія (покращить вашу діагностику)

Це не просто дрібниці. Вони пояснюють, чому виникає проблема і чому певні «виправлення» працюють.

Windows не «вгадує» доступ до інтернету; він його перевіряє. Сучасний Windows використовує механізм перевірки доступності (зазвичай NCSI), який перевіряє доступність відомих кінцевих точок і поведінку DNS.
Каптивні портали навмисно ламають перевірки. Готелі та гостьові мережі часто підміняють DNS або HTTP, щоб показати сторінку входу; Windows трактує це як «не справжній інтернет», поки ви не автентифікуєтесь.
«Метрика» вирішує, який адаптер перемагає. Якщо є кілька маршрутів (Wi‑Fi, Ethernet, VPN, Hyper‑V vSwitch), Windows обирає найнижчу метрику для маршруту за замовчуванням. Це не завжди той адаптер, який ви вважаєте активним.
Winsock — це рубці Windows-мереж. Багато продуктів безпеки та VPN встановлюють компонентні фільтри; коли вони працюють некоректно, виникають дивні симптоми, що виглядають як «Wi‑Fi зламався».
IPv6 може бути відволікаючим фактором. Деякі мережі рекламують IPv6, але не забезпечують робоче upstream-з’єднання. Windows може віддавати перевагу IPv6, зазнати збою і не повернутися до IPv4 залежно від налаштувань і таймаутів.
Віртуальні адаптери розмножуються як кролики. Hyper‑V, WSL, Docker Desktop і VPN створюють адаптери. Кожен з них — це шанс, що Windows направить трафік у невигідне місце.
Відмова DHCP може виглядати як «захищено». Якщо DHCP не працює, Windows може самостійно призначити APIPA-адресу (169.254.x.x). Ви все ще будете «підключені» до Wi‑Fi, але фактично залишитесь на острові.
Управління живленням драйверів — постійний підозрюваний. Помилки після сну/пробудження і опція «Дозволити комп’ютеру вимикати цей пристрій для економії енергії» спричинили більше ранкових інцидентів, ніж будь‑яка прошивка роутера, яку я зустрічав.

Виберіть правильний адаптер (перед скиданням)

«Скинути мережевий адаптер» — це хороша порада так само, як «перезапустити сервер» — працює, але безвідповідально, коли ви не знаєте, що перезапускаєте.

На сучасному ноутбуку з Windows імовірно є:

Фізичний Wi‑Fi адаптер (Intel/Realtek/Qualcomm).
Можливо фізичний Ethernet-адаптер (або USB-донгл).
Один або кілька VPN-адаптерів (WireGuard, AnyConnect, GlobalProtect тощо).
Віртуальні свитчі (Hyper‑V, VMware, VirtualBox).
Loopback та тунельні адаптери (Teredo, ISATAP — рідше тепер, але трапляються).

Ваша мета — знайти адаптер, який Windows використовує для маршруту за замовчуванням до інтернету. Тоді ви скидаєте саме його — або виправляєте причину, чому Windows обрав неправильний.

Короткий жарт #1: Мережеві адаптери — як середні менеджери: ви помічаєте їх тільки тоді, коли вони «допомагають».

Практичні завдання: команди, виводи, рішення (12+)

Ці завдання припускають, що ви можете відкрити піднятий PowerShell або Command Prompt у Windows. Команди реальні. Приклади «виводів» репрезентативні — ваші будуть відрізнятися. Кожне завдання завершується рішенням, яке ви повинні прийняти.

Завдання 1: Побачити, що Windows вважає підключеним

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
------------------------------------------------------------------------
Enabled        Connected      Dedicated        Wi-Fi
Enabled        Disconnected   Dedicated        Ethernet
Enabled        Connected      Dedicated        VPN - Corp
Enabled        Connected      Dedicated        vEthernet (Default Switch)

Що це означає: Багато «Connected» інтерфейсів — нормально. Це також шлях до того, щоб вас націлили в чорну діру.

Рішення: Якщо VPN або віртуальний свитч підключені, а не повинні бути — ймовірно, проблема в маршрутизації/метриці. Не скидайте Wi‑Fi спочатку; визначте, який адаптер володіє маршрутом за замовчуванням.

Завдання 2: Показати IP-конфігурацію і знайти шлюз за замовчуванням

cr0x@server:~$ ipconfig /all
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201
   Physical Address. . . . . . . . : 3C-52-82-11-22-33
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . : 192.168.1.57(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.1

Ethernet adapter VPN - Corp:

   IPv4 Address. . . . . . . . . . . : 10.44.12.8(Preferred)
   Default Gateway . . . . . . . . . : 
   DNS Servers . . . . . . . . . . . : 10.44.0.53

Що це означає: Адаптер з шлюзом за замовчуванням зазвичай є тим, що дає маршрут назовні. VPN-адаптери часто не показують шлюз, але можуть встановлювати маршрути.

Рішення: Якщо Wi‑Fi не має шлюзу або він дивний (наприклад 0.0.0.0 або порожній) — виправляйте DHCP або статичну конфігурацію. Якщо у Wi‑Fi є шлюз, але інтернету немає — продовжуйте розбиратися з маршрутизацією, DNS або фільтрацією.

Завдання 3: Проінспектувати таблицю маршрутів і знайти маршрут за замовчуванням

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.57     35
         10.0.0.0        255.0.0.0         On-link      10.44.12.8      5
    192.168.1.0    255.255.255.0         On-link     192.168.1.57    291
===========================================================================

Що це означає: Маршрут за замовчуванням — 0.0.0.0/0. Тут він вказує на шлюз Wi‑Fi 192.168.1.1 — добре. Зверніть увагу на маршрут VPN для 10.0.0.0/8 з нижчою метрикою; це нормально для split-tunnel.

Рішення: Якщо 0.0.0.0/0 вказує на VPN/віртуальний адаптер несподівано — відключіть цей адаптер або виправте його метрику. Скидання Wi‑Fi не допоможе, якщо трафік ніколи не виходить через Wi‑Fi.

Завдання 4: Перевірити метрики інтерфейсів (відповідь на «чому Windows обрав це?»)

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  6          35        1500  connected     Wi-Fi
 17           5        1400  connected     VPN - Corp
 22          25        1500  connected     vEthernet (Default Switch)

Що це означає: Нижча метрика перемагає. Якщо VPN має метрику 5 і встановлює маршрут за замовчуванням, він буде домінувати.

Рішення: Якщо Windows постійно віддає перевагу неправильному шляху — встановіть розумну метрику або вимкніть «automatic metric» на проблемному інтерфейсі.

Завдання 5: Доведіть локальну доступність: ping до шлюзу

cr0x@server:~$ ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64

Що це означає: Ви можете дістатися роутера/точки доступу на рівні 3. Проблема не в канальному підключенні Wi‑Fi.

Рішення: Якщо ping до шлюзу не проходить — виправляйте асоціацію Wi‑Fi, RF-проблеми, драйвер або локальні правила брандмауера. Якщо проходить — рухайтеся вгору по стеку.

Завдання 6: Перевірити маршрутизацію в інтернет без DNS: ping публічного IP

cr0x@server:~$ ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Request timed out.
Request timed out.

Що це означає: Або upstream-маршрутизація зламана, або ICMP блокується, або ваша таблиця маршрутів брешe. Не робіть ще висновків «ICMP заблокований» — протестуйте TCP далі.

Рішення: Якщо ping по IP не працює — протестуйте TCP (Завдання 8). Якщо TCP теж не працює — у вас справжня проблема з виходом/маршрутизацією/фільтрацією.

Завдання 7: Перевірити DNS: розв’язати ім’я

cr0x@server:~$ nslookup example.com
Server:  router.lan
Address: 192.168.1.1

Non-authoritative answer:
Name:    example.com
Addresses: 93.184.216.34

Що це означає: DNS-розв’язання працює через ваш налаштований сервер.

Рішення: Якщо DNS не працює, але IP-зв’язок є — змініть DNS-сервер, очистіть кеш DNS або виправте VPN/проксі, що підмінив DNS.

Завдання 8: Перевірити реальний TCP-зв’язок (достовірніше за ping)

cr0x@server:~$ powershell -Command "Test-NetConnection 1.1.1.1 -Port 443"
ComputerName     : 1.1.1.1
RemoteAddress    : 1.1.1.1
RemotePort       : 443
InterfaceAlias   : Wi-Fi
TcpTestSucceeded : True

Що це означає: У вас є реальний вихід у інтернет по 443, навіть якщо ping не проходить. Це часто буває в мережах з обмеженнями.

Рішення: Якщо TCP працює, але Windows все ще каже «Немає інтернету, захищено», підозрюйте каптив-портал, проксі-настройки або блокування NCSI.

Завдання 9: Перевірити налаштування проксі (класична корпоративна пастка)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) : 127.0.0.1:8080
    Bypass List     : (none)

Що це означає: Системний рівень WinHTTP змушує трафік йти через локальний проксі на порті 8080. Якщо цей проксі не працює (або блокується), багато додатків зламаються, навіть якщо браузер іноді працює.

Рішення: Якщо ви не використовуєте локальний проксі навмисно — скиньте його на пряму (Завдання 10).

Завдання 10: Скидання WinHTTP-проксі на пряму

cr0x@server:~$ netsh winhttp reset proxy
Current WinHTTP proxy settings:

    Direct access (no proxy server).

Що це означає: Системні компоненти перестануть намагатися маршрутизувати через проксі.

Рішення: Якщо після цього відновлюється підключення — ви знайшли винуватця: залишкові налаштування проксі від VPN/засобів безпеки або від ручного налагодження.

Завдання 11: Release/renew DHCP-лізу (виправляє погані ліси і застарілі опції)

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

An error occurred while renewing interface Wi-Fi : unable to contact your DHCP server. Request has timed out.

Що це означає: Wi‑Fi пов’язаний на рівні 2, але DHCP-пакети не отримують відповіді. Це може бути проблема точки доступу, помилка VLAN, ізоляція бездротових клієнтів або баг драйвера.

Рішення: Якщо оновлення DHCP таймаутить — спробуйте вимкнути/увімкнути адаптер, забути мережу або перевірити, чи точка доступу дійсно пропускає клієнтів до DHCP.

Завдання 12: Очистити кеш DNS (швидко, безпечно, часто марно — але інколи магічно)

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Що це означає: Ви очистили кешовані DNS-записи.

Рішення: Якщо після змін мережі/відключення VPN деякі сайти не працюють, очищення кешу допомагає. Якщо нічого не змінюється — не робіть це як ритуал.

Завдання 13: Скинути Winsock (виправляє симптоми з ланцюгом LSP/фільтрів)

cr0x@server:~$ netsh winsock reset
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Що це означає: Каталог Winsock скинуто. Це може видалити/відновити хуки, встановлені VPN та засобами безпеки.

Рішення: Використовуйте, коли підозрюєте аномалії рівня сокетів (додатки не можуть підключитися, але маршрути виглядають нормально). Плануйте перезавантаження.

Завдання 14: Скинути TCP/IP стек (більший молот, але легітимний)

cr0x@server:~$ netsh int ip reset
Resetting Global, OK!
Resetting Interface, OK!
Restart the computer to complete this action.

Що це означає: Налаштування TCP/IP скинуто до значень за замовчуванням.

Рішення: Робіть це, коли підозрюєте корупцію маршрутизації/стеку і попередні кроки не допомогли. Очікуйте, що кастомні статичні налаштування будуть стерті.

Завдання 15: Вимкнути та знову ввімкнути конкретний адаптер (точкове скидання)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=enabled

Що це означає: Ви перезавантажили інтерфейс Wi‑Fi, змусивши його повторно асоціюватись і оновити DHCP-ліз.

Рішення: Віддавайте перевагу цьому над «Network reset» у Settings, якщо хочете мінімальний боковий вплив.

Завдання 16: Показати стан бездротового з’єднання та підтвердити SSID/BSSID (виявити проблеми з роумінгом)

cr0x@server:~$ netsh wlan show interfaces
    Name                   : Wi-Fi
    State                  : connected
    SSID                   : CorpGuest
    BSSID                  : aa:bb:cc:dd:ee:ff
    Radio type             : 802.11ax
    Authentication         : WPA2-Personal
    Channel                : 36
    Receive rate (Mbps)    : 1201
    Transmit rate (Mbps)   : 1201
    Signal                 : 85%

Що це означає: Ви підключені до конкретної точки доступу (BSSID). Якщо ви на неправильному SSID (гостьовий vs корпоративний), все нижче може «працювати», але бути марним.

Рішення: Якщо SSID неправильний — забудьте мережу і підключіться до правильної. Якщо BSSID далеко і сигнал посередній — примусово перепідключіться або змусьте роумінг.

Завдання 17: Перевірити, чи отримали ви APIPA-адресу (детектор DHCP-помилок)

cr0x@server:~$ ipconfig
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 169.254.88.12
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . :

Що це означає: APIPA. Windows відмовився від DHCP і самопризначив адресу. Ви не матимете нормального інтернету з цього підключення.

Рішення: Припиніть займатися DNS. Виправляйте доступність DHCP: перезавантажте адаптер, спробуйте інший SSID, перезавантажте AP або перевірте NAC/каптивний портал.

Завдання 18: Переконатися, що брандмауер не блокує вихід у дивному профілі

cr0x@server:~$ netsh advfirewall show allprofiles state
Domain Profile Settings:
State                                 ON

Private Profile Settings:
State                                 ON

Public Profile Settings:
State                                 ON

Що це означає: Брандмауер увімкнений для всіх профілів (нормально). Справжнє питання: чи не перейшла ваша мережа в «Публічний» профіль, в якому корпоративні політики блокують трафік?

Рішення: Якщо в організації суворі правила для публічного профілю, переконайтеся, що мережа класифікована правильно (або користуйтеся VPN, який терпить Public). Не вимикайте брандмауер просто так; з цього починаються звіти про порушення безпеки.

Стратегія скидання: від найменш руйнівного до найбільш

Скидання «правильного» адаптера — це про мінімізацію шкоди. Системи виробництва навчили мене цінувати маленькі зміни з чітким відкатом. Ваш ноутбук заслуговує на такий самий підхід.

Рівень 0: підтвердьте, що ви не переслідуєте реальний збій

Перевірте інший пристрій на тій самій Wi‑Fi (телефон працює? колега працює?).
Якщо у всіх немає інтернету — не звинувачуйте NIC, шукайте upstream.

Рівень 1: перепустіть тільки активний інтерфейс

Вимкніть/увімкніть Wi‑Fi (Завдання 15). Підключіться заново до SSID. Це змушує повторну асоціацію і обновлення без видалення налаштувань.

Рівень 2: вбити неправильних претендентів

Якщо VPN/віртуальні адаптери підключені — тимчасово відключіть їх. Ви не «виправляєте інтернет». Ви прибираєте заплутані альтернативні маршрути.

Типові винуватці:

VPN залишився підключеним, але не працює (split tunnel зламався).
Hyper‑V vSwitch захоплює маршрут за замовчуванням через Internet Connection Sharing.
Старі TAP/TUN адаптери від видалених VPN-клієнтів.

Рівень 3: освіжити адресацію і ім’я

Release/renew DHCP (Завдання 11).
Очистити DNS (Завдання 12).
Скинути WinHTTP-проксі (Завдання 10), якщо середовище дозволяє.

Рівень 4: скинути стек (потребує перезавантаження, іноді виправляє «примарні» проблеми)

Скидання Winsock (Завдання 13).
Скидання TCP/IP (Завдання 14).

Рівень 5: драйвер і налаштування живлення (смуга «зламалося після сну»)

Якщо проблема корелює з оновленням Windows, новим драйвером або пробудженням зі сну — перестаньте трактувати це як проблему DNS. Ймовірно, справа в драйвері. Оновіть драйвер Wi‑Fi від OEM або відкотіть, якщо останній — проблемний.

Короткий жарт #2: «Ви пробували вимкнути і ввімкнути?» — це просто «скинути становий автомат» з кращим маркетингом.

Поширені помилки: симптом → корінна причина → виправлення

Ось повторювані випадки, які я бачив у флоті ноутбуків, VDI-клієнтів і «тимчасових» конференц‑ПК, які тимчасові з 2017 року.

1) Симптом: «Підключено, інтернету немає», але VPN теж «підключений»

Корінна причина: VPN-адаптер має нижчу метрику і встановлює маршрут за замовчуванням; тунель зламаний, тому трафік губиться.

Виправлення: Відключіть VPN; вимкніть його адаптер; або виправте метрики/маршрути, щоб тільки потрібні префікси йшли через тунель.

2) Симптом: Браузер працює, але системні додатки (Store, Outlook, деякі оновлювачі) ламаються

Корінна причина: WinHTTP-проксі неправильно налаштований (часто лишається від агента або налагодження).

Виправлення: netsh winhttp reset proxy і перевірте налаштування проксі в системних параметрах.

3) Симптом: Можна пінгувати шлюз, але нічого далі

Корінна причина: Upstream-аутейдж, каптив-портал або брандмауер/NAC блокує невідомі пристрої.

Виправлення: Спробуйте відкрити просту HTTP-сторінку, щоб викликати каптив-портал; пройдіть аутентифікацію; або перевірте, чи SSID вимагає реєстрації пристрою.

4) Симптом: IP-адреса 169.254.x.x

Корінна причина: DHCP-збій. Іноді точка доступу неправильно налаштована; інколи ізоляція клієнтів блокує DHCP relay; інколи драйвер завис.

Виправлення: Перезапустіть Wi‑Fi адаптер; забудьте/підключіться заново; перезавантажте AP; перевірте VLAN і доступність DHCP-сервера.

5) Симптом: Тільки цей ноутбук падає на відомому хорошому Wi‑Fi

Корінна причина: Пошкоджений профіль мережі, зламаний фільтруючий драйвер або застарілі статичні IP/DNS налаштування.

Виправлення: Видаліть Wi‑Fi профіль і підключіться знову; скиньте Winsock/TCP/IP; перевірте, чи властивості адаптера не встановлені статично випадково.

6) Симптом: Працює на 2.4 GHz, але не на 5/6 GHz (або навпаки)

Корінна причина: Проблеми драйвера, пов’язані з конкретною смугою, DFS/каналом або невідповідністю режимів безпеки (перехід WPA3 може бути проблемним).

Виправлення: Оновіть драйвер; змініть канал/налаштування безпеки на AP; тимчасово примусьте клієнта на стабільну смугу, щоб перевірити гіпотезу.

7) Симптом: Після сну «Немає інтернету, захищено» до перезавантаження

Корінна причина: Помилка в управлінні живленням/драйвері, коли NIC не ініціалізується правильно або не відбувається оновлення DHCP-лізу.

Виправлення: Вимкніть агресивну економію енергії для адаптера; оновіть/відкотіть драйвер; використовуйте бадьорий перезапуск адаптера як тимчасове рішення.

8) Симптом: Інтернет працює, але Windows все одно показує «Немає інтернету»

Корінна причина: NCSI-проба блокується брандмауером/проксі/DNS-підміною; або інструмент приватності блокує перевірки доступності.

Виправлення: Якщо все, що вам потрібно, працює — можна не звертати уваги. Інакше дозвольте пробу або виправте поведінку DNS/проксі.

Контрольні списки / покроковий план

Контрольний список A: Швидке відновлення, коли потрібно просто отримати роботу

Переконайтесь, що SSID правильний (Завдання 16).
Вимкніть/увімкніть Wi‑Fi (Завдання 15).
Запустіть ipconfig і переконайтесь, що у вас реальний IP і шлюз за замовчуванням (Завдання 2, Завдання 17).
Протестуйте ping до шлюзу (Завдання 5).
Протестуйте TCP до зовнішнього IP (Завдання 8).
Якщо TCP працює, але імена не розв’язуються — виправляйте DNS (Завдання 7, Завдання 12).
Якщо системні додатки не працюють — скиньте WinHTTP-проксі (Завдання 10).
Якщо нічого не допомагає — скиньте Winsock (Завдання 13) і перезавантажте.

Контрольний список B: Правильна діагностика, коли проблема повторюється

Зніміть таблицю маршрутів і метрики інтерфейсів перед змінами (Завдання 3, Завдання 4).
Перелічіть всі підключені інтерфейси (Завдання 1). Визначте «очікувані/неочікувані» підключені адаптери.
Перевірте на APIPA і помилки поновлення DHCP (Завдання 11, Завдання 17).
Перевірте конфігурацію проксі (Завдання 9).
Корелюйте з подіями: сон/пробудження, док‑станція, підключення/відключення VPN, оновлення Windows.
Оновіть або відкотіть драйвер Wi‑Fi, якщо кореляція сильна.

Контрольний список C: Дерево рішень «скинути правильний адаптер»

Якщо маршрут 0.0.0.0/0 вказує на невірний адаптер → відключіть невірний адаптер або виправте його метрику/маршрути.
Якщо Wi‑Fi не має шлюзу або має APIPA → виправляйте DHCP (перезапуск адаптера, скидання профілю, проблема AP/VLAN).
Якщо IP працює, але DNS не працює → виправляйте DNS/проксі, а не Wi‑Fi.
Якщо TCP не працює, але ping шлюзу проходить → підозрюйте каптив-портал/NAC або upstream‑брандмауер.
Якщо все виглядає нормально, але додатки нестабільні → скидання Winsock/TCP/IP і дослідження фільтруючих драйверів.

Три міні-історії з корпоративного життя

Міні‑історія 1: Відмова через неправильне припущення

Налаштування здавалося безпечним: конференц-зала з док-станцією, Ethernet і «secure guest» Wi‑Fi як резерв. Гість поскаржився: на всіх Windows-ноутбуках Wi‑Fi показував Немає інтернету, захищено. Всі думали, що гостьовий SSID впав.

Фасиліті перезавантажили точку доступу. Не допомогло. Мережники перевірили аплінк. Чисто. Хтось зареєстрував інцидент «Wi‑Fi outage affecting conference rooms», і ось вам п’ять інженерів на дзвінку через проблему одного пристрою.

Неправильне припущення було тонким: вирішили, що шлях іде по Wi‑Fi. Насправді ноутбуки були в док-станції і мали USB Ethernet-адаптер, який показував «Disconnected», але через баг драйвера тримав найнижчу метрику. Windows продовжував намагатися відправляти трафік через привида Ethernet.

Ми довели це за хвилини, захопивши route print і netsh interface ipv4 show interfaces. Шлях за замовчуванням вказував на інтерфейс без фізичного лінку. Вимкнення того адаптера миттєво відновило інтернет по Wi‑Fi без втручання в AP.

Урок простий: не шукайте проблему там, де бачите іконку Wi‑Fi. Шукайте пристрій, який несе маршрут за замовчуванням. Це стало стандартним кроком служби підтримки: перевірити таблицю маршрутів, потім скинути правильний адаптер.

Міні‑історія 2: Оптимізація, що відбилась боком

Команда безпеки розгорнула «поліпшення продуктивності» для віддалених ноутбуків: агресивний завжди‑включений VPN із split tunneling, щоб зменшити навантаження на концентратори. На папері все елегантно — тільки корпоративні префікси йдуть у тунель, все інше — локальний інтернет.

Потім кількість звернень «Немає інтернету, захищено» різко зросла. Не повсюди. Тільки на певних домашніх роутерах і публічних Wi‑Fi. Ця часткова картина ускладнила діагностику, бо виглядала як помилка користувача.

Повернення додалося через метрики і поведінку DNS. VPN-клієнт правильно встановлював маршрути, але також інжектував корпоративні DNS-сервери, недоступні до стабілізації тунелю. Під час флапу тунелю Windows намагався розв’язувати імена через недосяжний DNS. IP‑зв’язок був, DNS — ні. UI говорив «Немає інтернету», і користувачі йому вірили.

Гірше, допоміжний скрипт намагався «почистити мережу», скидаючи весь стек, коли проба провалювалась. Це стирало керовані налаштування і спричиняло біль при повторній реєстрації сертифікатів для Wi‑Fi. Оптимізація постачалась з кнопкою скидання, яка фактично була розподіленим denial‑of‑helpdesk.

Вирішення було дисциплінованим: зберегти split‑tunnel маршрути, але не «отруювати» DNS під час нестабільності тунелю. Також припинити автоматичні скидання стеку — збирати докази спочатку. Діагностику можна автоматизувати, але автоматизація паніки — це все ще паніка.

Міні‑історія 3: Скупе, але правильне правило, що врятувало день

Фінансовий відділ мав суворе правило «без прав адміністратора». Люди скреготали зубами, поки це тихо не врятувало їх. У невеликій пілотній групі з правами адміністратора поширилася «покращувальна» утиліта для Wi‑Fi як диво‑рішення для відеодзвінків. Вона обіцяла «розумніший роумінг» і «прискорення інтернету», чого насправді не існує, але маркетинг має свої межі.

На машинах, де її встановили, Немає інтернету, захищено почало з’являтися після перезавантажень. Утиліта додала фільтруючий драйвер і змінила налаштування проксі. Вона не ламалася відразу; проблема проявилась після оновлення постачальника, який змінив порядок мережевих провайдерів. Класична затримана дія.

Машини фінансистів не могли встановити цю утиліту. Вони лишилися чистими. Коли інцидент стався, «нудний» автопарк став контрольної групою. Той самий Wi‑Fi, ті самі VLAN, ті самі AP — ніяких збоїв.

Оскільки був контрольний приклад, ми швидко ізолювали різницю: новий фільтруючий драйвер + зміна проксі. Видалили утиліту, скинули Winsock і стандартизували метрики VPN-адаптерів. Виправлення було простим, бо базова конфігурація була стабільною і зафіксованою.

Операційна моралі: жорсткий контроль змін на кінцевих точках — це не бюрократія, а спосіб зберегти відомо‑добрий стан, коли мережа веде себе дивно.

Одна операційна цитата (без прикрас)

Парафразована ідея (приписується): Gene Kim часто підкреслює, що надійні операції походять від швидкого зворотного зв’язку і малих, безпечних змін замість героїчних виправлень.

FAQ

1) Чому Windows каже «Немає інтернету, захищено», коли телефон працює на тому самому Wi‑Fi?

Ваш ноутбук може маршрутизувати через інший інтерфейс (VPN/віртуальний адаптер), використовувати зламаний проксі або мати проблеми з DHCP. Телефони зазвичай мають менше адаптерів і менше корпоративних хуків.

2) Чи варто використовувати кнопку «Network reset» в налаштуваннях Windows?

Лише після того, як ви спробували перепустити конкретний адаптер і перевірили маршрути/метрики. «Network reset» має великий радіус ураження: він видаляє/реінсталює адаптери, скидає багато налаштувань і може зламати профілі VPN.

3) Це зазвичай DNS?

Іноді. Але «Немає інтернету, захищено» так само часто пов’язане з маршрутом за замовчуванням або каптив-порталом. Розділіть проблему: протестуйте TCP до IP (Завдання 8) і DNS-розв’язання (Завдання 7). Потім приймайте рішення.

4) Який найшвидший доказ того, що використовується невірний адаптер?

route print. Якщо 0.0.0.0/0 вказує кудись дивно — ви знайшли причину. Потім перевірте метрики (Завдання 4), щоб зрозуміти, чому так сталося.

5) Чому відключення VPN‑адаптера виправляє Wi‑Fi?

Тому що VPN-адаптер може встановлювати маршрути або налаштування DNS, які переважають шлях Wi‑Fi. Вимкнення прибирає ці маршрути і змушує Windows використовувати шлюз Wi‑Fi.

6) Що означає IP 169.254.x.x?

APIPA: Windows не зміг отримати DHCP-ліз. Ви не «майже підключені». Ви локально відрізані. Виправляйте доступність DHCP і асоціацію.

7) Чи може IPv6 бути проблемою?

Так, особливо в мережах з поламаним upstream для IPv6. Але не відключайте IPv6 навмання як забобон. Спочатку доведіть, що маршрути/DNS IPv6 не працюють, поки IPv4 працює. Потім приймайте цілеспрямоване рішення.

8) Чому я бачу це лише на гостьовому Wi‑Fi або в готелях?

Каптивні портали, підміна DNS і блоковані перевірки. Мережа може вимагати веб-автентифікацію перед дозволом трафіку, і перевірки доступності Windows чутливі до такої поведінки.

9) Після `netsh winsock reset` чого очікувати?

Потрібне перезавантаження і, в деяких середовищах, VPN/засоби безпеки можуть вимагати відновлення або повторної реєстрації. Часто це виправляє зламану поведінку сокетів через фільтри/ LSP.

10) Коли підозрювати баг драйвера замість конфігурації?

Якщо проблема корелює зі сном/пробудженням, змінами докування або недавнім оновленням Windows/драйвера — і якщо перезапуск адаптера тимчасово вирішує проблему — драйвери і налаштування живлення піднімаються до верхнього пріоритету.

Висновок: наступні кроки, які ви справді виконаєте

«Немає інтернету, захищено» рідко містичне. Windows підключений до чогось, але шлях назовні неправильний або стек скомпрометований. Переможний хід — перестати трактувати Wi‑Fi як однорідне явище і почати думати про нього як про конвеєр: адаптер → IP → маршрути → DNS → проксі/фільтри.

Зробіть це далі, у порядку:

Запустіть route print і визначте, хто володіє 0.0.0.0/0.
Вимкніть невірного претендента (VPN/віртуальний) або виправте метрики, якщо потрібно.
Перезапустіть правильний адаптер (Wi‑Fi) і підтвердьте, що ви отримали реальний IP + шлюз.
Розділіть DNS і маршрути тестом TCP до IP і DNS-запитом.
Якщо стек «оповитий привидами», скиньте Winsock/TCP/IP — але робіть це усвідомлено — і перезавантажтеся один раз.

Будьте хірургічні. Збирайте докази перед тим, як натискати кнопки. Це не лише гарна інженерна практика; це спосіб уникнути «виправлення» ноутбука у ще дорожчу проблему.