Додатки випадково втрачають інтернет: пояснення виправлення Winsock

February 24, 2026 • February 24, 2026 • Читання: 5 хв • Views: 1

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

Ваш ноутбук показує, що Wi‑Fi підключено. Teams перепідключається, наче готується до марафону. Браузер крутиться, потім заявляє, що інтернет «недоступний», а ping працює, і ваш колега в тій самій мережі — нормально. Ви перезавантажуєтеся, усе лікується. Потім це повторюється — зазвичай перед презентацією.

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

Що таке Winsock насправді (а чим він не є)

Winsock (Windows Sockets) — це API та підсистема, якою додатки користуються для роботи з TCP/UDP у Windows. Ваш браузер не «робить мережу» сам, формуючи Ethernet-фрейми; він викликає функції Winsock, а ОС уже обробляє решту: резолюцію імен, маршрутизацію, встановлення з’єднань, опції сокетів та взаємодію з мережевими драйверами.

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

Winsock reset виправляє певну категорію проблем: корупцію або поганий стан у каталозі Winsock, часто спричинену Layered Service Providers (LSP) або суміжними мережевими провайдерами, які встановлюють VPN, антивіруси, шейпери трафіку, батьківський контроль, блокувальники реклами або агенти захисту даних у корпоративних середовищах.

Winsock reset не виправляє все. Якщо драйвер мережевого інтерфейсу падає, Wi‑Fi погано роумить або маршрутизатор плавиться, скидання Winsock — це як поміняти двірники, щоб виправити детонацію двигуна. Ви відчуєте себе продуктивним, але не будите праві.

Цікаві факти та історичний контекст (бо минуле продовжує ламати сучасність)

Факт 1: Winsock 1.1 з’явився на початку 1990-х, щоб стандартизувати програмування сокетів у Windows; Winsock 2 додав сучасні можливості (як-от кращу розширюваність і overlapped I/O).
Факт 2: LSP широко використовувалися в еру Windows XP для антивірусів і «захисту вебу», а також зловживалися adware. Ця спадщина ще має значення.
Факт 3: «Каталог Winsock» — це список провайдерів в реєстрі і їхній порядок. Коли порядок ламається, додатки можуть виходити з ладу дивно вибірково.
Факт 4: Резолюція імен у Windows — це не лише DNS; це ланцюжок (hosts-файл, кеш DNS-клієнта, multicast, NetBIOS у деяких середовищах), і різні додатки потрапляють на різні шляхи.
Факт 5: Багато повідомлень «інтернет не працює» насправді — це TLS-помилки: зсув часу, перехоплені сертифікати або поломаний SChannel — сучасні додатки трактують «не вдалось встановити handshake» як «немає інтернету».
Факт 6: Налаштування HTTP-проксі можуть бути на рівні користувача й на рівні системи; WinHTTP і WinINET — різні стекі проксі. Тому браузер може працювати, а сервіс — ні (або навпаки).
Факт 7: У Windows кілька шарів брандмауера: політика Windows Defender Firewall, виклики WFP (Windows Filtering Platform) і сторонні фільтри. «Вимкнено» в інтерфейсі не завжди означає «не фільтрується».
Факт 8: «Скидання TCP/IP» і «скидання Winsock» — це різні операції; одна торкається параметрів інтерфейсу й стека, інша — стану каталогу провайдерів сокетів.

Чому лише деякі додатки падають: режими відмов, що виглядають як хаос

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

1) DNS виглядає нормально, але з’єднання падають

Ви можете резолвити імена, але TCP-з’єднання тайм-аутяться або скидаються. Це вказує на фільтрацію (брандмауер/WFP), проблеми MTU/PMTUD або зламаний ланцюжок мережевих провайдерів. Якщо падають лише певні порти — підозрюйте політику або інспекцію. Якщо лише певні призначення — особливо через VPN — підозрюйте маршрут/MTU.

