Windows показує «Підключено, немає інтернету»? Виправте без скидання всього

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

Це порядок, який я використовую, коли хтось пише «інтернет не працює» і мені потрібна правда швидко. Шукаємо вузьке місце: канал, IP, маршрут, DNS, політика або власне виявлення Windows.

1) Мережа реально не працює, чи Windows просто скаржиться?

• Відкрийте браузер на відомому HTTPS-сайті. Якщо він завантажується, інтернет працює; статус Windows може бути хибним (часто NCSI/проксі/VPN).
• Спробуйте ping по IP (наприклад публічний DNS). Якщо IP працює, а імена — ні, то це DNS.

2) Підтвердіть, що у вас є IP, шлюз і адекватні маршрути

• Перевірте конфігурацію IP: чи є у вас не-APIPA адреса (не 169.254.x.x), шлюз за замовчуванням і DNS-сервери?
• Перегляньте таблицю маршрутів: чи є маршрут за замовчуванням (0.0.0.0/0) до правильного інтерфейсу?

3) Визначте, який шар ламається

• Немає IP / APIPA: проблема з DHCP або L2.
• Є IP, але немає маршруту за замовчуванням: проблема зі шлюзом/маршрутом, часто через метрики VPN, ICS або плутанину адаптерів.
• Є IP + маршрут, але DNS не працює: недоступні DNS-сервери, DoH/NRPT/політика або перехоплення captive portal.
• Все працює, крім статусу Windows: NCSI блокується або змінюється проксі, брандмауером чи політикою жорсткого захисту.

Не робіть «скидання всього», поки не зможете сказати, який із цих елементів не працює. Інакше ви просто додаєте ентропію. Ентропія завжди перемагає; у неї краще фінансування.

Що насправді означає «Підключено, немає інтернету»

Windows показує «Підключено, немає інтернету», коли вважає, що шлях до публічного інтернету зламаний. Це переконання частково базується на NCSI (Network Connectivity Status Indicator), компоненті, що виконує перевірки підключення.

Дві ключові думки, які зекономлять години:

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

Під капотом Windows пильнує за кількома шарами:

• Шари 1–2: стан каналу (асоціація Wi‑Fi, лінк Ethernet).
• Шар 3: IP-адреса, підмережа, шлюз за замовчуванням і маршрути.
• Шари 4–7: доступність DNS, HTTP/HTTPS доступ (включно з перевіркою captive portal), поведінка проксі.
• Політика і безпека: правила брандмауера, kill switch VPN, корпоративний endpoint security і «корисні» налаштування оптимізації.

Цитата, яку варто тримати в кишені, коли хочеться застосувати хаотичні виправлення: «Надія — це не стратегія.» — Gene Kranz

Жарт №1: мережа Windows — як комітет на зборі: у всіх є думка, але ніхто не говорить один з одним.

Цікаві факти та історичний контекст (чому це повторюється)

Короткі, конкретні факти, які роблять проблему «Підключено, немає інтернету» менш містичною і більш передбачуваною:

1. NCSI з’явився з мережею епохи Vista. Windows почала активно опитувати підключення до інтернету замість того, щоб довіряти лише стану лінку.
2. «No Internet, secured» зазвичай про безпеку Wi‑Fi, а не інтернету. Позначка «secured» вказує на шифрування Wi‑Fi (WPA2/WPA3), а не на придатність шляху в інтернет.
3. Captive portals навмисно ламають нормальну поведінку. Багато гостьових мереж перехоплюють DNS/HTTP, поки ви не погодитесь з умовами; сучасний HTTPS ускладнює ситуацію.
4. APIPA (169.254.0.0/16) — це запас Windows при збої DHCP. Він дозволяє локальне спілкування, але зазвичай означає відсутність шлюзу та інтернету.
5. WPAD автоматичне виявлення проксі — корпоративна класика і біль голови. Неправильний WPAD може ламати перегляд сторінок, хоча ping-и все ще працюють.
6. Kill switch VPN призначений викликати відключення. Його завдання — блокувати трафік, якщо тунель впав, і він часто виглядає як «немає інтернету».
7. Windows підтримує пер-інтерфейсні метрики для пріоритету маршрутів. «Швидший» інтерфейс або VPN може вкрасти маршрут за замовчуванням, коли не повинен.
8. Кешування DNS — і фішка продуктивності, і підсилювач помилок. Погані відповіді можуть триматися до закінчення TTL або поки ви не очистите кеш.
9. IPv6 часто звинувачують, часто помилково. Зламаний IPv6 може зашкодити, але відключення IPv6 — грубий хід, що може зламати сучасні корпоративні налаштування.

