Wi‑Fi раптово обривається: налаштування роумінгу, яке приховує Windows

February 8, 2026 • February 8, 2026 • Читання: 6 хв • Views: 1

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

Ви на дзвінку. Звук добрий — поки раптом ні. Teams зависає, Slack перепідключається, а VPN влаштовує невеличку істерику.
Іконка Wi‑Fi робить те саме «підключено → не підключено → знову підключено», ніби репетирує для талант‑шоу.

Більшість людей звинувачують «поганий Wi‑Fi». Іноді так воно і є. Частіше причина — клієнт Windows, який приймає рішення про роумінг, яких ви не просили,
за порогами, які ви не вибирали, з енергозберігаючими «оптимізаціями», яких ви точно не схвалювали. Давайте виведемо ці налаштування на світло.

Що таке роумінг насправді (і чому це виглядає як обрив)

Роумінг — це коли клієнт вирішує: «Я зараз асоційований з AP A; AP B може бути кращим; я перемістюся».
В термінах Wi‑Fi це означає reassociation (і часто ключовий handshake), що може тривати від десятків до сотень мілісекунд.
Якщо процес чистий і швидкий, ви ледь помічаєте. Якщо він заплутаний — ваші додатки бачать втрату пакетів, затримки TCP і перевстановлення VPN.

«Випадкові обриви» часто насправді — поганий роумінг. Це виглядає як розрив, бо додатки не розбираються в семантиці Wi‑Fi.
Їх хвилює лише факт, що сокет перестав передавати дані. VoIP, відеодзвінки, RDP і VPN найперші починають скаржитись.

Неприємна реальність: рішення про роумінг здебільшого ухвалює саме клієнт. AP може підштовхувати, мотивувати або примушувати (про це далі),
але стек Wi‑Fi у Windows і драйвер остаточно вирішують, коли кинути поточний BSSID і приєднатися до іншого.

У вас може бути відмінне покриття й одночасно поганий роумінг. Сильний сигнал не гарантує стабільності — AP може бути перевантаженим, некоректно налаштованим або на зашумленому каналі.
Навпаки, трохи слабший AP може давати більш стабільний канал з меншим числом повторів.
Windows інтерпретує світ через RSSI, SNR, кількість повторів, результати сканів і евристики драйвера.

Налаштування Windows, яке має значення: Roaming Aggressiveness

У багатьох драйверах Wi‑Fi адаптерів (особливо Intel, але не тільки) є розширена властивість, зазвичай з назвoю
Roaming Aggressiveness. Windows не розміщує її у зручному екрані «Мережа й інтернет».
Вона захована в параметрах драйвера адаптера, і точна формулювання варіюється в залежності від виробника.

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

Проблема в тому, що «кращий сигнал» не те ж саме, що «кращий досвід». Порядний AP може мати сильний RSSI і одночасно бути перевантаженим, неправильно налаштованим або працювати на шумному каналі.
Натомість трохи слабший AP може забезпечувати набагато стабільніший зв’язок із меншим числом повторів.

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

Що робити загалом:

Якщо у вас стабільне середовище (домашній офіс, стаціонарний стіл, один близький AP): встановіть роумінг‑агресивність нижчою.
Якщо ви справді мобільні (склад, лікарня, кампус) і у вас є корпоративні AP, розраховані на це: можливо, варто вибрати середню.
Не ставте максимум лише тому, що «роумінг звучить добре». Це не спортивне досягнення.

Жарт №1: Wi‑Fi роумінг — як офісний hot‑desking: у теорії чудово, але хаос, коли всі постійно міняють місця посеред зустрічі.

Чому відбуваються «випадкові обриви»: реальні режими відмов

1) Надмірно агресивний роумінг спричиняє мікро‑перериви

Якщо драйвер занадто часто сканує і роумить, якість з’єднання стає пилкоподібною. Трохи втрачених пакетів викликає TCP backoff.
Трохи затримки — і «Teams перепідключається». Інтерфейс Windows може показати відключення або й залишатиме SSID, поки ваші додатки таймаутяться.

2) Енергозбереження вам брешe

Windows і драйверне керування живленням можуть переводити NIC у низькопотужні стани, зменшувати потужність передавача або збільшувати сон.
На батареї система агресивніша. Результат може виглядати як «випадкові обриви», особливо при низькій пропускній здатності (чат‑додатки в стані очікування),
а потім при різкому попиті в реальному часі (починається дзвінок).

