Скидання мережевого стека через PowerShell (чисто, з можливістю відкату)

February 21, 2026 • February 21, 2026 • Читання: 7 хв • Views: 1

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

Коли мережа в Windows ламається, вона рідко робить це елегантно. Одного моменту ви в VPN, наступного — «Connected, no internet», дзвінки в Teams звучать як підводний човен, а ваша система моніторингу чемно робить вигляд, ніби нічого не сталося, бо хост все ще пінгує сам себе.

Спокуса — натиснути велику червону кнопку: «Network reset», випадкові заклинання netsh, перезавантаження й надія. Іноді це спрацьовує. Іноді локальна проблема перетворюється на повний інцидент — особливо на машинах з VPN-клієнтами, віртуальними комутаторами, Hyper-V, WSL2 або агентами безпеки кінцевої точки. Цей посібник — розумний шлях: скидаємо мережевий стек через PowerShell чисто, обдумано і з можливістю відкату.

Що насправді означає «скинути мережевий стек»

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

Налаштування інтерфейсу: IP-адреси, маршрути, DNS-сервери, MTU, стан DHCP.
Параметри TCP/IP: глобальні налаштування, як-от автотонування, ECN, RSS, offload-опції. Деякі параметри — на інтерфейс.
Каталог Winsock: місце, де Layered Service Providers (LSP) раніше підключалися до викликів сокетів; сьогодні багато продуктів використовують WFP (Windows Filtering Platform), але скидання Winsock все ще зустрічається в плейбуках.
Кеш клієнта DNS і NRPT: розв’язування імен — це і кеш клієнта, і політика (особливо з VPN).
Налаштування проксі: WinINET/WinHTTP і PAC-настройки; можуть зламати «інтернет», тоді як сирі сокети ще працюють.
Профілі та правила брандмауера: не зовсім «мережевий стек», але близько, через що скидання часто взаємодіє з ними.
Віртуальні комутатори та адаптери: Hyper‑V vSwitch, WSL2 vEthernet, VPN-адаптери, драйвери фільтрів від агентів безпеки.

«Скидання» може означати:

М’яке скидання: очистити кеші, оновити оренди, перезапустити адаптери, скинути проксі. Низький ризик, висока віддача.
Середнє скидання: скидання Winsock і параметрів TCP/IP до значень за замовчуванням, перезбірка частин стека, перезапуск служб. Іноді потрібен перезавантаження. Може порушити інтеграції VPN/EDR.
Грубе скидання: видалити та перевстановити адаптери, стерти профілі, видалити постійні маршрути, скинути політики брандмауера, UI «Network reset». Ефективно, але ви щойно стерли докази й можливо бізнес-критичні налаштування.

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

Перед тим як щось чіпати: межі, резервні копії та зона ураження

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

Визначте масштаб: машина, користувач, додаток чи шлях?

Якщо зламаний лише один додаток, не починайте з «скидання стека». Доведіть, що це не на рівні додатка (налаштування проксі, сховище сертифікатів, per-app VPN, застарілий DNS всередині додатка). Якщо лише один користувач має проблему на спільній системі, підозрюйте проксі/ WPAD для користувача, облікові дані або інструменти VPN, що залежать від профілю.

Зрозумійте, що означає «зворотність» у мережах Windows

Зворотність не означає кнопку «скасувати». Це означає, що у вас є достатньо збереженого стану, щоб відтворити:

IP/DNS конфігурацію інтерфейсів (DHCP чи статична)
Маршрути (особливо постійні маршрути)
DNS-suffix / список пошуку
Налаштування проксі (WinINET та WinHTTP)
Політики, пов’язані з VPN (NRPT) та імена адаптерів
Розширені властивості адаптера, які ви спеціально налаштовували

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

Адміністративна реальність

Багато операцій вимагають підвищених прав. Якщо ви на корпоративному керованому вузлі, деякі дії будуть заблоковані політикою або пізніше відкотяться агентами управління. Змиріться з цим. Ваше завдання — діагностувати й застосувати мінімальну стійку зміну.

Цитата, бо правда

«Надія — це не стратегія.» — генерал Гордон Р. Салліван