Практичні завдання з командами: що запускати, що означає, що робити далі

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

Завдання 1: Перевірити IP, шлюз і DNS за один крок

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

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection
   Physical Address. . . . . . . . . : 00-11-22-33-44-55
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.24.18.73(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1
   DHCP Server . . . . . . . . . . . : 10.24.16.10
   DNS Servers . . . . . . . . . . . : 10.24.0.53
                                       10.24.0.54

Що це означає: У вас є реальна IPv4-адреса, шлюз і DNS-сервери. Якщо інтернет все ще «відсутній», проблема, ймовірно, у маршрутизації, доступності DNS, проксі/VPN, брандмауері або NCSI.

Рішення: Якщо ви бачите 169.254.x.x або немає шлюзу за замовчуванням, переходьте до виправлень DHCP/L2. Якщо DNS-сервери порожні або дивні (наприклад, старий статичний IP), виправте це спочатку.

Завдання 2: Швидке виявлення APIPA (збій DHCP)

cr0x@server:~$ ipconfig
Windows IP Configuration

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . . : 169.254.77.12
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Що це означає: DHCP не видав адресу. Ви самопризначаєтесь. Це не «проблема інтернету», це проблема «я не потрапив у мережу».

Рішення: Перевірте кабель/автентифікацію Wi‑Fi/VLAN, потім оновіть оренду DHCP. Якщо це корпоративна мережа, підозрюйте 802.1X або профіль порту комутатора.

Завдання 3: Оновити оренду DHCP (без скидання всього)

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

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

Що це означає: Windows вважає інтерфейс відключеним (або кабель відсутній, або Wi‑Fi вимкнено). Це перший тип відмови: лінк.

Рішення: Виправте фізичний лінк / асоціацію Wi‑Fi перед тим, як робити щось хитріше.

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

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : corp.example
   IPv4 Address. . . . . . . . . . . : 10.24.18.73
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1

Що це означає: DHCP успішно видав адресу. Ви повернулися до рівня L3.

Рішення: Якщо інтернет усе ще не працює, переходьте до перевірок маршрутизації/DNS/проксі.

Завдання 4: Пропінгуйте шлюз за замовчуванням (локальна мережа жива?)

cr0x@server:~$ ping 10.24.16.1

Pinging 10.24.16.1 with 32 bytes of data:
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64

Ping statistics for 10.24.16.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss)

Що це означає: Хост досягає шлюзу. L2/L3 на локальному сегменті виглядає добре.

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

Завдання 5: Пропінгуйте зовнішній IP (обійдемо DNS)

cr0x@server:~$ ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)

Що це означає: Маршрутизація до інтернету працює принаймні для ICMP. Якщо вебсайти не відкриваються, ймовірно DNS, проксі, TLS-перехоплення або брандмауер.

Рішення: Негайно перевірте розв’язування DNS і HTTPS-доступ наступним кроком.

Завдання 6: Тест розв’язування DNS (просто і вирішально)

cr0x@server:~$ nslookup example.com
Server:  dns1.corp.example
Address:  10.24.0.53

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

Що це означає: DNS відповідає і повертає сенсовані дані.

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

cr0x@server:~$ nslookup example.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.