2) Ping працює, але браузер каже «Немає інтернету»

Ping — це ICMP. Браузери використовують TCP+TLS+HTTP. У корпоративних мережах ICMP може бути дозволено, тоді як TLS-інспекція не працює або проксі неправильно налаштовано. Або ви можете досягати IP, але DNS/проксі/TLS-handshake зламані. Ping — це ковдра комфорту, а не перевірка здоров’я.

3) Браузер працює, але «додатки» відмовляють (Outlook, Teams, store apps)

Різні API-стекі. Браузери часто використовують WinINET із власною логікою проксі; сервіси й системні компоненти часто використовують WinHTTP. Якщо WinHTTP-проксі неправильний, фонові сервіси помирають, а браузер щасливо спілкується.

4) Все відпадає після відключення VPN

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

5) Працює кілька хвилин, потім падає на кілька хвилин

Така періодичність кричить «оновлення оренди», «роумінг», «енергозбереження» або «хтось щось сканує». Windows буде вимикати NIC для економії. Засоби безпеки перехоплюватимуть потоки. DHCP-оновлення та captive portal можуть перетягувати маршрути. Шукайте стан із таймерами.

Цитата, яку варто тримати на стіні, від Річарда Кука (часто парафраз у колах надійності): успіх у експлуатації будується на безлічі дрібних підганянь, а не на одному великому проєкті. Ось мережі Windows: працює, бо десяток підсистем зазвичай співпрацюють. Коли одна перестає — з’являються історії-привиди.

Жарт 1: Інтернет не впав. Він просто взяв особистий день і не сказав вашим сокетам.

Що змінює «Winsock reset» під капотом

Коли ви виконуєте:

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

Ви кажете Windows перебудувати каталог Winsock назад до відомого доброго базового стану. Цей базовий стан включає стандартні провайдери сокетів (зазвичай MSAFD Tcpip [TCP/UDP over IPv4/IPv6]) і видаляє сторонні LSP-записи з ланцюга (або принаймні видаляє реєстрацію в реєстрі, що вказує на них).

У старіші ери Windows це було звичним виправленням для malware, яке вставляло себе як LSP. Сьогодні це так само релевантно — тільки «malware» часто виявляється легітимним корпоративним агентом із невдалим оновленням.

Що воно впливає:

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

Що воно безпосередньо не виправляє:

Зламані драйвери NIC, ненадійний Wi‑Fi або погані порти комутатора.
Неправильні маршрути, невірні шлюзи або помилки split-tunnel VPN.
Проблеми з TLS-інспекцією/довірою сертифікатів.
Налаштування проксі у WinHTTP/WinINET (хоча деякі «повні» рецепти скидають проксі окремо).

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

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

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

Перший: доведіть базовий шлях (канал, IP, маршрут)

Перевірте, чи є валідна IP-адреса, шлюз і DNS-сервери.
Перевірте маршрут до 0.0.0.0/0 та ::/0 — чи виглядає він адекватно (особливо після підключення/відключення VPN).
Перевірте, чи проблема лише з IPv6 або лише з IPv4.

Другий: розділіть DNS і підключення

Розв’яжіть ім’я в IP.
Підключіться до IP на відомому порту (443), не покладаючись на DNS, якщо потрібно.
Якщо DNS резолвиться, але TCP-підключення падає — перестаньте звинувачувати DNS.

Третій: визначте перехоплення (проксі, брандмауер, агент безпеки, LSP/WFP)

Перевірте WinHTTP-проксі та користувацькі налаштування проксі.
Перевірте профіль брандмауера Windows і останні події блокування.
Перевірте, чи встановлено стек VPN/засіб безпеки і чи був він нещодавно оновлений.
Якщо симптоми — «вибіркові додатки», «після VPN» або «після оновлення безпеки», Winsock/WFP/ланцюжок провайдерів — головний підозрюваний.