Скидання мереж, кероване надією, — це шлях до п’яти перезавантажень і називання цього «періодичним».

Швидкий план діагностики (знайдіть вузьке місце за кілька хвилин)

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

Перше: інтерфейс реально підключений і в нормі?

Перевірте статус адаптера, швидкість та який NIC використовується.
Підтвердіть, що у вас є IP (IPv4 і/або IPv6) і шлюз за замовчуванням там, де очікуєте.

Друге: чи можна дістатися шлюзу і щось за ним?

Зробіть ping до шлюзу (локальна L2/L3 досяжність).
Зробіть ping зовнішньої IP-адреси (маршрутизація/NAT/вихідна лінія).
Якщо ping бреше, зробіть трасування (фаєрволи можуть робити ping ненадійним свідком).

Третє: чи DNS — проблема (часто так)?

Розв’яжіть відоме ім’я через налаштований DNS-сервер.
Порівняйте розв’язування і сире IP-з’єднання.
Очищайте кеш DNS лише після того, як зафіксували докази.

Четверте: чи проксі або політика VPN не перехоплює трафік?

Перевірте проксі WinHTTP та проксі користувача.
Перевірте маршрути VPN і правила NRPT (split tunnel vs full tunnel).

П’яте: чи є фільтрація (брандмауер, EDR, WFP callback, драйвер)?

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

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

Цікаві факти та історичний контекст

Шість–десять невеликих фактів, які допоможуть вам зрозуміти, чому мережа Windows поводиться так:

Скидання Winsock — релікт, що ще має значення. Layered Service Providers (LSP) були поширеним способом перехоплення сокетів; сучасні інструменти безпеки часто використовують WFP, але каталог Winsock може бути пошкоджений або неправильно впорядкований.
netsh з’явився задовго до PowerShell. Автоматизація мереж Windows жила в netsh до того, як PowerShell став стандартом. Багато «PowerShell» виправлень все ще викликають netsh, бо він перевірений боєм.
Windows віддає перевагу IPv6, коли може. Системи з подвійним стеком часто спочатку намагаються AAAA-записи. «IPv6 ламається» може проявлятися як «інтернет повільний», а не як «IPv6 не працює».
DNS у Windows — це не просто DNS. Резольвер змішує кеш, список суфіксів пошуку, LLMNR, mDNS (новіше) та політики NRPT. Одна неправильна політика може зробити внутрішні імена недоступними, тоді як публічні працюють.
UI «Network reset» — відносно нова функція. Це зручність епохи Windows 10+, яка фактично видаляє та перевстановлює мережеві адаптери і скидає компоненти. Це також гарний спосіб втратити кастомні маршрути та прив’язки VPN.
Автотонування TCP було контроверсійним. Коли Windows широко ввів автотонування вікна прийому, воно покращило пропускну здатність для багатьох каналів, але спричинило дивність з деякими middlebox. Вимкнення часом допомагало, але часто просто знижувало продуктивність.
Налаштування проксі живуть у двох світах. WinINET-проксі — в контексті користувача і використовується браузерами; WinHTTP-проксі — в контексті машини і використовується службами. Скидання одного без іншого дає «працює в браузері, не працює в службі».
Маршрутизація на основі метрик зазвичай правильна… поки не ні. Windows вибирає маршрути за довжиною префіксу та метрикою. Додайте VPN-адаптер — і ваш маршрут за замовчуванням зміниться. Люди називають це «випадковим». Це не випадково. Це детерміновано і незручно.
Агенти безпеки люблять мережевий стек. Багато EDR встановлюють драйвери-фільтри і WFP callback-и. Скидання, що змінює порядок біндінгів або каталоги, може зламати ці інтеграції — тимчасово або допоки агент не відновить себе.

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

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