Що це означає: Мережа може блокувати публічні DNS (поширено в підприємствах і деяких ISP), або ви не можете дістатися до цього резолвера через правила маршрутизації/VPN.

Рішення: Не «виправляйте» шляхом жорсткого прописування публічного DNS у корпоративній мережі, якщо вам подобаються квитки в службу підтримки. Краще відновіть доступ до призначених DNS-серверів.

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

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.24.16.1     10.24.18.73     25
        10.24.16.0    255.255.252.0        On-link      10.24.18.73    281

Що це означає: У вас є маршрут за замовчуванням через ваш шлюз. Добре.

Рішення: Якщо маршрут 0.0.0.0 відсутній або вказує на інтерфейс VPN несподівано, ви знайшли причину.

Завдання 8: Перевірте, який інтерфейс Windows віддає перевагу (метрики мають значення)

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  12          5        1400  connected     CorpVPN
  10         25        1500  connected     Ethernet

Що це означає: Нижча метрика перемагає. Тут VPN має пріоритет і може викрадати маршрут за замовчуванням.

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

Завдання 9: Перевірте WinHTTP проксі (невидимий тип)

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

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

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

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

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

    Direct access (no proxy server).

Що це означає: Системний HTTP тепер йде напряму.

Рішення: Повторно протестуйте NCSI і проблеми з входом у Microsoft. Якщо корпоративна політика вимагає проксі, не «виправляйте» обхідним шляхом — отримайте правильну конфігурацію проксі.

Завдання 10: Перевірте проксі на рівні користувача (еквівалент Settings/Internet Options)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    ProxyEnable    REG_DWORD    0x1

Що це означає: Проксі для користувача увімкнено.

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

Завдання 11: Тест доступності HTTP без браузера (підказки про проксі/captive portal)

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty StatusCode"
200

Що це означає: Ви можете дістатися до HTTP-ендпойнту, який Windows часто використовує для перевірки підключення.

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

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty Content"
Microsoft Connect Test

Що це означає: Вміст відповіді правильний. Captive portals часто повертають HTML-сторінку входу.

Рішення: Якщо ви отримуєте HTML або редиректи, ви за captive portal. Авторизуйтеся (або запитайте у мережевої команди, чому «корпоративна» SSID має портал).

Завдання 12: Очистити кеш DNS (виправлення застарілих/поганих відповідей)

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

Successfully flushed the DNS Resolver Cache.

Що це означає: Будь-які кешовані DNS-відповіді очищені.

Рішення: Якщо розв’язування імен раптово запрацювало, ваша проблема була в застарілому кеші або тимчасовому DNS-помилкові (невинна неправильна конфігурація або captive portal). Якщо нічого не змінилося — продовжуйте пошук.

Завдання 13: Скинути Winsock (цільова «трубна» чистка TCP/IP)

cr0x@server:~$ netsh winsock show catalog
Catalog entry #0000000001
------------------------------------------------------------
Entry Type:  Provider
Description: MSAFD Tcpip [TCP/IP]
...output truncated...

Що це означає: Ви переглядаєте каталог Winsock (де LSP раніше підключалися). Програмне забезпечення безпеки іноді тут застрягає.

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

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

Що це означає: Winsock скинуто до значень за замовчуванням.

Рішення: Перезавантажте і повторно протестуйте. Якщо ваш корпоративний агент залежить від компоненту типу LSP, координуйте дії з IT перед виконанням на керованих машинах.

Завдання 14: Скидання TCP/IP стека (ще не «скидання всього»)

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

Що це означає: Ви скинули ключові параметри TCP/IP до стандартних.

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

Завдання 15: Перевірити, чи VPN створив постійні маршрути

cr0x@server:~$ route print -4
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.10.0.1     10.10.0.55      1
         10.10.0.0    255.255.0.0         On-link       10.10.0.55    261

Що це означає: Маршрут за замовчуванням вказує на шлюз 10.10.0.1 (ймовірно віртуальний адаптер VPN). Якщо VPN відключено, але маршрут лишився, ви швидко отримаєте «немає інтернету».

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