Якщо ви пройдете ці три кроки, ви майже завжди зійдетеся на одному з: (a) маршрутизація, (b) DNS/проксі, (c) фільтрація/перехоплення, (d) ненадійний канал.

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

Ці завдання розраховані на виконання в терміналі Windows з підвищеними правами (PowerShell/CMD). Я показую їх у блоках коду з реалістичним виводом. Ваше завдання — читати вивід і приймати рішення, а не збирати скріншоти як Покемонів.

Завдання 1: Підтвердіть стан інтерфейсу та IP-конфіг

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

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection
   Physical Address. . . . . . . . . : 3C-52-82-11-22-33
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.42.18.57(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, February 5, 2026 9:10:01 AM
   Lease Expires . . . . . . . . . . : Monday, February 5, 2026 5:10:01 PM
   Default Gateway . . . . . . . . . : 10.42.18.1
   DNS Servers . . . . . . . . . . . : 10.42.0.10
                                       10.42.0.11

Що це означає: У вас є валідна DHCP-оренда, шлюз і DNS. Якщо ви бачите 169.254.x.x — DHCP не вдалося; якщо шлюз пустий — ви не маршрутуєте за межі підмережі.

Рішення: Якщо IP/шлюз/DNS відсутні або неправильні — виправте спочатку це (DHCP, VLAN, Wi‑Fi). Не чіпайте Winsock поки.

Завдання 2: Перевірте таблицю маршрутизації для маршрутів за замовчуванням (IPv4/IPv6)

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.42.18.1     10.42.18.57     25
       10.42.18.0    255.255.255.0         On-link     10.42.18.57    281
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
::/0                     fe80::1           On-link      25

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

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

Завдання 3: Явно перевірте резолюцію DNS

cr0x@server:~$ nslookup www.microsoft.com
Server:  dns01.corp.example
Address:  10.42.0.10

Non-authoritative answer:
Name:    www.microsoft.com
Addresses:  13.107.246.45
           13.107.213.45

Що це означає: DNS відповідає і повертає A-записи. Якщо це тайм-аутиться — у вас проблема досяжності DNS або блокування UDP/TCP 53.

Рішення: Якщо DNS падає — перевірте сервери DNS, правила брандмауера або captive portal. Не звинувачуйте Winsock, поки DNS не стабільно відповідає.

Завдання 4: Обійдіть DNS і перевірте TCP 443 на IP

cr0x@server:~$ powershell -Command "Test-NetConnection 13.107.246.45 -Port 443"
ComputerName     : 13.107.246.45
RemoteAddress    : 13.107.246.45
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 10.42.18.57
TcpTestSucceeded : True

Що це означає: Транспортне підключення до 443 працює. Якщо DNS працює, але це падає — дивіться на маршрути/MTU/брандмауер/перехоплення.

Рішення: Якщо TcpTestSucceeded — False, переходьте до перевірок брандмауера/WFP і підозри на MTU/VPN.

Завдання 5: Перевірте, чи IPv6 — джерело проблем

cr0x@server:~$ powershell -Command "Test-NetConnection www.microsoft.com -Port 443"
ComputerName     : www.microsoft.com
RemoteAddress    : 2603:1020:201:10::10f
InterfaceAlias   : Ethernet
SourceAddress    : 2001:db8:42:18::57
TcpTestSucceeded : False

Що це означає: DNS повернув IPv6-адресу першим; шлях IPv6 не працює. Багато додатків віддають перевагу IPv6 і поводяться «випадково», якщо IPv6 частково зламаний.

Рішення: Виправте маршрутизацію/RA/DHCPv6 або тимчасово відключіть IPv6 для діагностики. Довгостроково частковий IPv6 гірший, ніж його відсутність.

Завдання 6: Перевірте WinHTTP-проксі (часта причина «додатки падають, браузер працює»)

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

    Proxy Server(s) : http=proxy.corp.example:8080;https=proxy.corp.example:8080
    Bypass List     : (none)

Що це означає: Системні служби й багато корпоративних додатків використовуватимуть цей проксі. Якщо він вказує на мертвий проксі або неправильний PAC — фонове підключення помре.

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

Завдання 7: Скиньте WinHTTP-проксі в режим direct (діагностично)

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

    Direct access (no proxy server).

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

Рішення: Або вирішіть досяжність проксі (VPN, DNS, маршрути), або відновіть правильні налаштування через політику/PAC.

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

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

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

Рішення: Якщо проксі не повинен використовуватися — відключіть його. Якщо повинен — переконайтеся, що PAC/хост/порт правильні.

Завдання 9: ЗлDump каталогу Winsock, щоб помітити сторонні провайдери

cr0x@server:~$ netsh winsock show catalog
Catalog Entries:
------------------------------------
Entry #0000000001
-----------------
Service Provider : MSAFD Tcpip [TCP/IP]
Provider Path    : %SystemRoot%\system32\mswsock.dll

Entry #0000000009
-----------------
Service Provider : Contoso Security LSP
Provider Path    : C:\Program Files\Contoso\NetFilter\contosolsp.dll

Що це означає: Існують сторонні провайдери. Якщо DLL відсутня, несумісна або зламана — додатки падатимуть неочевидними способами.

Рішення: Якщо ви бачите провайдери від деінстальованих VPN/AV, плануйте скидання Winsock (і, ймовірно, перевстановлення/очищення проблемного продукту).

Завдання 10: Виконайте скидання Winsock (і погодьтеся на перезавантаження)

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

Що це означає: Скидання каталогу поставлено в чергу; потрібне перезавантаження для повного застосування.

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

Завдання 11: Скиньте параметри 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, пов’язані з інтерфейсом, а не провайдери Winsock. Корисно після дивної поведінки VPN/драйверів або ручних налаштувань.

Рішення: Використовуйте це, коли спостерігаєте дивну маршрутизацію/поведінку інтерфейсу (шлюз/MTU/кеш сусідів). Також потребує перезавантаження.

Завдання 12: Очистіть кеш DNS клієнта (низький ризик, іноді вирішує)

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

Successfully flushed the DNS Resolver Cache.

Що це означає: Кешовані DNS-записи видалені. Корисно, коли змінюється split-DNS (VPN on/off) і кеш зберігає застарілі відповіді.

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

Завдання 13: Перевірте профіль брандмауера та стан

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

Private Profile Settings:
----------------------------------------------------------------------
State                                 ON

Public Profile Settings:
----------------------------------------------------------------------
State                                 ON

Що це означає: Брандмауер увімкнений для всіх профілів. Це нормально. Питання — чи політика блокує вихідні з’єднання або примушує інспекцію.

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

Завдання 14: Визначте, чи NCSI брешуть щодо підключення до інтернету

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet
    EnableActiveProbing    REG_DWORD    0x1

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

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

Завдання 15: Швидка перевірка MTU (симптом: TLS зависає, деякі сайти падають)

cr0x@server:~$ ping -f -l 1472 8.8.8.8
Pinging 8.8.8.8 with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss)