Завдання 1: Підтвердіть, що ви з підвищеними правами (не вгадуйте)

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal]::new([Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)"
True

Що це означає: True означає контекст адміністратора. Багато дій скидання мовчатимуть або застосуються частково без нього.

Рішення: Якщо False, відкрийте PowerShell як адміністратор. Не продовжуйте. Часткові скидання — як створити унікальну, невідтворювану помилку.

Завдання 2: Збережіть поточну конфігурацію інтерфейсу (ваш seed для відкату)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,InterfaceIndex,IPv4Address,IPv6Address,DNSServer,IPv4DefaultGateway,NetProfile.Name"
InterfaceAlias     : Ethernet0
InterfaceIndex     : 12
IPv4Address        : 10.20.14.55
IPv6Address        : fe80::b9f1:7c2a:7c2d:aa11
DNSServer          : {10.20.0.10, 10.20.0.11}
IPv4DefaultGateway : 10.20.14.1
NetProfile.Name    : CorpLAN

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

Рішення: Збережіть це (копіюйте/вставте у тикет або експортуйте у файл). Якщо ви не бачите шлюзу за замовчуванням — це ще не задача «скидання»; спочатку виправляйте DHCP/статичну конфігурацію.

Завдання 3: Визначте активний вибір маршруту (дефолтний маршрут розповідає історії)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric,InterfaceMetric | Format-Table ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric -Auto"
ifIndex InterfaceAlias NextHop      RouteMetric InterfaceMetric
------ -------------- -------      ----------- --------------
12     Ethernet0      10.20.14.1   0           25
28     VPN-Corp       0.0.0.0      10          5

Що це означає: У вас є конкуренція дефолтних маршрутів. Тут VPN-адаптер має нижчу сумарну метрику і може відбирати трафік. Це може бути бажано (full tunnel) або катастрофа (коли очікується split tunnel).

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

Завдання 4: Базова перевірка з’єднання: шлюз, потім зовнішній IP

cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 10.20.14.1"
Source        Destination     IPV4Address      IPV6Address Bytes Time(ms)
------        -----------     -----------      ----------- ----- --------
WIN-CLIENT01  10.20.14.1      10.20.14.1                   32    2
WIN-CLIENT01  10.20.14.1      10.20.14.1                   32    2

cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 1.1.1.1"
Source        Destination     IPV4Address      IPV6Address Bytes Time(ms)
------        -----------     -----------      ----------- ----- --------
WIN-CLIENT01  1.1.1.1         1.1.1.1                      32    16
WIN-CLIENT01  1.1.1.1         1.1.1.1                      32    15

Що це означає: L3-маршрутизація до інтернету працює (щонайменше ICMP). Якщо додатки все ще падали — підозрюйте DNS/проксі/фільтри.

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

Завдання 5: Тест розв’язування DNS, що справді дає інфу

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name example.com -Server 10.20.0.10 | Select-Object -First 2"
Name       Type TTL Section IPAddress
----       ---- --- ------- ---------
example.com A    60  Answer  93.184.216.34
example.com A    60  Answer  93.184.216.34

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

Рішення: Якщо це таймаут, перевірте, чи досяжний DNS-сервер і чи VPN або фаєрвол не блокують UDP/TCP 53. Якщо повертає NXDOMAIN для внутрішніх імен — дивіться суфікси пошуку і NRPT.

Завдання 6: Перегляд кешу клієнта DNS (і не очищайте сліпо)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5"
Entry           RecordName  RecordType TimeToLive Data
-----           ----------  ---------- ---------- ----
example.com     example.com A          00:00:41  93.184.216.34
wpad            wpad        A          00:05:00  10.20.0.50
intranet        intranet    A          00:00:12  10.20.8.20

Що це означає: Ви бачите кешовані записи, як-от wpad. WPAD часто є джерелом «тільки веб-додатки не працюють».

Рішення: Якщо бачите підозрілі записи (неправильна IP для intranet, застарілий wpad), очистіть кеш після фіксації, а потім повторно протестуйте розв’язування. Якщо неправильний результат повертається відразу — причина upstream або політика, а не кеш.

Завдання 7: Перевірте стан проксі (WinINET vs WinHTTP)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

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

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable,ProxyServer,AutoConfigURL"
ProxyEnable ProxyServer        AutoConfigURL
----------- -----------        -------------
1           10.20.0.60:8080    http://wpad/wpad.dat

Що це означає: І контекст машини, і користувача вказують на проксі/PAC. Якщо цей проксі недоступний, браузери й багато додатків будуть падати, тоді як ping буде в порядку.

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

Завдання 8: Перевірте, чи служба клієнта DNS здорова

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-Table Status,StartType,Name -Auto"
Status  StartType Name
------  --------- ----
Running Automatic Dnscache

Що це означає: Якщо Dnscache зупинено/відключено, розв’язування імен стає непослідовним і повільнішим; деякі API поводяться інакше.

Рішення: Якщо служба не працює — запустіть її і з’ясуйте, чому її відключили (політика жорсткого захисту? «оптимізатор»?). Не скидайте TCP/IP, щоб виправити зупинену службу.

Завдання 9: Спостерігайте глобальні параметри TCP перед «тонінгом»

cr0x@server:~$ powershell -NoProfile -Command "netsh int tcp show global"
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : default
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

Що це означає: Це глобальні поведінки TCP. «Скидання TCP/IP» може повернути деякі пункти; «оптимізатори» часто їх змінюють.

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

Завдання 10: Визначте драйвери адаптерів і недавні зміни

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed,DriverInformation | Format-List"
Name              : Ethernet0
Status            : Up
LinkSpeed         : 1 Gbps
DriverInformation : Intel(R) Ethernet Connection (11) I219-LM #4

Name              : VPN-Corp
Status            : Up
LinkSpeed         : 100 Mbps
DriverInformation : WAN Miniport (IKEv2)

Що це означає: «Up» не означає «здоровий», але це початок. Ідентичність драйвера важлива: вендори NIC поставляють розширені offload-функції, які можуть ламатися після оновлень.

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

Завдання 11: Перезапустіть один адаптер (низький ризик, дуже ефективно)

cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false"

Що це означає: Це струсить інтерфейс, заново проведе переговори по лінку, у багатьох випадках оновить DHCP і перев’яже протоколи.

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

Завдання 12: Примусово оновіть DHCP (коли підозрюєте застарілу оренду)

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /release"
Windows IP Configuration

No operation can be performed on Ethernet0 while it has its media disconnected.
Ethernet0 has been released.

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /renew"
Windows IP Configuration

Ethernet0 has renewed its lease.
   IPv4 Address. . . . . . . . . . . : 10.20.14.55
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.20.14.1

Що це означає: Release/renew — грубий, але оборотний метод. Якщо оновлення не вдається — шлях DHCP зламаний (або 802.1X/VLAN неправильний).

Рішення: Якщо renew не вдається — зупиніться. Виправляйте автентифікацію L2/VLAN/DHCP. Не переходьте до скидання стека; ви просто опинитесь в ще складнішому офлайні.

Завдання 13: Очищення DNS і повторна перевірка (тільки після доказів)

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /displaydns | Select-Object -First 12"
Windows IP Configuration

    example.com
    ----------------------------------------
    Record Name . . . . . : example.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 41
    Data Length . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 93.184.216.34

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /flushdns"
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Що це означає: Кеш очищено. Якщо розв’язування одразу повертає неправильне — отруєння upstream або політика, а не локальний кеш.

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

Завдання 14: Скидання Winsock (середній вплив, часто вимагає перезавантаження)

cr0x@server:~$ powershell -NoProfile -Command "netsh winsock show catalog | Select-String -Pattern 'Catalog5' -Context 0,2 | Select-Object -First 6"
Catalog5 01
--------
Packed Catalog Item
    Description: MSAFD Tcpip [TCP/IP]

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

Що це означає: Каталог Winsock перебудовано до значень за замовчуванням. Це може зламати або виправити софт, що підключається до сокетів. Потреба в перезавантаженні реальна.

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

Завдання 15: Скидання параметрів TCP/IP (сильніший молоток)

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

Що це означає: Це скидає багато реєстрових налаштувань TCP/IP. Може виправити пошкодження і погані налаштування. Також може стерти навмисні тюнінги і деякі статичні шаблони.

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

Завдання 16: Скидання WinHTTP-проксі (поширений «інтернет зламався» фікс)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp reset proxy"
Current WinHTTP proxy settings:

    Direct access (no proxy server).

Що це означає: Проксі в контексті машини очищено. Служби, що залежать від WinHTTP, можуть почати працювати відразу.

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

Завдання 17: Збереження та відновлення постійних маршрутів (легко забути й викликати аварію)

cr0x@server:~$ powershell -NoProfile -Command "route print -4 | Select-String -Pattern 'Persistent Routes' -Context 0,8"
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      10.50.0.0    255.255.0.0        10.20.14.254       1

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Format-Table DestinationPrefix,NextHop,RouteMetric,InterfaceAlias -Auto"
DestinationPrefix NextHop       RouteMetric InterfaceAlias
----------------- -------       ----------- --------------
10.50.0.0/16      10.20.14.254  1           Ethernet0

Що це означає: Існують постійні маршрути і вони важливі. «Грубий скидання» або перевстановлення адаптера може їх стерти, і бізнес-додаток за 10.50.0.0/16 тихо помре.

Рішення: Експортуйте ці маршрути перед скиданням. Після скидання відновіть їх за допомогою New-NetRoute -PolicyStore PersistentStore, якщо потрібно.

Завдання 18: Швидкий тест порту/шляху (доведіть, що це не лише ICMP)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.10 -Port 53"
ComputerName     : 10.20.0.10
RemoteAddress    : 10.20.0.10
RemotePort       : 53
InterfaceAlias   : Ethernet0
SourceAddress    : 10.20.14.55
TcpTestSucceeded : True

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.60 -Port 8080"
ComputerName     : 10.20.0.60
RemoteAddress    : 10.20.0.60
RemotePort       : 8080
InterfaceAlias   : Ethernet0
SourceAddress    : 10.20.14.55
TcpTestSucceeded : False

Що це означає: DNS-сервер досяжний на TCP 53; порт проксі 8080 — ні. Це пояснює «веб-додатки мертві» без скидання IP-стека.

Рішення: Виправте доступ до проксі або правила обходу. Не скидайте Winsock через недоступний проксі.

Це багато команд, і так — це навмисно. Скидання стека має бути завершенням короткого ланцюжка діагностики, а не першим кроком у скрипті емоційної підтримки.

Контрольні списки / покроковий план: чисте, з можливістю відкату

Це плейбук для продакшену. Це не найшвидший спосіб «щось зробити». Це найшвидший спосіб перестати робити не те.

Контрольний список A: Збережіть стан (робіть це щоразу)

Збережіть конфігурацію інтерфейсів: IP, DNS, шлюз, профіль.
Збережіть маршрути, включаючи постійні.
Збережіть налаштування клієнта DNS (список суфіксів, сервери).
Збережіть стан проксі (WinINET + WinHTTP).
Запишіть статус VPN і список адаптерів.

cr0x@server:~$ powershell -NoProfile -Command "New-Item -ItemType Directory -Force C:\Temp\net-reset | Out-Null; Get-Date | Out-File C:\Temp\net-reset\timestamp.txt; Get-NetIPConfiguration | Out-File C:\Temp\net-reset\netipconfig.txt; Get-NetRoute | Out-File C:\Temp\net-reset\netroutes.txt; Get-DnsClientServerAddress | Out-File C:\Temp\net-reset\dns-servers.txt; netsh winhttp show proxy | Out-File C:\Temp\net-reset\winhttp-proxy.txt; Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Out-File C:\Temp\net-reset\wininet-proxy.txt; Get-NetAdapter | Out-File C:\Temp\net-reset\netadapters.txt"

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

Контрольний список B: М’яке скидання (перші безпечні кроки)

Перезапустіть уражений адаптер.
Оновіть оренду DHCP (тільки якщо використовується DHCP).
Очищення кешу DNS (після фіксації доказів).
Скидання WinHTTP-проксі (діагностика).
Перезапуск служби клієнта DNS, якщо вона зависла.

cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false; ipconfig /renew; ipconfig /flushdns; netsh winhttp reset proxy; Restart-Service Dnscache -Force"
Windows IP Configuration

Ethernet0 has renewed its lease.
Successfully flushed the DNS Resolver Cache.
Current WinHTTP proxy settings:

    Direct access (no proxy server).

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

Контрольний список C: Середнє скидання (коли м’яке не допомагає)

Робіть це, коли довели, що хост має лінк, має IP, може дістатися шлюзу, але вищі рівні мережі пошкоджені чи перехоплені.

Скиньте каталог Winsock.
Скиньте параметри TCP/IP стека.
Перезавантаження (так, справжнє перезавантаження).

cr0x@server:~$ powershell -NoProfile -Command "netsh winsock reset; netsh int ip reset"
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.

Рішення: Якщо ви не можете перезавантажитись — не прикидайтеся, що скинули. Заплануйте вікно перезавантаження. Стек повний стану; ви не перехитрите його атмосферою.

Контрольний список D: Грубе скидання (остання інстанція, велика зона ураження)

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

Замість UI «Network reset» я надаю перевагу таргетованим діям: видалення застарілих адаптерів, відключення/повторне підключення конкретних біндінгів і лише потім повний скидання. Якщо мусите використати ядерну опцію, переконайтеся, що маєте знімок зі Списку A.

Жарт #1: Повне скидання мережі — як «вимкнути і ввімкнути», тільки воно ще й видаляє домашнє завдання, а потім дивується, чому ви виглядаєте напружено.

Три корпоративні міні-історії (як це йде не так і правильно)

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

Почалося як скарга «VPN повільний» від віддаленої фінансової команди. Ноутбук міг пінгувати шлюз VPN, міг розв’язувати внутрішній DNS, але ERP-клієнт таймаутив. Хтось побачив «Connected, no internet» на іконці Wi‑Fi і вирішив, що стек TCP/IP пошкоджено.

Намір виправити був рвучким: скидання Winsock, скидання TCP/IP, «Network reset» через Параметри, дві перезавантаження. VPN-клієнт перевстановлено. Все одно не працювало. Стало гірше: машина втратила постійний маршрут, який тихо направляв ERP-трафік через внутрішній проксі, що використовувався лише тим відділом.

Ми підключилися після третього перезавантаження, бо тоді вже «це мусить бути Windows». Підказка була в таблиці маршрутів: VPN встановив дефолтний маршрут з низькою метрикою, але підмережа ERP не була включена в split-tunnel VPN. До скидання, постійний маршрут це компенсував. Після скидання його не було, тож ERP-трафік ішов не туди і пропадав.

Справжнє виправлення — виправити pushed routes VPN і тимчасово додати постійний маршрут назад. Скидання не допомогло — воно видалило обхідне рішення, яке компенсувало upstream-помилку. Неправильне припущення: іконка «no internet» означає «зламаний TCP/IP». Насправді Windows не могла дістатися конкретного NCSI probe endpoint, що не те ж саме, що «мережа впала».

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

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

Команда десктоп-інженерії розгорнула «скрипт оптимізації латентності» по флоту торгових терміналів. Він вимкнув автотонування TCP, підправив offload-и і вніс кілька реєстрових значень з форумного поста ери Windows Vista. Скрипт зробив автора відчувати себе сильним, що рідко є сигналом надійності.

Декілька днів ніхто не помічав. Потім почалися скарги: внутрішні веб-додатки час від часу падали, передачі файлів гальмували, VPN під навантаженням був ненадійний. PING був нормальний. Speedtest «в порядку». Реальні робочі навантаження — ні.

Ми порівняли зламану машину зі справною. Глобальний стан TCP був димовим сигналом: авто-тонування вимкнено, провайдер керування перевантаженням змінено, і купа offload-налаштувань адаптера була змінена без урахування версій драйверів. Деякий middlebox на шляху не полюбив таку поведінку й почав скидати або перемішувати трафік при пікових навантаженнях.

«Фікс» виявився скиданням — але контрольованим. Ми захопили стан, повернули глобальні параметри TCP до дефолту і застосували лише вузьку, вимірювану зміну там, де це виправдано. Більшість «оптимізації» було видалено. Пропускна здатність покращилася, помилки зменшилися, і єдине, що стало повільніше — це швидкість появи нових тікетів.

Урок: налаштування продуктивності без вимірів — це просто відмови в кращій упаковці. Повернення до дефолту часто найшвидший шлях назад до стабільності.

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

Windows-сервер у віддаленому офісі почав ненадійно розв’язувати внутрішні імена. Місцева ІТ-команда зробила стандартне: очистили DNS, перезавантажили, лаяли на провайдера. Іноді працювало на годину, іноді — ні. Тим часом сервер успішно розв’язував публічні імена, бо мав fallback до публічного DNS.

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

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

Виправлення було прісним: прибрати публічний DNS із конфігурації, додати другий внутрішній DNS, доступний по стабільнішому шляху, і виправити маршрут у філії. Ніякого скидання стека не знадобилось. Знімок стану не дозволив нам знищити докази і дав можливість довести причинно-наслідковий зв’язок команді мережі.

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

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

Тут тікети перестають бути розмитими.

1) «Connected, no internet», але внутрішні ресурси працюють