Завдання 16: Перевірте профіль і стан Windows Firewall

cr0x@server:~$ netsh advfirewall show allprofiles state

Domain Profile Settings:
State                                 ON

Private Profile Settings:
State                                 ON

Public Profile Settings:
State                                 ON

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

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

Завдання 17: Перевірте політику розв’язування і NRPT (поширено з VPN split DNS)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Format-Table -AutoSize"

Namespace          NameServers     DirectAccessDNS
---------          -----------     ---------------
.corp.example      {10.24.0.53}    False

Що це означає: Запити для певних просторів імен примусово направляються на конкретні DNS-сервери. Добре, коли правильно; катастрофа, коли VPN фактично не маршрутизує до цих серверів.

Рішення: Якщо NRPT вказує на недоступні DNS, ви отримаєте «деякі сайти працюють, деякі — ні». Виправте маршрутизацію VPN або оновіть політику; не виривайте NRPT, якщо ви не власник політики.

Завдання 18: Перевірити, які DNS-сервери фактично використовуються на кожному інтерфейсі

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias  ServerAddresses
--------------  ---------------
Ethernet        {10.24.0.53, 10.24.0.54}
CorpVPN         {10.99.0.10}

Що це означає: Різні адаптери можуть мати різні DNS-сервери. Windows може обрати «неправильний» DNS для загальних запитів залежно від метрик і політик.

Рішення: Якщо DNS VPN недоступний (тунель вниз), але переважний, ви відчуєте збої в іменах. Виправте пріоритет/метрики або відновіть тунель.

Captive portals і корпоративні дивності Wi‑Fi

Captive portals — класичний виробник повідомлення «Підключено, немає інтернету», бо вони стоять між вами і інтернетом і кажуть: «Так, ви можете підключитися… після того як ви натиснете цю галочку, написану юристом». Windows намагається виявити це і показати сторінку входу, але сучасні мережі і засоби безпеки можуть блокувати механізм.

Як розпізнати captive portal (без здогадок)

• DNS працює, але HTTP повертає несподіваний вміст. Ваш тест підключення повертає HTML замість очікуваного plain text.
• HTTPS-сайти не завантажуються з попередженнями про сертифікат або взагалі не завантажуються. Портали не можуть легко перехоплювати сучасний HTTPS без неприємних маніпуляцій.
• Лише деякі додатки відмовляють. Додатки зі строгим TLS pinning відмовляться від перехопленого трафіка.

Що робити

• Використайте простий HTTP URL (так, навмисно), щоби викликати портал і авторизуватись. Після цього поверніться до HTTPS як культурна людина.
• Тимчасово вимкніть VPN, якщо портал потребує розбалансованого трафіку. Багато VPN блокують потоки captive portal за задумом.
• Не прописуйте жорстко публічний DNS, щоб «виправити» портал. Деякі портали покладаються на інтерцепцію DNS; ви просто зробите ситуацію дивнішою.

VPN, проксі та «захисні» фічі, які відрізають вам ноги

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

Режими відмови VPN, що виглядають як «немає інтернету»

• Викрадення маршруту за замовчуванням: VPN стає пріоритетним маршрутом, але тунель фактично не передає трафік.
• Несумісність split tunnel DNS: DNS-запити йдуть на VPN DNS, але VPN не маршрутизує до нього (або DNS-сервер вас блокує).
• Kill switch увімкнено: клієнт VPN блокує весь трафік при відключенні тунелю. Це не баг; це функція з гострими краями.
• Застаріла політика NRPT: суфікси доменів примусово вирішуються на недоступні сервери, що ламає внутрішні додатки і іноді вхід Windows.

Режими відмови проксі, що виглядають як «немає інтернету»

• WinHTTP проксі лишився після видалення засобу безпеки, і системні сервіси не можуть дістатися вебу.
• Проксі користувача увімкнено з невірним PAC-файлом або мертвим іменем хоста проксі.
• Auto-detect (WPAD) знайшов проксі в одній мережі, а потім продовжує використовувати його в іншій, де він не існує.