Що це означає: Path MTU менший за 1500 (1472 корисне навантаження + 28 заголовків). VPN і тунелі часто зменшують MTU; зламаний PMTUD може робити великі пакети чорними дірками.

Рішення: Якщо це відбувається — зменшіть MTU інтерфейсу або виправте PMTUD/фільтрацію ICMP на шляху. Скидання Winsock цього не торкається.

Жарт 2: Якщо ваш «оптимізатор мережі» обіцяє інтернет у 300% разів швидший, він зазвичай оптимізує час, який ви витрачаєте на перезавантаження.

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

Міні-історія 1: Інцидент через неправильне припущення

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

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

Справжня проблема: інсталятор VPN додав конфігурацію WinHTTP-проксі, призначену для використання лише в мережі компанії. Але він не видаляв або не обходив її при відключенні. Користувачі поза офісом опинилися з системними компонентами, що намагалися проксувати через недосяжний хост. Трафік браузера не завжди йшов цим шляхом, тому браузер залишався «в порядку», що підсилювало неправильне припущення.

Виправлення було нудним: скинути WinHTTP-проксі в direct для користувачів поза мережею й виправити політику VPN, щоб налаштування встановлювалися й очищалися належним чином. Також написали односторінковий runbook: «Браузер працює, додатки падають: перевірте WinHTTP-проксі». Кількість заявок упала швидко.