Симптом: Windows показує «No internet», але ви маєте доступ до інтра-мережі або можете пінгувати внутрішні IP.

Корінь: NCSI (Network Connectivity Status Indicator) не може дістатися свого probe endpoint, часто через проксі, фаєрвол або політику DNS. Це не обов’язково реальна відмова мережі.

Виправлення: Перевірте справжнє здоров’я шляху за допомогою Test-NetConnection до відомих цілей. Перевірте проксі й DNS. Не скидайте TCP/IP через невдоволений значок.

2) Пінг працює, веб-браузинг падає

Симптом: Test-Connection 1.1.1.1 працює. Браузер нічого не завантажує.

Корінь: Неправильна конфігурація проксі (PAC/WPAD), заблокований порт проксі або неправильно налаштований WinINET-проксі.

Виправлення: Перевірте WinINET і WinHTTP-проксі; протестуйте доступ до порту проксі; скиньте проксі для діагностики.

3) DNS працює для публічних імен, але падає для внутрішніх

Симптом: Resolve-DnsName example.com працює; Resolve-DnsName intranet.corp повертає NXDOMAIN.

Корінь: Неправильні DNS-сервери, відсутній список суфіксів пошуку або NRPT-політики VPN не застосовано.

Виправлення: Переконайтеся, що внутрішні DNS-сервери налаштовані і доступні; перевірте список суфіксів; перевірте DNS/політику VPN. Очищення кешу не створить відсутні зони.