Жарт №2: проксі-сервер — як той колега, що наполягає бути в копії листа — поки не піде у відпустку і ваша пошта перестане працювати.

Драйвери, енергозбереження і тиха жорстокість «оптимізації»

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

Шаблони відмов, що кричать «драйвер/енергія»

• Інтернет відмирає після пробудження зі сну, але перезавантаження вирішує проблему.
• Ethernet показує підключено, але трафік не йде, поки ви не вимкнете/увімкнете адаптер.
• Wi‑Fi підключається, а потім падає до «немає інтернету», хоча сигнал сильний.

Що робити (і чого уникати)

• Краще відкатати до відомого робочого драйвера, якщо проблема почалася після оновлення. Нове не завжди краще; іноді воно просто новіше.
• Уникайте відключення IPv6 як першого кроку. Це може приховати симптом і зламати корпоративні сервіси, сучасну поведінку DNS і подальше налагодження.
• Перевірте налаштування енергозбереження адаптера, якщо проблема пов’язана зі сном. Якщо ваш корпоративний образ нав’язує ці налаштування через політику, виправляйте централізовано.

Три корпоративні короткі історії з поля бою

1) Інцидент через хибне припущення: «Якщо DHCP працює, інтернет працює»

У середній компанії була повторювана скарга: кожні кілька днів випадкова площадка повідомляла «Підключено, немає інтернету». Скрипт служби підтримки був передбачуваний: перезапустити точку доступу, перезавантажити користувача і рухатись далі. Це «працювало», тобто ніхто нічого не вивчив.

Коли SRE підключились, перше припущення, яке вони оскаржили — класичне: успішний DHCP означає працездатну мережу. Користувачі дійсно мали адреси, шлюзи і DNS. Пінги шлюзу проходили. Зовнішні IP пінги працювали. DNS теж відповідав. Але браузери відмовлялися працювати.

Відсутній шматок: корпоративний проксі був обов’язковим для виходу в веб, і проксі покладався на PAC-файл, що обслуговувався внутрішнім хостом. Це ім’я розв’язувалось, але порт проксі був періодично заблокований неправильно застосованою ACL на одному комутаторі. Тож мережа «працювала», інтернет «працював», але веб — ні — і Windows інтерпретував це як «немає інтернету».

Виправлення не було грандіозним. Воно було нудним: вирівняти ACL по комутаторах, моніторити доступність порту проксі і навчити підтримку тестувати доступність проксі, а не лише ping. Хибне припущення перетворило просту політичну помилку на місяці «примарних відключень».

2) Оптимізація, що зіграла злий жарт: «Давайте примусово поставимо публічний DNS для швидшого розв’язування»

IT-команда втомилась від скарг на внутрішній DNS затримки. Хтось запропонував просту оптимізацію: через GPO надіслати клієнтам DNS відомого публічного резолвера «для продуктивності». Це було розгорнуто тихо — бо кому потрібен change management для DNS, правда?

За день Windows-ноутбуки почали повідомляти «Підключено, немає інтернету» в офісі — в той час як деякі сайти завантажувалися, а внутрішні додатки ні. Картина була хаотична: нові співробітники були в порядку, старі — ні, а користувачі VPN страждали найбільше.

Реальність: корпоративний брандмауер блокує вихідний DNS в інтернеті як політику. Клієнти, примушені до публічних DNS, нічого не могли розв’язати, якщо не були в мережі з дозволом. Тим часом внутрішні зони, доступні лише через корпоративний DNS, перестали розв’язуватись, що ламає входи, друк і внутрішні портали. Перевірка підключення Windows теж провалювалась через непослідовне розв’язування і HTTP-доступ.

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

3) Нудна, але правильна практика, що врятувала ситуацію: відомі базові налаштування і два тести