3) Band steering та «smart connect» змушують клієнтів скакати

Побутові mesh‑системи часто використовують band steering: один SSID для 2.4 GHz та 5 GHz (іноді 6 GHz), система намагається перемістити клієнтів на «кращі» діапазони.
Це може працювати — поки не перестає. Якщо AP надто наполегливий (або багатий), ви отримаєте повторні деauth, невдалі reassociation і користувача, який упевнений, що провайдер ненавидить його особисто.

4) Баги драйвера та «просунуті» функції

Функції на кшталт U‑APSD, «Throughput Booster», «Preferred Band», «MIMO power save» і vendor roaming assist можуть конфліктувати з конкретною прошивкою AP.
Найгірші баги — ті, що відтворюються лише у вівторок о 10:03 під час дзвінка.
Але логи не брешуть; потрібно просто витягти потрібні.

5) Безпека й затримка handshak’у

WPA2‑Enterprise (802.1X) роумінг може бути швидким, якщо середовище налаштоване (PMK caching, OKC, 802.11r). Воно може також стати повільною катастрофою, якщо шлях RADIUS повільний,
сертифікати керуються неправильно або клієнта змушують робити повну повторну автентифікацію занадто часто.

6) Sticky‑клієнти: протилежна проблема

Інколи «обрив» — це насправді відмова клієнта роумити, коли треба; він тримається за помираючий AP, поки зв’язок не розсипається.
Потім нарешті роумить запізно, і ваш додаток називає це відключенням. Зниження roaming aggressiveness може погіршити таку поведінку у середовищах з високою мобільністю.
Саме тому діагностика перш ніж міняти налаштування.

7) DHCP‑оновлення та проблеми IP‑рівня, що маскуються під Wi‑Fi

Роумінг може спровокувати коротку зміну на шарі зв’язку, яка виявляє слабкий DHCP, ненадійний шлюз або VPN, що не толерує переходи інтерфейсу.
Мережевий доступ Wi‑Fi може бути в порядку; падає IP‑стек.

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

Коли користувач каже «Wi‑Fi обривається», не починайте з перевстановлення драйверів, ніби це 2009 рік. Тріажуйте як SRE:
підтвердіть симптом, звузьте шар, потім змінюйте одну змінну за раз.

Перший: доведіть, чи це шар‑зв’язку Wi‑Fi (роум/відключення) чи IP/VPN/додаток

Створіть WLAN‑звіт Windows та перегляньте логи Event Viewer. Шукайте Roaming, disconnected, deauth, reason codes.
Зіставте часові мітки з повідомленнями користувача та логами VPN.
Якщо BSSID змінюється у час «обриву», це роумінг. Якщо ні — ймовірно енергозбереження, RF‑повтори або вищий шар.

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

Перевірте процент близький до RSSI, швидкості прийому/передачі та канал.
Шукайте високу завантаженість каналу або очевидні симптоми ко‑канального завадіння (зниження швидкостей, повторні спроби роумінгу).

Третій: ізолюйте тригер контрольованими змінами

Зменшіть roaming aggressiveness на один крок (не ставте «мінімум назавжди», просто один крок). Протестуйте.
Вимкніть енергозбереження адаптера на час тесту. Протестуйте.
Якщо у вас mesh з band steering, тимчасово розділіть SSID за діапазонами (2.4 vs 5). Протестуйте.
Якщо корпоративна мережа: протестуйте 802.11r вкл/викл, перевірте затримки RADIUS і PMK caching.

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

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

Завдання 1: Згенерувати WLAN‑звіт (роуми, відключення, reason codes)

cr0x@server:~$ netsh wlan show wlanreport
WLAN report was written to: C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html

Що це означає: Windows створив HTML‑звіт з хронологією підключень, причинами відключень і інформацією про адаптер.
Рішення: Відкрийте звіт і шукайте повторювані відключення/роуми з однаковою періодичністю. Якщо бачите «Reason: The network is disconnected by the driver»
або багато подій roam, ви маєте справу з драйвером/роумінгом, а не з «втратою провайдера».

Завдання 2: Вивести стан інтерфейсу (BSSID, канал, швидкості)