4) Після підключення VPN все ламається

Симптом: Локальний інтернет зникає разом із підключенням VPN або внутрішні маршрути не працюють.

Корінь: Захоплення дефолтного маршруту (full tunnel vs split tunnel), питання метрик або відсутні pushed routes.

Виправлення: Перевірте дефолтні маршрути й метрики; валідируйте політику маршрутизації VPN. Не скидайте стек; виправляйте намір маршруту.

5) «Скидання допомогло одного разу, але вранці знову те саме»

Симптом: Щоденне повернення проблеми; швидке скидання тимчасово допомагає.

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

Виправлення: Знайдіть налаштування, що «дрейфує», порівнявши знімки. Виправте джерело (GPO/MDM/VPN-клієнт/драйвер). Повторні скидання — це просто ви, що запускаєте той самий інцидент за розкладом.

6) Після «network reset» бізнес-додаток не достукатися до підмережі

Симптом: Більшість речей працює; одна внутрішня підмережа недоступна.

Корінь: Втрачено постійні маршрути або статичну IP-конфігурацію.

Виправлення: Відновіть постійні маршрути і перевірте за допомогою Get-NetRoute -PolicyStore PersistentStore. Ось чому ми робимо знімки стану.

7) DNS повільний, переривчасті таймаути

Симптом: Розв’язування імен займає секунди; іноді відмовляє.