Міні-історія 2: Оптимізація, що підвела

Команда безпеки розгорнула модуль інспекції трафіку, щоб ловити ексфільтрацію. Він вставився в мережевий стек, бо трафік там. Розгортання було фазованим, і ранні користувачі казали, що нічого не змінилось. Потім прийшов «patch Tuesday».

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

«Оптимізація» була налаштуванням продуктивності: модуль інспекції ввімкнув агресивний pooling з’єднань і змінив поведінку деяких сокетів, щоб зменшити накладні витрати. За певних таймінгів — сон/пробудження і швидкі мережеві зміни — ланцюжок провайдерів опинявся в поганому стані, через що виклики connect() зависали до тайм-ауту. Це виглядало як «інтернет упав», але насправді це була затримка створення сокета та оцінки політик.

Winsock reset тимчасово виправляв уражені машини, перебудовуючи каталог і очищуючи стан ланцюжка провайдерів, що легко дозволяло хибно діагностувати «Windows нестабільний». Справжнє виправлення — патч для модуля і зміна практики розгортання: ніяких «мовчазних драйверних оптимізацій» без поетапного відкату і явних health-check для сну/пробудження і переходів VPN.

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

Інша організація працювала дисципліновано. Не ідеально, але дисципліновано. Вони мали стандартний скрипт «network sanity bundle», який збирав: IP-конфіг, маршрути, тести DNS-резолюції, стан проксі і дамп каталогу Winsock. Кожного разу, коли користувач скаржився на переривчасте підключення, вони запускали той самий бандл перед будь-якими скиданнями.

Одного тижня прийшла хвиля заявок: «Внутрішній додаток не може дістатися API, але інтернет працює». Бандл показав послідовний натяк: маршрут за замовчуванням правильний, DNS правильний, але TCP 443 до внутрішнього балансувальника відмовляв лише коли переважав IPv6. Маршрут IPv6 існував, але шлях був зламаний за першим хопом. Додатки, що використовували IPv4, продовжували працювати; ті, що віддавали перевагу IPv6, падали «випадково».

Оскільки у них були еталонні виводи з робочих машин, вони швидко порівняли й передали мережній команді докази. Коренева причина була в неправильно налаштованій рекламній маршрутизації (router advertisement) на сегменті, яка оголошувала IPv6-ідентичність без реальної маршрутизації до ЦОДу. Виправлення було на мережевому боці, а не на кінцевих пристроях.

Нудна практика — збирати перед скиданням — врятувала їх від масового «Winsock fix», який би нічого не змінив. Це також позбавило мережну команду від класичної непродуктивної заявки: «інтернет зламався, полагодьте». Вони отримали точне: «IPv6 default route присутній; TCP 443 падає тільки по IPv6; ось traceroute і інтерфейс». Так вирішують проблеми швидко у корпоративному житті.

Типові помилки: симптом → корінь проблеми → виправлення

Це секція, де ви припиняєте виконувати інтерпретативний танець з мережевим стеком.

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

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

Виправлення: Дозвольте механізм опитування через корпоративні контролі або налаштуйте політику відповідно. Не «виправляйте» це відключенням NCSI, якщо не хочете порушити поведінку VPN і довіру користувачів.

2) Симптом: Браузер працює, Teams/Outlook/store apps падають