cr0x@server:~$ netsh wlan show interfaces
There is 1 interface on the system:

    Name                   : Wi-Fi
    Description            : Intel(R) Wi-Fi 6 AX201 160MHz
    GUID                   : 2c3a6b2d-1f45-4a8b-9c0a-0f1b1c0d1234
    Physical address       : 34:ab:cd:ef:12:34
    State                  : connected
    SSID                   : CorpNet
    BSSID                  : a0:bb:cc:dd:ee:f0
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA2-Enterprise
    Connection mode        : Profile
    Channel                : 36
    Receive rate (Mbps)    : 866.7
    Transmit rate (Mbps)   : 780.0
    Signal                 : 72%
    Profile                : CorpNet

Що це означає: Ви бачите поточний AP (BSSID), діапазон (канал) і швидкості лінку.
Рішення: Коли станеться наступний «обрив», запустіть цю команду знову. Якщо BSSID зміниться — це роумінг.
Якщо швидкості різко падають перед обривом — підозрюйте RF/перешкоди або енергозбереження. Якщо сигнал сильний, але продуктивність погана — підозрюйте контенцію або баги steering.

Завдання 3: Переглянути збережені профілі і впевнитися, що ви не підключаєтесь до невірного SSID

cr0x@server:~$ netsh wlan show profiles
Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
    <None>

User profiles
-------------
    All User Profile     : CorpNet
    All User Profile     : CorpNet-Guest
    All User Profile     : CorpNet_24G

Що це означає: Існують кілька схожих профілів.
Рішення: Якщо бачите і «CorpNet», і «CorpNet_24G/5G», вирішіть, чи хочете ви явного вибору діапазону для тестування.
Якщо запам’ятовано гостьовий SSID з автопідключенням, він може «перемістити» вас на неправильну мережу на парковці.

Завдання 4: Перевірити поточний драйвер і версію (баги драйверів існують)

cr0x@server:~$ pnputil /enum-drivers | findstr /i wifi
Published Name : oem42.inf
Original Name  : Netwtw10.inf
Provider Name  : Intel
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 23.30.0.6
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Що це означає: Ви ідентифікуєте vendor INF і версію драйвера.
Рішення: Якщо у вас відома проблемна версія драйвера для вашого парку пристроїв, стандартизуйтеся на перевіреній версії.
Не оновлюйте «до останньої» всліпу, якщо ваше середовище чутливе; спочатку тестуйте.

Завдання 5: Перевірити можливості керування живленням і активний план (поведінка на батареї важлива)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Що це означає: У вас стоїть Balanced, який зазвичай дозволяє більш агресивне енергозбереження.
Рішення: Для діагностики тимчасово переключіться на High performance або встановіть Wireless Adapter Settings на Maximum Performance.
Якщо проблема зникає на живленні від мережі, але виникає на батареї — у вас взаємодія політики живлення/драйвера.

Завдання 6: Перевірити налаштування енергозбереження по адаптеру (режим енергозбереження бездротового адаптера)

cr0x@server:~$ powercfg /q 381b4222-f694-41f0-9685-ff5bb260df2e 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a | findstr /i "Current AC Power Setting Index"
Current AC Power Setting Index: 0x00000002

Що це означає: Числовий індекс відповідає режиму енергозбереження адаптера (залежить від збірки/драйвера), де вищий часто означає більше енергозбереження.
Рішення: Якщо ви шукаєте стабільність, установіть максимальну продуктивність для AC і DC під час діагностики.
Якщо це допомагає, пізніше можна тонше налаштувати, а не жити в режимі повного витрату батареї.

Завдання 7: Витягнути події WLAN AutoConfig (істина в часових мітках)

cr0x@server:~$ wevtutil qe Microsoft-Windows-WLAN-AutoConfig/Operational /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8001
  Level: Information
  Description:
    WLAN AutoConfig service has successfully connected to a wireless network.

Event[1]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8003
  Level: Warning
  Description:
    WLAN AutoConfig service has disconnected from a wireless network.
    Reason: The network is disconnected by the driver.

Що це означає: Ви бачите події підключення/відключення та причини без гадань.
Рішення: «Disconnected by the driver» вказує на проблему драйвера/прошивки/енергозбереження/роумінгу.
Якщо бачите «Explicit EAP failure», ви маєте справу з 802.1X/RADIUS.