Корінь: Перший DNS-сервер недоступний, Windows повільно переходить на наступний; або DNS VPN-сервера перевантажені.

Виправлення: Тестуйте кожен DNS-сервер окремо з Resolve-DnsName -Server. Приберіть мертві DNS-сервери; не просто очищайте кеш і кажіть «виправлено».

8) «Скидання Winsock зламало мій клієнт безпеки/VPN»

Симптом: Після скидання VPN або агент безпеки не підключається, фільтрація мережі поводиться дивно.

Корінь: Програмне забезпечення залежить від конкретних записів у каталозі або біндінгів фільтрів; скидання змінило порядок/налаштування за замовчуванням.

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

Жарт #2: Скидання Winsock — це як скотч у мережевій інженерії: інколи заклеює дірку, інколи стає частиною сантехніки.

FAQ

1) Чи однакові «Reset this PC’s network» (Параметри Windows) та `netsh winsock reset`?

Ні. UI «Network reset» ширший і руйнівніший: він видаляє і перевстановлює адаптери та скидає кілька компонентів. netsh winsock reset таргетує каталог Winsock конкретно. Використовуйте UI лише коли таргетовані скидання не допомагають і ви зберегли стан.

2) Чи можна зробити чисте скидання тільки PowerShell, без `netsh`?