Корінь проблеми: WinHTTP-проксі неправильно налаштований або недосяжний; WinINET (браузер) використовує інший шлях проксі.

Виправлення: netsh winhttp show proxy, скиньте/імпортуйте правильний проксі, переконайтеся, що VPN встановлює та знімає проксі послідовно.

3) Симптом: DNS резолвиться, але TCP-підключення тайм-аутиться по багатьох сайтах

Корінь проблеми: Блокування вихідних з’єднань через брандмауер/WFP або маршрут за замовчуванням вказує на застарілий інтерфейс.

Виправлення: Перевірте політику/події брандмауера, підтвердьте route print, видаліть застарілі VPN-адаптери/маршрути, потім розгляньте Winsock reset, якщо ланцюжок провайдерів пошкоджений.

4) Симптом: Працювало до відключення VPN; потім нічого не підключається

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

Виправлення: Правильне оновлення/ремонт VPN-клієнта, скиньте проксі в direct, очистіть DNS, потім Winsock reset + перезавантаження, якщо провайдери застрягли.

5) Симптом: Падають тільки великі завантаження або деякі HTTPS сайти; маленькі ping працюють

Корінь проблеми: MTU/PMTUD чорна діра, часто через VPN або GRE/IPsec тунелі з заблокованим ICMP.

Виправлення: Діагностика DF ping, змініть MTU на інтерфейсі або виправте обробку ICMP fragmentation-needed у мережевій політиці.

6) Симптом: Після оновлення засобів безпеки — випадкові тайм-аути й скидання

Корінь проблеми: Зламаний WFP callout драйвер або провайдер, схожий на LSP; записи каталогу вказують на несумісні версії DLL.

Виправлення: Патч/відкат від постачальника; Winsock reset може очистити корупцію каталогу, але не виправить багатий фільтруючий драйвер.

7) Симптом: Внутрішні імена резолвяться в неправильне оточення (prod vs dev), періодично

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

Виправлення: Очистіть DNS, переконайтеся, що налаштування DNS VPN правильні, перевірте список суфіксів пошуку, уникайте хардкодингу серверів DNS на кінцевих пристроях.

Чеклісти / покроковий план

Чекліст A: Тріаж однієї машини (10 хвилин, без геройств)

Запустіть ipconfig /all. Підтвердіть IP, шлюз, DNS, оренду. Якщо зламано: спочатку виправте канал/DHCP.
Запустіть route print. Підтвердіть маршрути за замовчуванням, особливо після переходів VPN.
Запустіть nslookup для відомого домену. Якщо помилка: фокус на досяжності DNS.
Запустіть Test-NetConnection до IP:443. Якщо помилка: фокус на маршрутизації/брандмауері/MTU.
Перевірте WinHTTP-проксі: netsh winhttp show proxy. Якщо неправильно: скиньте/імпортуйте коректний проксі.
Зробіть дамп каталогу Winsock: netsh winsock show catalog. Шукайте сторонні провайдери, пов’язані з нещодавніми інсталяціями/оновленнями.
Якщо ланцюжок провайдерів виглядає підозріло і симптоми співпадають: netsh winsock reset, потім перезавантаження.

Чекліст B: «Я зробив Winsock reset і досі не працює» (добре, тепер справжня робота)

Перевірте ще раз налаштування проксі (WinHTTP і користувацький проксі). Winsock reset не виправляє стан проксі.
Тестуйте IPv4 та IPv6 окремо. Відключайте IPv6 лише як тимчасове підтвердження.
Перевірте MTU за допомогою DF ping; впевніться, що наклад VPN/тунелю не чорна діра для пакетів.
Підтвердіть профілі брандмауера і наявність стороннього фільтруючого ПЗ.
Шукайте проблеми з драйверами: журнали подій, енергоменеджмент NIC, тригери сон/пробудження.