Завдання 8: Порівняти безперервність на IP‑рівні (Wi‑Fi обривається, чи IP падає?)

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

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
   Physical Address. . . . . . . . : 34-AB-CD-EF-12-34
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.44.12.87(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, 10:12:01 AM
   Lease Expires . . . . . . . . . . : Monday, 06:12:01 PM
   Default Gateway . . . . . . . . . : 10.44.12.1
   DNS Servers . . . . . . . . . . . : 10.44.0.10
                                       10.44.0.11

Що це означає: Ви підтверджуєте DHCP, час оренди, шлюз, DNS.
Рішення: Якщо «обриви» корелюють з оновленням DHCP або зміною шлюзу, ви бачите IP‑чоргування, а не роумінг Wi‑Fi.
Якщо IP залишається стабільним, але додатки падають — дивіться роумінг/енергозбереження/VPN.

Завдання 9: Безперервний ping для виявлення мікро‑перерв (вимірюйте, а не інтуїтуйте)

cr0x@server:~$ ping -n 50 10.44.12.1
Pinging 10.44.12.1 with 32 bytes of data:
Reply from 10.44.12.1: bytes=32 time=3ms TTL=64
Reply from 10.44.12.1: bytes=32 time=4ms TTL=64
Request timed out.
Request timed out.
Reply from 10.44.12.1: bytes=32 time=5ms TTL=64

Ping statistics for 10.44.12.1:
    Packets: Sent = 50, Received = 48, Lost = 2 (4% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 48ms, Average = 6ms

Що це означає: Ви бачите короткі спайки втрат пакетів — класичний симптом роумінгу або RF‑повторів.
Рішення: Якщо втрата відбувається в 1–3‑секундних сплесках і збігається з логами, підозрюйте роумінг.
Якщо це тривала втрата без подій роумінгу — підозрюйте перешкоди/нестабільність AP.

Завдання 10: tracert, щоб перевірити, чи «обрив» відбувається вище по ланцюгу

cr0x@server:~$ tracert -d 8.8.8.8
Tracing route to 8.8.8.8 over a maximum of 30 hops

  1     3 ms     2 ms     3 ms  10.44.12.1
  2     6 ms     5 ms     6 ms  10.44.0.1
  3    12 ms    11 ms    13 ms  192.0.2.10
  4    14 ms    13 ms    14 ms  203.0.113.22
  5    16 ms    15 ms    16 ms  8.8.8.8

Trace complete.

Що це означає: Базова траса маршруту. Під час «обриву» це може впасти або змінитися.
Рішення: Якщо перший хоп (шлюз) відпадає під час обривів — це локальний Wi‑Fi/LAN. Якщо перший хоп в порядку, а дальші ланки падають — проблема upstream WAN/VPN/політики.

Завдання 11: Перевірити коливання інтерфейсу VPN (VPN може підсилювати біль від роумінгу)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Connected      Dedicated        Ethernet
Enabled        Connected      Dedicated        Wi-Fi
Enabled        Disconnected   Dedicated        MyCorp VPN

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

Завдання 12: Підтвердити можливості Wi‑Fi, які повідомляє драйвер (тут починаються нюанси 802.11r/ax)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/12/2025
    Version                   : 23.30.0.6
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Що це означає: Драйвер заявляє підтримувані стандарти та функції безпеки.
Рішення: Якщо ваша мережа використовує 802.11w або новіші стандарти, підтвердіть, що клієнт їх підтримує.
Невідповідності можуть спричинити деauth‑цикли або «підключення — потім обрив».

Завдання 13: Вимкнути й увімкнути адаптер, щоб очистити застряглий стан (хірургічно, не з суєти)

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

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

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

Завдання 14: Перевірити «липкий» DNS після роумінгу (Wi‑Fi ніби впав, але DNS говорить інше)

cr0x@server:~$ nslookup internal-service
Server:  10.44.0.10
Address: 10.44.0.10

Name:    internal-service.corp.example
Address: 10.44.20.15

Що це означає: DNS‑резолюція працює зараз.
Рішення: Якщо Wi‑Fi «обривається», але ping до шлюзу працює, а DNS не працює, проблема в резолюції імен,
captive portal або політиці split‑DNS/VPN — а не в roaming aggressiveness.

Керування в Windows, що впливає на стабільність (і чого уникати)

Де знаходиться Roaming Aggressiveness

Зазвичай: Device Manager → Network adapters → ваш Wi‑Fi адаптер → Properties → Advanced → Roaming Aggressiveness.
Іноді це називають «Roaming Sensitivity», «Roaming Decision» або «Roam Tendency».
Якщо не бачите — драйвер може не показувати цю опцію або OEM приховав її у власному пакеті.

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

Preferred Band: корисно, але небезпечно як постійний костиль

Встановлення «Preferred Band» на 5 GHz може зменшити перешкоди від 2.4 GHz, який фактично схожий на громадський парк, де всі кричать.
Але якщо покриття 5 GHz неповне, ви викличете більше роумів і маргінальних лінків.

Використовуйте preferred band як тестовий перемикач. Якщо примусово 5 GHz вирішує обриви — це натяк, що 2.4 GHz перевантажений або band steering AP збійний.
Тоді виправляйте мережу. Не приклеюйте всі ноутбуки до 5 GHz та не прикидайтеся, що «оптимізували».

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

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

Power Management: чекбокс, що зіпсує ваш день

Класика: «Allow the computer to turn off this device to save power». Це не завжди прямий винуватець, але може посилити проблеми драйвера.
Для діагностики вимкніть його. Якщо стабільність покращиться, вирішіть, чи важливіший час роботи від батареї, ніж відсутність обривів під час дзвінків.

802.11ax режим і функції типу «Throughput Booster»

Іноді вимкнення 802.11ax (примус 802.11ac) — законний обхідний шлях, коли прошивка AP і драйвер клієнта не погоджуються щодо OFDMA або поведінки енергозбереження.
Це не елегантно. Проте іноді ефективно.

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

Налаштування AP і мережі, що викликають некоректну поведінку Windows

Band steering: коли «розумно» означає вперто

Band steering працює, відмовляючи в асоціації на одному діапазоні, затримуючи відповіді або деаутхуючи клієнтів, щоб «підштовхнути» їх переміститися.
Це не роумінг — це примус. Windows може реагувати погано — особливо якщо roaming aggressiveness також висока і клієнт продовжує сканувати.

Якщо бачите повторні деauth, розгляньте послаблення агресивності steering, тимчасове розділення SSID або вимкнення steering на підмножині AP.
В корпоративних середовищах band steering часто менш передбачуваний, ніж просто правильний дизайн покриття 5 GHz.

802.11r (Fast BSS Transition): чудово, коли послідовно, жахливо при напівввімкненні

802.11r може суттєво зменшити час роумінгу, що важливо для голосових та реальних‑часових додатків.
Проблема — часткове розгортання: деякі AP підтримують, деякі — ні; деякі клієнти — так, деякі — ні; і отримуєте періодичні збої, що виглядають «випадково».

Ставтесь до 802.11r як до feature flag: або розгортайте коректно та тестуйте клієнти, або вимикайте.
«Ніби ввімкнено» — ідеальне джерело інцидентів.

802.11k/v: звіти про сусідів і керування клієнтами

802.11k допомагає клієнтам швидше знаходити кандидати для роумінгу. 802.11v може пропонувати клієнтам переміститися.
Windows і драйвери по‑різному використовують ці підказки. Якщо AP надто наполегливий з 11v, ви можете викликати роумінги, які клієнту не були потрібні.

DFS‑канали: потужні, але іноді пастка

DFS‑канали (у 5 GHz) дають чистіший спектр, але вимагають виявлення радарів.
Коли AP виявляє радар (або думає, що виявив), він повинен залишити канал. Клієнти відключаються й перепідключаються в інше місце. Користувач назве це «випадковими обривами».

Якщо обриви відбуваються пачками, і зачіпають багато клієнтів одночасно — перевіряйте події DFS на AP/контролері.
«Виправлення» може бути перемісити важливі SSID з DFS‑каналів у регіонах, схильних до радарів, а не міняти roaming aggressiveness.

Мінімальний RSSI і примусове відключення

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

Windows з високою roaming aggressiveness плюс агресивний мінімальний RSSI — ідеальна буря. Налаштуйте одне або інше, а не підтягуйте обидва до «максимальної суворості».

Таймери повторної автентифікації WPA2‑Enterprise і затримки RADIUS

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

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

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

Середня компанія розгорнула нову Wi‑Fi 6 мережу на двох поверхах. Пілот пройшов добре: кілька IT‑ноутбуків, кілька телефонів, чемний тестовий трафік.
Потім повернувся решта офісу. Відеодзвінки почали падати, а дашборд служби підтримки світився як новорічна ялинка.

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

Команда два дні ганялася за невірним шаром. Вони замінили крайовий фаєрвол (двічі), поміняли канал інтернет‑провайдера і сперечалися про DNS.
Видавало себе WLAN AutoConfig: події роумінгу збігалися з падінням дзвінків, хоча SSID не змінювався.

Виправлення не було героїчним. Вони зменшили перетин каналів, підкоригували потужність передачі AP, щоб зменшити розміри клітин, і зменшили roaming aggressiveness на один крок для найпроблемніших моделей.
Дзвінки перестали падати. Мережа не стала «сильнішою». Вона стала спокійнішою.

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

Інша організація мала блискуче mesh‑розгортання в модерному офісі — скляні стіни, відкриті стелі і так далі.
Хтось ввімкнув агресивний band steering, бо «5 GHz швидше», і встановив мінімальний RSSI, бо «липкі клієнти — погано».
Дві розумні ідеї, злиті в один нерозумний результат.

Ноутбуки біля межі покриття асоціювалися до 5 GHz, їх підштовхували, а потім викидали, коли RSSI трохи впав.
Вони падали на 2.4 GHz, їх знову steered, і так повторювалося. Користувачі описували це як «Wi‑Fi вмирає щоразу, коли я встаю».
Здавалося смішно, поки ми не відтворили це, відсунувши стілець назад.

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

Відновлення полягало в послабленні band steering, піднятті порога мінімального RSSI лише там, де покриття дійсно щільне, і припиненні примусу клієнтів ухвалювати ідеальні рішення в нерівній RF‑реальності.
Вони також стандартизували версії драйверів Windows, бо одна модель ноутбука мала баг роум‑лупу, що все погіршувало.

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

Фінансова фірма мала політику: при повідомленні про Wi‑Fi‑проблеми перший респондент мав збирати ті самі три артефакти — WLAN‑звіт, логи AutoConfig і 10‑хвилинний зразок ping/втрат до шлюзу.
Без винятків. Люди бурчали, бо це здавалося повільним. Насправді це запобігало тижневим полюванням на привидів.

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

Логи вказали на DFS‑вакуації каналів на кластері AP. Поряд розташований джерело радару почало тригерити виявлення.
Команда перемістила критичний SSID з DFS‑каналів для тієї зони і запланувала повне RF‑опитування.
Інцидент закрився швидко, бо докази збиралися послідовно, а не тому, що хтось мав містичну інтуїцію Wi‑Fi.

Жарт №2: Єдине, що більш випадкове за Wi‑Fi — це зустріч про те, чому Wi‑Fi був випадковим.

Цікавинки й історія, які стануть у нагоді в дискусіях

Роумінг Wi‑Fi за дизайном керує клієнт: історично 802.11 залишає рішення про роумінг за станцією (клієнтом), а не за AP.
Ранній корпоративний роумінг був повільним: до сучасних швидких переходів WPA2‑Enterprise роумінг часто вимагав повну автентифікацію, спричиняючи чутні VoIP‑глюки.
802.11r з’явився через вимоги голосових сервісів: Fast BSS Transition був просунутий реальними‑часовими додатками, які не можуть терпіти багатосекундні handshakes.
2.4 GHz має лише три неперекриваючі 20 MHz канали у багатьох регіонах: тому він заторний навіть коли «палички» виглядають добре.
DFS — це не «необов’язкова складність», це регулювання: AP мають покидати певні канали при виявленні радару, і це може виглядати як масові відключення.
RSSI — грубий інструмент: багато клієнтів все ще використовують силу сигналу як основний вхід для роумінгу, хоча важливіші перешкоди та використання повітряного часу.
Band steering не є стандартом: багато реалізацій — пропрієтарні поведінки поверх правил асоціації 802.11.
802.11k/v — це «підказки», не команди: клієнти можуть їх ігнорувати, і різні драйвери тлумачать їх по‑різному.
Логи Windows мережевих подій покращилися з часом: сучасні збірки роблять WLAN AutoConfig‑події та генерацію WLAN‑звітів доволі корисними — якщо їх читати.

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

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

«Він обривається кожні 10–20 хвилин, як по годиннику.»

Корінь: періодичні таймери реавтентифікації (WPA2‑Enterprise), проблеми DHCP‑renew або цикл енергозбереження драйвера.

Виправлення: зіставте часові мітки в WLAN AutoConfig логах і WLAN‑звіті. Якщо EAP‑події збігаються — налаштуйте таймери реавтентифікації та перевірте здоров’я RADIUS.
Якщо збігається DHCP — проаналізуйте поведінку оренд і шлюз DHCP. Якщо ні те, ні інше — тестуйте з вимкненим енергозбереженням адаптера.

«Він обривається, коли я рухаюсь між кімнатами.»

Корінь: затримка роумінгу, неправильно налаштований 802.11r або липкий клієнт.

Виправлення: для корпоративного середовища перевірте консистентність 11r і PMK caching; для побутового mesh — тимчасово розділіть SSID.
Якщо роум відбувається занадто пізно — трохи підвищте roaming aggressiveness; якщо занадто часто — знизьте.

«Сильний сигнал, але Teams постійно перепідключається.»

Корінь: ко‑канальна контенція, повтори або churn від band steering; RSSI виглядає нормально, але airtime насичений.

Виправлення: порівняйте швидкості лінку з часом і шукайте події роумінгу. Зменшіть агресивність band steering, підкоригуйте план каналів і уникайте надто широких каналів у щільних зонах.

«Тільки на батареї — жахливо.»

Корінь: режим енергозбереження адаптера і/або налаштування плану живлення Windows.

Виправлення: встановіть Wireless Adapter Settings на Maximum Performance на батареї для тесту; вимкніть NIC power‑saving у Device Manager; повторно перевірте.

«Почалося після ввімкнення WPA3 / захисту керувальних кадрів.»

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

Виправлення: перевірте можливості через netsh wlan show drivers і стандартизуйте версії драйверів. Розгорніть тестовий SSID з WPA2 тільки, щоб підтвердити.

«Всі одночасно відключаються.»

Корінь: перезавантаження/впав AP, DFS‑вакуація, проблема контролера, upstream LAN/WAN outage.

Виправлення: припиніть чіпати клієнтів. Дістаньте логи AP/контролера щодо DFS‑подій, перезавантажень або змін каналів. Перевірте здоров’я шлюзу і помилки портів комутатора.

«Лише на одній моделі ноутбука.»

Корінь: регресія версії драйвера, OEM‑пакет драйвера або несумісність конкретної просунутої функції.

Виправлення: порівняйте версії драйверів через pnputil. Откатіть або стандартизуйте. Вимкніть просунуті функції типу throughput booster для цієї моделі.

«Він ‘обривається’, але Wi‑Fi показує підключено.»

Корінь: проблеми DNS, перехоплення captive portal, перевстановлення тунелю VPN або upstream маршрутизація/політика.

Виправлення: протестуйте ping до шлюзу + DNS‑запит під час події. Якщо ping до шлюзу в порядку, а DNS — ні, виправляйте DNS/VPN split‑DNS/captive portal правила.

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

Покроково: стабілізувати Windows‑ноутбук, що «раптом обривається»

Спочатку зберіть докази.
Згенеруйте WLAN‑звіт і витягніть останні 10–50 AutoConfig‑подій. Запишіть часову мітку видимого користувачем обриву.
Підтвердіть, чи це роумінг.
Перевірте, чи змінюється BSSID навколо події. Якщо так — роумінг задіяний. Якщо ні — дивіться енергозбереження, повтори і IP‑рівень.
Вимкніть легкі «винуватці» для контрольованого вікна тесту (30–60 хвилин).
Приберіть чекбокс енергозбереження адаптера; встановіть Wireless Adapter Settings на Maximum Performance; вимкніть будь‑які «бустери».
Підкоригуйте Roaming Aggressiveness на одну позицію.
Якщо роумів багато без руху — зменшуйте. Якщо клієнт тримається за слабкий AP під час переміщення — підвищуйте (обережно).
Перевірте припущення про band steering.
Якщо у вас побутовий mesh — тимчасово розділіть SSID по діапазонах. Якщо стабільність покращиться — проблема в steering, а не в Windows.
Стандартизуйте версії драйверів.
Виберіть відому‑добру версію для вашого середовища. Оновлюйте/відкатуйте групами, а не поодинці.
Якщо корпоративна 802.1X: перевірте таймери реавтентифікації, затримки RADIUS і функції швидкого роумінгу (11r/OKC/PMK caching).
Після змін перегляньте логи ще раз.
Ви хочете менше подій відключення, менше thrash‑роумінгів і знижені сплески втрат пакетів.

Чеклист: ознаки, що варто налаштувати roaming aggressiveness (на боці клієнта)

Роумінги відбуваються, коли користувач нерухомий.
Кілька AP видно з подібною силою сигналу (щільне розгортання, відкритий офіс).
Події відключення/підключення показують driver‑initiated disconnects без очевидної втрати RF.
Увімкнено band steering і клієнт часто змінює канали/діапазони.

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

Багато клієнтів падає одночасно.
Логи AP показують DFS‑вакуації, перезавантаження або зміну каналів у час падінь.
Доступність шлюзу падає для дротових і бездротових клієнтів одночасно.
Помилки RADIUS/автентифікації з’являються у користувачів у той самий проміжок часу.

FAQ

1) Де саме знаходиться «Roaming Aggressiveness» у Windows?

Зазвичай у Device Manager → Network adapters → (ваш Wi‑Fi адаптер) → Properties → Advanced tab.
Якщо її там немає — ваш драйвер/OEM‑пакет може її не показувати. У такому разі вибір версії драйвера набуває ще більшого значення.

2) Який вибрати режим: Lowest, Medium, Highest?