Деякі частини — так (перезапуск адаптера, інспекція IP, управління маршрутами). Але скидання Winsock/TCP/IP все ще надійніше виконувати через netsh на багатьох версіях Windows. Бути догматичним щодо інструмента — це як втрачати час.

3) Коли потрібно перезавантажувати?

Коли інструмент каже про це, і коли ви внесли зміни, що модифікують низькорівневий стан стека. Скидання Winsock і TCP/IP зазвичай вимагають перезавантаження для повного застосування. Якщо не можете перезавантажитись — називайте це діагностичною спробою, а не скиданням.

4) Чи зламає скидання мій VPN?

Може. VPN-клієнти часто встановлюють віртуальні адаптери, маршрути, DNS-політики і іноді компоненти фільтрації. М’які скидання зазвичай не зашкодять. Середні/грубі скидання можуть змусити клієнт ремонтуватися або перевстановлюватись. Захопіть маршрути та стан DNS перед дією, щоб знати, чи щось змінилося через VPN.

5) Я можу дістатися IP-адрес, але не імен. Чи скинути TCP/IP?

Зазвичай ні. Це частіше проблема доступності DNS-сервера, списку суфіксів, NRPT або проксі/PAC. Почніть з Resolve-DnsName -Server і перевірки DNS-серверів та маршрутів. Скидання TCP/IP — це більший молоток, ніж проблема потребує.