Чекліст C: Практика для парку машин (що стандартизувати, щоб це перестало бути «випадковим»)

Стандартизувати версії VPN-клієнтів і забезпечити чисті процедури видалення/встановлення.
Заборонити «інтернет-оптимізатори» в корпоративних образах. Вони рідко оптимізують те, що вам потрібно.
Підтримувати скрипт бандла діагностики і збирати виводи перед скиданнями.
Визначити чітку стратегію проксі: PAC vs статичний, WinHTTP vs WinINET, на мережі vs поза мережею.
Відстежувати зміни: оновлення засобів захисту кінцевих точок, оновлення VPN, оновлення драйверів. Корелюйте зі сплесками заявок.

FAQ

1) Чи видаляє Winsock reset мої мережеві адаптери?

Ні. Він скидає каталог Winsock (провайдери). Ваші адаптери залишаються. Але треба перезавантажитись, і деяке програмне забезпечення, яке вставляло провайдери, може потребувати ремонту/перевстановлення.

2) Чому перезавантаження «виправляє», навіть коли нічого не змінювалось?

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

3) Чи варто виконувати і `netsh winsock reset`, і `netsh int ip reset`?

Лише коли є докази і для двох проблем: дивна поведінка ланцюжка провайдерів (Winsock) і дивні параметри інтерфейсу/стека (TCP/IP). Виконувати обидва всліпу — це шлях до того, щоб не відстежити, що саме допомогло.

4) Чому лише деякі додатки падають, а не всі?

Додатки використовують різні стекі (WinHTTP vs WinINET), різні налаштування проксі, різну поведінку DNS і віддають перевагу IPv4/IPv6 по-різному. Вибіркова відмова — очікувана річ у багатошарових системах.

5) Чи може VPN викликати проблеми Winsock навіть після деінсталяції?

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

6) Чи проблема DNS, якщо `nslookup` працює?

Не обов’язково. Резолюція DNS може бути успішною, тоді як транспорт падає. Розділяйте «читаю ім’я?» і «можу підключитись?» за допомогою прямого TCP-тесту порту.

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

Windows використовує перевірки доступності (NCSI), які можуть бути заблоковані політикою або проксі. Іконка — підказка, а не вирок.

8) Коли підозрювати MTU/PMTUD замість Winsock?

Якщо малий трафік працює (DNS, невеликі HTTP) але великі HTTPS-трансфери зависають, або падають лише певні сайти, особливо через VPN. Перевірте DF ping і коригуйте MTU або обробку ICMP.

9) Чи добра ідея відключати брандмауер як діагностику?

Не в корпоративних середовищах. Ви зміните профіль безпеки і все одно можете не обійти сторонні WFP-фільтри. Краще цілеспрямовані перевірки: профіль, правила і контрольовані тести портів.

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

В порядку: очистити DNS, скинути WinHTTP-проксі до відомого доброго стану, потім Winsock reset + перезавантаження. Додавайте TCP/IP reset тільки якщо поведінка інтерфейсу явно зіпсована.

Наступні кроки, які варто зробити

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

Виконайте швидкий план діагностики і розділіть DNS від транспорту від політики.
Перевірте проксі (WinHTTP і користувацький). Це найвища ефективність виправлення для «додатки падають, браузер працює».
Перегляньте каталог Winsock, коли підозрюєте стороннє перехоплення. Якщо він «забруднений» або застарілий — скиньте і перезавантажте.
Не розганяйте скидання по всьому парку машин без збору базових виводів; спочатку зберіть дані, потім виправляйте шар, що дає проблему.
Ескалюйте з доказами: таблиця маршрутів, стан проксі, тести IPv4/IPv6 і чи відмови корелюють з оновленнями VPN/засобів безпеки.

Winsock reset — хороший інструмент. Це не спосіб життя. Використовуйте його, коли ланцюжок провайдерів — ймовірний винуватець, і будьте дисципліновані, щоб довести це.