Для ноутбука, що стоїть на столі у стабільній мережі, початкова точка — один крок нижче за дефолт.
Lowest може викликати проблему липких клієнтів при русі. Highest схильний створювати churn роумів у щільних розгортаннях.

3) Чому обривається при сигналі 80–90%?

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

4) Це проблема Windows чи Wi‑Fi мережі?

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

5) Чи варто відключити 802.11ax (Wi‑Fi 6), щоб виправити обриви?

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

6) Чи допоможе розділення SSID (2.4 і 5 GHz)?

Може. Це чудовий діагностичний інструмент для виявлення churn band steering.
Для довготривалої роботи це компроміс: більше контролю, але більше плутанини для користувачів і більше супроводу.

7) Мій VPN падає при роумінгу Wi‑Fi. Це нормально?

Це часто. Багато VPN‑клієнтів трактують короткі переривання інтерфейсу як «мережа змінилася» і ініціюють перевстановлення.
Виправлення — швидший роумінг (11r правильно налаштований) або налаштування VPN на толерантність коротких збоїв — а не просто «відключити роумінг».

8) Який найкращий лог для першого перегляду?

WLAN‑звіт від netsh wlan show wlanreport, бо він дає хронологію, яку можна зіставити з відчуттям користувача.
Поєднуйте з WLAN AutoConfig подіями для коду причин.