Глобальна організація мала невелику, але дисципліновану мережеву практику: в кожному офісі був задокументований «відомо-робочий» конфігураційний зразок для Ethernet і Wi‑Fi, плюс два стандартні тести: (1) пінг шлюзу, (2) розв’язати і завантажити файл перевірки підключення через HTTP. Вони не були гарними, але були послідовними.

Одного ранку сайт повідомив «Підключено, немає інтернету» у кількох командах. Люди почали звинувачувати провайдера, потім оновлення Windows, потім кавоварку (несправедливо). Інженер на виклику попросив виконати два тести. Пінг шлюзу пройшов. HTTP-завантаження повернуло HTML-сторінку замість очікуваного тексту.

Це відразу звузило коло: captive portal або перехоплення. Офіс не використовував портал. Виявилось, що вночі була застосована нова політика безпекового пристрою, що перенаправляла невідомі user-agent на сторінку автентифікації. Проба NCSI тепер вважалася «невідомою» і отримувала редирект, тож Windows оголосив «немає інтернету». Деякі браузери працювали, бо вони інакше реагують на запит авторизації; деякі додатки відмовляли, бо чекали чистого HTTP-відповіді.

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

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

Це повторювані провини. Читайте їх як польовий довідник.

1) «Підключено, немає інтернету», але сайти відкриваються

• Симптом: Браузер працює; трей Windows каже немає інтернету; деякі Microsoft-додатки скаржаться.
• Корінь: NCSI блоковано або перенаправлено проксі, брандмауером, фільтрацією DNS або невдалою перевіркою captive portal.
• Виправлення: Протестуйте файл перевірки підключення через PowerShell. Перевірте WinHTTP проксі. Якщо корпоративна мережа — попросіть додати в allowlist кінцеві точки NCSI і налаштувати проксі правильно.

2) IP-адреса 169.254.x.x

• Симптом: Локальне з’єднання показує підключено; інтернет немає; іноді «Unidentified network».
• Корінь: Збій DHCP (немає відповіді, блокується, невірний VLAN, помилка 802.1X).
• Виправлення: Оновіть оренду DHCP; перевірте лінк; спробуйте інший порт/SSID; в корпоративній мережі перевірте профіль порту комутатора і логи автентифікації.

3) Ping до 1.1.1.1 працює, але DNS не працює

• Симптом: IP-зв’язок є; nslookup таймаут.
• Корінь: DNS-сервер недоступний, блокування вихідного DNS, встановлено неправильний DNS, або вибір DNS VPN при відсутньому тунелі.
• Виправлення: Перевірте ipconfig /all і Get-DnsClientServerAddress. Встановіть правильний DNS, який очікує мережа; виправте маршрути/метрики VPN.

4) Лише внутрішні сайти не працюють, публічний інтернет — так

• Симптом: Google відкривається; внутрішній портал — ні; VPN іноді задіяний.
• Корінь: Split DNS/NRPT неправильний, або внутрішній DNS доступний лише через VPN.
• Виправлення: Підключіть VPN коректно; перевірте NRPT-політики і доступність DNS; не «виправляйте» шляхом використання публічного DNS.

5) Інтернет вмирає після сну/гібернації

• Симптом: Працює після перезавантаження; не працює після пробудження; допомагає вимкнення/увімкнення адаптера.
• Корінь: Баг драйвера або енергозбереження адаптера, іноді ускладнено станом VPN-сервісу.
• Виправлення: Оновіть або відкатайте драйвер; вимкніть агресивне енергозбереження адаптера; переконайтесь, що клієнт VPN коректно обробляє відновлення.

6) «Немає інтернету» з’являється лише після встановлення VPN (навіть коли він відключений)

• Симптом: Видалення VPN «вирішує» проблему; інакше маршрути плутаються.
• Корінь: Постійні маршрути, фільтруючі драйвери або активний kill switch.
• Виправлення: Перегляньте таблицю маршрутів і метрики інтерфейсів; відновіть або перевстановіть клієнт VPN чисто; ескалюйте, якщо політика kill switch примусова.