6) Яка найкраща «перша команда для скидання»?

Restart-NetAdapter для ураженого адаптера, а потім цілеспрямоване очищення кешу DNS, якщо є докази застарілого розв’язування. Це має низьку зону ураження і часто прибирає тимчасові глюки драйвера/DHCP.

7) Очищення кешу DNS впливає на інших користувачів чи служби?

Воно впливає на локальний кеш резольвера машини. Може спричинити короткий сплеск DNS-запитів при повторному резольвінгу імен. Зазвичай безпечно, але при діагностиці зафіксуйте кеш перед очищенням, щоб бачити, що було не так.

8) Чому деякі служби падають, а браузери працюють (або навпаки)?

Через контекст проксі. Браузери часто використовують WinINET (проксі користувача). Служби і фонова компонента часто використовують WinHTTP (машинний проксі). Якщо вони не узгоджені — отримаєте розділення поведінки.

9) Чи слід відключати IPv6, щоб «полагодити»?

Майже ніколи не як перший крок. Відключення IPv6 може сховати справжні проблеми з DNS/маршрутом і зламати сучасні функції Windows та деякий VPN-поведінку. Якщо підозрюєте проблему IPv6, тестуйте явно (AAAA, IPv6 ping/traceroute), а не відривайте його.

10) Як зробити скидання практично відкотним?

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

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

Якщо ви запам’ятаєте одне: скидання мережевого стека — це не діагностика; це крок виправлення. Використовуйте його, коли звузили проблему до локальної корупції або поганого стану — не коли вам нудно.

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

Запустіть швидкий план діагностики: інтерфейс → шлюз → зовнішній IP → DNS → проксі/VPN → фільтрація.
Збережіть стан у C:\Temp\net-reset (або там, де цього чекає ваша організація). Тримайте це як доказ інциденту.
Спочатку пробуйте м’які скидання: перезапуск адаптера, оновлення DHCP, очищення DNS, скидання проксі (діагностика), перезапуск Dnscache.
Якщо досі не працює і у вас є вікно для перезавантаження: Winsock reset + TCP/IP reset, потім одне чисте перезавантаження.
Після будь-якого скидання: перевірте маршрути та постійні маршрути, підтвердіть DNS-сервери, підтвердіть намір проксі, а потім повторно протестуйте початковий проблемний додаток.

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