9) Чи може Bluetooth спричиняти падіння Wi‑Fi?

Іноді, особливо у 2.4 GHz через проблеми співіснування. Якщо примусове 5 GHz або 6 GHz усуває проблему — видно сильну підказку.
Тоді виправляйте використання каналів/діапазонів, а не звинувачуйте «Windows».

10) Якщо я знизжу roaming aggressiveness, чи можу щось зламати?

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

Наступні кроки, що справді працюють

Якщо ви хочете найкоротший шлях до меншої кількості Wi‑Fi «обривів», зробіть це в такому порядку:

Згенеруйте WLAN‑звіт і витягніть WLAN AutoConfig події. Підтвердіть, чи це роумінг, відключення або просто втрата IP/DNS.
Запустіть netsh wlan show interfaces до й після обриву. Слідкуйте за змінами BSSID і зсувами каналу/швидкості.
Тимчасово вимкніть енергозбереження адаптера і встановіть Wireless Adapter Settings на Maximum Performance. Якщо стабільність повернеться — ви знайшли важіль.
Зменшіть Roaming Aggressiveness на одну позицію, якщо бачите thrash роумінг у нерухомому користувачі.
Якщо у вас mesh із «smart connect», протестуйте розділення SSID. Якщо це допомагає — підлаштуйте steering, а не карайте клієнта.
Стандартизуйте й протестуйте версії драйверів Wi‑Fi у вашому парку. Випадковість часто має номер версії.

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