7) Ethernet показує підключено, але трафіку немає

• Симптом: Світлодіоди лінку горять; пінг шлюзу не проходить; DHCP може бути або ні.
• Корінь: Неправильний VLAN на порту комутатора, безпека порту, помилка 802.1X або проблеми узгодження драйвера.
• Виправлення: Спробуйте інший порт/кабель; в корпоративній мережі перевірте автентифікацію портів і призначення VLAN; розгляньте примусову швидкість/дуплекс тільки в крайньому випадку.

8) Вимкнення IPv6 «працює», але проблема повертається

• Симптом: Вимкнення IPv6 тимчасово допомагає.
• Корінь: Неправильна IPv6 маршрутизація/DNS на мережі або проблеми RA. Вимикання IPv6 просто змушує використовувати IPv4 і приховує реальну проблему.
• Виправлення: Виправте конфігурацію IPv6 у мережі (router advertisements, AAAA/DNS, брандмауер). На окремій кінцевій точці віддайте перевагу виправленню DNS/шлюзу перед відключенням протоколу.

Чеклісти / покроковий план (без «ядерного» скидання)

Ось план, який я передав би компетентному адміну або впертому просунутому користувачу. Він ескалює обережно.

Чекліст A: Перевірте базові речі (2–5 хвилин)

1. Підтвердіть, що ви підключені до потрібного SSID або Ethernet-порту (не гостевого VLAN).
2. Запустіть ipconfig /all. Зафіксуйте: IPv4-адреса, шлюз за замовчуванням, DNS-сервери.
3. Пропінгуйте шлюз за замовчуванням.
4. Пропінгуйте публічний IP (наприклад: 1.1.1.1).
5. Запустіть nslookup example.com.

Критична точка рішення:

• Якщо DHCP не працює (APIPA), зупиніться і виправте DHCP/L2/802.1X.
• Якщо IP є, але DNS не працює — виправте DNS або вибір DNS VPN.
• Якщо DNS працює, але веб/додатки падають — перевірте проксі/VPN/брандмауер/captive portal.

Чекліст B: Ловіть звичні підозрювані (5–10 хвилин)

1. Перевірте WinHTTP проксі: netsh winhttp show proxy. Скиньте, якщо неправильний.
2. Перевірте проксі користувача через реєстр (або Налаштування): підтвердьте, що ProxyEnable має сенс.
3. Перевірте метрики інтерфейсів: netsh interface ipv4 show interfaces.
4. Огляньте таблицю маршрутів: route print на предмет сюрпризів з маршрутом за замовчуванням.
5. Протестуйте пробу підключення Windows через PowerShell Invoke-WebRequest до файлу connect test.

Чекліст C: Ремонт стека (10–20 хвилин, контрольовані зміни)

1. Очистіть DNS: ipconfig /flushdns.
2. Відпустіть/оновіть оренду: ipconfig /release, потім ipconfig /renew.
3. Скиньте Winsock: netsh winsock reset (перезавантаження).
4. Скиньте IP стек: netsh int ip reset (перезавантаження).

Критична точка рішення: Якщо це не допомогло, проблема, ймовірно, зовнішня (політика мережі, бекенд VPN, проксі, брандмауер, captive portal, баг драйвера). Не продовжуйте хаотично «рандомізувати» кінцеву точку.

Чекліст D: Драйвери й енергетична санітарія (залежить від випадку)

1. Якщо проблема почалась після оновлення драйвера — відкачайте драйвер назад.
2. Якщо проблема пов’язана зі сном — налаштуйте параметри енергозбереження адаптера.
3. Якщо використовується USB Ethernet-адаптер/док — спробуйте інший порт або прямий Ethernet; доки можуть бути «маленькими маршрутизаторами з почуттями».

Питання та відповіді

1) Чому Windows каже «Немає інтернету», коли я можу серфити?

Тому що Windows виконує механізм перевірки підключення (NCSI), який може бути заблокований або перенаправлений. Перегляд може працювати через кеш DNS, іншу поведінку проксі або додатки, що використовують інші шляхи.

2) Який найшвидший спосіб зрозуміти, чи це DNS?

Пропінгуйте публічний IP (тест маршруту), потім запустіть nslookup example.com (тест DNS). IP працює + DNS не працює = проблема DNS або недоступність DNS.

3) Чи «Скидання мережі» — хороший спосіб?

Іноді. Але це руйнівно: видаляє збережені мережі, адаптери VPN/профілі, кастомні DNS/маршрути і може зламати корпоративну автентифікацію. Спочатку використовуйте цілеспрямовані скидання (winsock, int ip).

4) Чи варто вимикати IPv6?

Не як перший крок. Неправильний IPv6 у мережі може робити справжні проблеми, але відключення IPv6 на клієнті часто ховає основну помилку і може зламати корпоративні та сучасні функції Windows.

5) Чому проблема трапляється лише в корпоративному Wi‑Fi, а вдома ні?

Корпоративні мережі зазвичай застосовують проксі, блокують публічний DNS, вимагають 802.1X і накладають перевірки стану endpoint. Домашня мережа — це по суті дружнє анархічне середовище у порівнянні.

6) Чому Microsoft-додатки (Store, OneDrive, Teams) падають, коли браузер працює?

Системні компоненти часто використовують WinHTTP проксі і інші TLS/проксі шляхи, відмінні від браузера. Неправильне WinHTTP проксі може ламати їх, поки Chrome/Edge продовжують працювати через власні налаштування.

7) Я підключений до VPN. Чому втрачаю інтернет, коли VPN падає?

Зазвичай це kill switch або політика маршрутизації: коли тунель падає, клієнт блокує трафік, щоб запобігти витокам. Виправлення — змінити політику VPN, а не «виправляти» Windows.

8) Як дізнатися, чи captive portal — причина?

Завантажте відомий plain HTTP файл і перевірте вміст. Якщо отримуєте HTML-сторінку входу або редирект замість очікуваного тексту — ви за captive portal.

9) Чому перезавантаження іноді «вирішує»?

Перезавантаження очищає транзіторний стан: застарілі маршрути, завислі VPN-сервіси, поганий стан драйвера після сну і кеш DNS. Це не лікування; це скидання стану, що може приховати реальну причину.

10) Коли слід ескалювати до IT/мереж не продовжувати самостійно?

Ескалюйте, якщо у вас є валідна IP-адреса, ви можете дістатися шлюзу, але проксі/VPN-політики або поведінка брандмауера виглядають як блокуючі фактори — особливо на керованих машинах. Кінцеве «поколювання» не вирішить центральну політику.

Висновок: наступні кроки, що не зіпсують ваш день

«Підключено, немає інтернету» — це або (a) ви справді не можете дістатися інтернету, або (b) Windows не може довести, що ви можете. Виправлення — це перестати трактувати це як містичне прокляття ОС і почати розглядати як багатошарову систему.

Зробіть наступне в такому порядку:

1. Запустіть ipconfig /all і підтвердіть: реальна IP-адреса, шлюз за замовчуванням, DNS-сервери.
2. Пропінгуйте шлюз, потім пропінгуйте публічний IP, потім запустіть nslookup домену.
3. Якщо веб/додатки поводяться непослідовно, перевірте проксі (WinHTTP + проксі користувача) і поведінку маршруту/метрики VPN.
4. Якщо підозрюєте корупцію стека, використайте netsh winsock reset і netsh int ip reset — і перезавантажте — перед тим, як робити «скидання мережі».
5. Якщо це корпоративна мережа і дані вказують на політику (блок проксі, обмеження DNS, kill switch VPN), ескалюйте з відповідними даними: результати команд і чіткий опис шару, що відмовляє.

Мета не в тому, щоб зробити іконку щасливою. Мета — відновити надійне підключення без видалення половини конфігурації і надії на прихильність всесвіту.