Wi‑Fi відключається кожні 10 хвилин: розширене налаштування драйвера, що виправляє це

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

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

Ви на відеодзвінку. Вас чутно, допоки — ніби метроном — ваш Wi‑Fi не відключається. Через десять хвилин він повертається. Ще через десять хвилин знову відключення. Ви перезавантажуєте роутер, лаятися на роутер, зсуваєтеся на три фути вліво, і на момент вам здається, що проблема вирішена.

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

Єдине розширене налаштування драйвера, яке найчастіше це виправляє

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

Вимкнути енергозбереження на боці клієнта Wi‑Fi (U‑APSD / SMPS / «Режим енергозбереження»)

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

У Windows це зазвичай два місця:

Керування живленням адаптера: «Дозволити комп’ютеру вимикати цей пристрій для економії енергії» (Диспетчер пристроїв → ваш Wi‑Fi адаптер → Властивості → Керування живленням).
Розширені параметри драйвера (Диспетчер пристроїв → Властивості → Додатково): «Power Save Mode», «MIMO Power Save Mode», «U‑APSD support», «Minimum Power Consumption», «Transmit Power» або «Prefer maximum performance».

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

Невеликий жарт, як освіжувач смаку: енергозбереження Wi‑Fi — як «eco mode» у спортивного автомобіля — класно в брошурі, жахливо в трафіку.

Чому «кожні 10 хвилин» трапляється у Wi‑Fi

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

Інтервали повторної зміни групового ключа (Group Key Rekey) у WPA2/WPA3 enterprise часто вимірюються хвилинами. У деяких середовищах їх встановлюють агресивно, і деякі драйвери клієнта погано обробляють перехід.
802.1X повторна автентифікація може плануватися, і якщо шлях авторизації хиткий, «оновлення» виглядає як відключення.
Оновлення DHCP-оренди зазвичай довші за 10 хвилин, але неправильно сконфігуровані мережі (особливо гостьові VLAN) можуть використовувати короткі оренди.
Фонове сканування драйвера і алгоритми роумінгу іноді працюють за періодичними таймерами і можуть викликати короткі розриви, що стають помітними для чутливих додатків.
Тіки енергоменеджменту можуть узгоджуватися з політиками ОС (режим економії батареї, Modern Standby, селективне призупинення NIC).

Факти та історія (бо у налаштувань є «багаж»)

Ось конкретні контекстні моменти, які пояснюють, чому ваша «проста Wi‑Fi» проблема насправді — купа рішень, прийнятих за 25 років:

Енергозбереження 802.11 існує з раннього Wi‑Fi, але сучасні реалізації розширили його механізмами, такими як WMM Power Save (U‑APSD), щоб зменшити затримку для голосу, при цьому спати між кадрами.
WPA2 (2004) нормалізував періодичну зміну ключів як засіб гігієни безпеки; «обертання ключів» — хороша практика, доки багатий клієнт не робить це подією під’єднання.
Band steering став поширеним із поширенням двох- і трьохдіапазонних AP; клієнтів можна заохочувати (або примушувати) переходити на 5 GHz/6 GHz, але деякі драйвери інтерпретують steering як нестабільність.
802.11k/v/r допоміжні механізми роумінгу існують, щоб зробити роумінг плавнішим; напівреалізовані функції можуть натомість створювати цикл спроб роумінгу.
Windows «Modern Standby» змінив семантику сну; він ближчий до «завжди увімкнено, завжди підключено», що створює більше навантаження на стани живлення NIC та коректність драйвера.
Драйвери клієнтів часто поставляються з OEM‑налаштуваннями, оптимізованими для тестів батареї, а не для вашого VPN + відеодзвінка + нестабільного AP набору.
Enterprise Wi‑Fi любить таймери, бо любить політику. Таймери не злі; вони просто дуже буквальні.
6 GHz (Wi‑Fi 6E) додає AFC і регуляторну складність в окремих регіонах і робить «сканувати все» дорожчим для клієнтів.

Швидкий план діагностики

Мета — швидко знайти вузьке місце: драйвер клієнта, RF/оточення, політика AP або мережа вгору. Не гадати. Зберіть докази за 10–15 хвилин.

Перше: доведіть, що це рівень посилання Wi‑Fi, а не «інтернет»

Запустіть безперервний ping до шлюзу за замовчуванням. Якщо він падає, ваше посилання розривається локально (RF, драйвер, AP). Якщо шлюз стабільний, але зовнішні цілі падають — підозрюйте WAN/VPN/DNS.
Слідкуйте за станом асоціації: чи клієнт роз’єднується і перепідключається (новий BSSID, нова автентифікація), або залишається асоційованим, але «зависає»?

Друге: шукайте періодичність і точну подію

У Windows згенеруйте WLAN‑звіт і прочитайте коди «Причина відключення».
У Linux перегляньте журнали journald на предмет deauth/disassoc причин і перемикань енергозбереження.

Третє: змініть один параметр клієнта, що вимикає енергозбереження

Вимкніть керування живленням Wi‑Fi адаптера у Диспетчері пристроїв і на вкладці Додатково драйвера.
Примусьте «Максимальну продуктивність» (додаткові параметри плану живлення Windows для Wireless Adapter Settings).

Четверте: якщо все ще періодично, перевірте таймери повторної авторизації/реки

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

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

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

Завдання 1 (Windows): Визначити адаптер, версію драйвера та виробника

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter -Physical | Where-Object {$_.Status -eq 'Up'} | Format-Table -Auto Name, InterfaceDescription, LinkSpeed"
Name   InterfaceDescription                      LinkSpeed
Wi-Fi  Intel(R) Wi-Fi 6 AX200 160MHz             780 Mbps

Що це означає: Підтверджує, який адаптер активний. «Intel AX200» та подібні мають специфічну поведінку енергозбереження та роумінгу.

Рішення: Сфокусуйте налаштування на цьому адаптері; не витрачайте час на віртуальні адаптери.

Завдання 2 (Windows): Отримати детальну інформацію про драйвер

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.FriendlyName -like '*Wi-Fi*'} | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion"
InstanceId  : PCI\VEN_8086&DEV_2723&SUBSYS_00848086&REV_1A\3&11583659&0&10
Data        : 23.60.1.2
Type        : String

Що це означає: Версія драйвера. Деякі періодичні відключення — це баги драйверів, а не ваша уява.

Рішення: Якщо ви відстаєте на кілька великих версій, оновіть. Якщо ви на найновішій і стало гірше — відкотіть на відому стабільну OEM‑пакетну версію.

Завдання 3 (Windows): Згенерувати та відкрити WLAN‑звіт

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

Що це означає: Windows створив HTML‑звіт про асоціації, відключення та причини.

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

Завдання 4 (Windows): Перелічити профілі Wi‑Fi і перевірити політику

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

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

User profiles
-------------
    All User Profile     : CorpWiFi
    All User Profile     : GuestWiFi

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

Рішення: Якщо корпоративний профіль застосовується централізовано, очікуйте 802.1X таймери та контролер‑керовані зміни; збирайте докази перед тим, як «виправляти».

Завдання 5 (Windows): Дивитися події WLAN AutoConfig для причини відключення

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-WLAN-AutoConfig/Operational -MaxEvents 5 | Select-Object TimeCreated, Id, Message | Format-List"
TimeCreated : 2/4/2026 9:12:10 AM
Id          : 8003
Message     : WLAN AutoConfig service has disconnected from a wireless network. Reason: The network is disconnected by the driver.

TimeCreated : 2/4/2026 9:12:12 AM
Id          : 8001
Message     : WLAN AutoConfig service has successfully connected to a wireless network.

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

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

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

cr0x@server:~$ powercfg /q | findstr /i "Wireless Adapter Settings"
Subgroup GUID: 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1  (Wireless Adapter Settings)
Power Setting GUID: 12bbebe6-58d6-4636-95bb-3217ef867c1a  (Power Saving Mode)

Що це означає: Підтверджує, що Windows керує Wi‑Fi енергоспоживанням як частиною плану живлення.

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

Завдання 7 (Linux): Визначити Wi‑Fi пристрій, драйвер і прошивку

cr0x@server:~$ sudo lspci -nnk | sed -n '/Network controller/,+4p'
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
	Subsystem: Intel Corporation Device [8086:0084]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Що це означає: Підтверджує драйвер ядра. Intel використовує iwlwifi; Realtek часто використовує rtw88/rtl8xxx; Qualcomm Atheros — ath10k/ath11k.

Рішення: Застосуйте специфічні для драйвера переключувачі (iwlwifi power_save тощо).

Завдання 8 (Linux): Перевірити поточний стан енергозбереження

cr0x@server:~$ iw dev wlan0 get power_save
Power save: on

Що це означає: Енергозбереження увімкнене на рівні mac80211.

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

Завдання 9 (Linux): Негайно вимкнути енергозбереження (runtime)

cr0x@server:~$ sudo iw dev wlan0 set power_save off
cr0x@server:~$ iw dev wlan0 get power_save
Power save: off

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

Рішення: Протестуйте принаймні 30 хвилин. Якщо 10‑хвилинні відключення зникли, зробіть це постійним (наступні завдання).

Завдання 10 (Linux + NetworkManager): Переконатися, що NM не вмикає powersave знову

cr0x@server:~$ sudo nmcli -f WIFI.POWERSAVE general
WIFI.POWERSAVE: 3 (enabled)

Що це означає: NetworkManager налаштований вмикати powersave (значення 3). Це може перевизначати ручні iw‑перемикання.

Рішення: Встановіть значення 2 (disabled) для тестування стабільності.

Завдання 11 (Linux + NetworkManager): Вимкнути NM Wi‑Fi powersave постійно

cr0x@server:~$ sudo bash -lc 'cat >/etc/NetworkManager/conf.d/wifi-powersave-off.conf <<EOF
[connection]
wifi.powersave = 2
EOF
systemctl restart NetworkManager'

Що це означає: Постійно відключає Wi‑Fi powersave у NetworkManager і перезапускає його.

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

Завдання 12 (Linux): Перевірити журнали навколо відключення

cr0x@server:~$ sudo journalctl -u NetworkManager --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop NetworkManager[1023]: <info>  [1707047530.1234] device (wlan0): supplicant interface state: completed -> disconnected
Feb 04 09:12:10 laptop NetworkManager[1023]: <warn>  [1707047530.1256] device (wlan0): link timed out.
Feb 04 09:12:12 laptop NetworkManager[1023]: <info>  [1707047532.8899] device (wlan0): supplicant interface state: disconnected -> scanning
Feb 04 09:12:14 laptop NetworkManager[1023]: <info>  [1707047534.2222] device (wlan0): supplicant interface state: scanning -> associating
Feb 04 09:12:16 laptop NetworkManager[1023]: <info>  [1707047536.3333] device (wlan0): supplicant interface state: associating -> completed

Що це означає: Показує послідовність: completed → disconnected → scanning → associating. Якщо це повторюється по таймеру, підозрюйте powersave або безпекову повторну авторизацію.

Рішення: Поєднайте це з повідомленнями wpa_supplicant (наступне завдання), щоб побачити, чи є причина deauth.

Завдання 13 (Linux): Переглянути повідомлення wpa_supplicant щодо причин деавтентифікації

cr0x@server:~$ sudo journalctl -t wpa_supplicant --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-DISCONNECTED bssid=aa:bb:cc:dd:ee:ff reason=4 locally_generated=1
Feb 04 09:12:12 laptop wpa_supplicant[1122]: wlan0: SME: Trying to authenticate with aa:bb:cc:dd:ee:ff (SSID='CorpWiFi' freq=5180 MHz)
Feb 04 09:12:14 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-CONNECTED - Connection to aa:bb:cc:dd:ee:ff completed [id=0 id_str=]

Що це означає: «locally_generated=1» часто вказує на рішення, прийняте на боці клієнта (роумінг, енергозбереження, драйвер). «reason=4» у багатьох контекстах — «відключено через неактивність», класичний запах невідповідності енергозбереження.

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

Завдання 14 (будь‑яка ОС): Доведіть, чи шлюз падає під час події

cr0x@server:~$ ping -n 200 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.14 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.06 ms
Request timeout for icmp_seq 63
Request timeout for icmp_seq 64
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=2.44 ms

Що це означає: Якщо шлюз за замовчуванням падає, то це не «DNS» чи «ISP». Це локальна Wi‑Fi зв’язність.

Рішення: Сфокусуйтеся на RF/драйвер/подіях асоціації AP, а не на зовнішньому маршруту.

Завдання 15 (будь‑яка ОС): Перевірити, чи ви роумите між AP або діапазонами

cr0x@server:~$ iw dev wlan0 link
Connected to aa:bb:cc:dd:ee:ff (on wlan0)
	SSID: CorpWiFi
	freq: 5180
	signal: -62 dBm
	rx bitrate: 780.0 MBit/s
	tx bitrate: 585.0 MBit/s

Що це означає: Показує BSSID і частоту. Якщо після відключення BSSID змінюється — ви роумите (можливо через band steering або погані пороги сигналу).

Рішення: Зменшіть агресивність роумінгу на клієнті або покращіть розміщення AP / вимкніть надто агресивний steering.

Windows: регулятори драйвера, що мають значення (і ті, що — ні)

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

Шар 1: Диспетчер пристроїв → вкладка Керування живленням

Налаштування: «Дозволити комп’ютеру вимикати цей пристрій для економії енергії.»

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

Чому це допомагає: Це грубий інструмент. Він запобігає селективному призупиненню NIC Windows. Селективне призупинення працює до того моменту, поки драйвер/прошивка не пропустять пробудження або не втратять стан.

Шар 2: План живлення → Параметри бездротового адаптера

Налаштування: Power Saving Mode: Maximum Performance проти Medium/Low Power Saving.

Робити: Встановіть обидва «На батареї» і «Підключено» на Maximum Performance під час діагностики. Якщо це допоможе, згодом вирішуйте, чи пом’якшувати «На батареї».

Шар 3: Розширені налаштування драйвера (основні джерела проблем)

Тут часто вирішуються періодичні відключення. Назви у виробників різні, але шукайте такі налаштування:

Power Save Mode / Minimum Power Consumption: встановити Off / Disabled.
MIMO Power Save Mode (SMPS): встановити No SMPS / Disabled (назви різняться). Агресивний SMPS може створювати дивні збої пропускної здатності; в деяких середовищах це виглядає як відключення.
U‑APSD / WMM Power Save: вимкнути для тесту. Якщо важливий голос/затримка, можна знову ввімкнути після стабілізації.
Roaming Aggressiveness: встановити Lowest (або Medium‑Low). Висока агресивність роумінгу — «драми королева»; вона постійно сканує і «покращує» вас до відключення.
Preferred Band: зафіксувати на 5 GHz (або 6 GHz, якщо стабільно), щоб уникнути band steering петель. Або тимчасово зафіксувати на 2.4 GHz, якщо тестуєте діапазон/RF.
Transmit Power: встановити Highest. Знижена потужність TX може спричинити асиметричні канали, коли ви чуєте AP, але AP не чує вас надійно.

Два налаштування, які люди люблять крутити, але рідко виправляють 10‑хвилинні відключення:

Перемикання режимів 802.11n/ac/ax може допомогти з сумісністю, але це не перша справа, якщо AP старий або проблемний.
Параметри ширини каналу впливають на пропускну здатність і інтерференцію; це другорядна тонка настройка, не головна при періодичних відключеннях.

Як перевірити виправлення (не довіряйте відчуттям)

Після змін перевірте три речі:

Події WLAN AutoConfig перестають показувати відключення, ініційовані драйвером.
Безперервний ping до шлюзу більше не має просідань кожні 600 секунд.
Ваш BSSID/частота залишаються стабільними (якщо ви фізично не рухаєтеся).

Linux: iwlwifi/ath* powersave, NetworkManager і реальність

Linux дає чесність: журнали скажуть, що сталося, і зроблять це о 2 ранку, коли ви намагаєтеся спати. Але Linux також дає вибір, і деякі з цих виборів — «так, система знову ввімкне powersave, бо хтось вважав це ввічливим».

Енергозбереження на боці клієнта: три перемикачі, один результат

mac80211 powersave через iw (runtime, на інтерфейс)
NetworkManager wifi.powersave (політика, постійна)
Параметри модуля драйвера (наприклад, iwlwifi power_save)

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

Параметри модуля iwlwifi (Intel)

Intel‑адаптери поширені і загалом хороші, але вони також складні. Функції енергозбереження можуть взаємодіяти з особливостями AP. Стабільна база для діагностики: powersave off, без дивних експериментальних функцій і актуальна прошивка.

cr0x@server:~$ sudo modinfo iwlwifi | grep -E "parm:|firmware"
firmware:       iwlwifi-cc-a0-77.ucode
parm:           power_save:Enable power save (default: true)
parm:           uapsd_disable:Disable U-APSD (default: false)

Що це означає: Показує параметри модуля. Якщо бачите uapsd_disable, це підказка, що можна протестувати вимкнення U‑APSD на рівні драйвера.

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

cr0x@server:~$ sudo bash -lc 'cat >/etc/modprobe.d/iwlwifi-powersave-off.conf <<EOF
options iwlwifi power_save=0 uapsd_disable=1
EOF
update-initramfs -u'
update-initramfs: Generating /boot/initrd.img-6.5.0-18-generic

Що це означає: Зберігає налаштування iwlwifi між перезавантаженнями (оновлення initramfs показане для Debian/Ubuntu‑подібних систем).

Рішення: Перезавантажте і підтвердіть, що відключення припинилися. Якщо стабільність покращилась — ви ідентифікували взаємодію AP+U‑APSD або поведінку прошивки.

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

Роутер/AP: таймери та функції, що створюють періодичні відключення

Налаштування клієнта виправляє дивовижну кількість випадків. Але іноді AP той, хто чемно виганяє вас кожні 10 хвилин — у відповідності зі стандартом і з кодом причини, який ніхто не читає.

Поширені причини на стороні AP періодичних відключень

Інтервал Group Key Rekey занадто короткий або клієнт некоректно обробляє перехід ключа.
802.1X повторна автентифікація з ненадійним RADIUS‑шляхом або неправильними значеннями таймауту сесії.
Таймаут неактивності, що не враховує клієнтів у режимі енергозбереження (AP думає, що ви неактивні; ви думаєте, що спите ввічливо).
Band steering, який постійно намагається перемістити вас між діапазонами, особливо коли той самий SSID на 2.4 і 5 GHz має агресивні пороги.
Балансування навантаження / client steering, налаштоване для щільних офісів, а не для домашнього офісу, де «перемістити клієнта» означає «відключити його».
WPA3 transition mode дивності (змішаний WPA2/WPA3), особливо з старішими драйверами.

Як визначити, що це політика AP без доступу до AP

З боку клієнта ви все одно можете багато чого вивести:

Якщо журнали показують деавтентифікацію/дисасоціацію, ініційовану AP (locally_generated=0 у Linux; «Reason: received deauthentication from AP» у Windows), підозрюйте таймери/steering AP.
Якщо клієнт перепідключається до з новою рукопотиском кожні ~10 хвилин — підозрюйте реавтентифікацію/переключення ключа/таймаут неактивності.
Якщо клієнт перепідключається до іншого BSSID або діапазону, підозрюйте steering або пороги роумінгу.

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

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

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

Фінансовий відділ поскаржився, що «інтернет відмирає кожні десять хвилин» під час закриття місяця. Ця фраза — пастка: вона спонукає всіх дивитися на графіки фаєрвола та ISP‑канали. Ми так і зробили. Все виглядало нормально. Ніякої втрати пакетів на WAN, жодних тривожних збоїв, нічого очевидного.

Хтось нарешті запустив безперервний ping до офісного шлюзу з одного з уражених ноутбуків. Ping був чистим 1–2 мс… допоки рівно через десять хвилин після останнього відключення він не пішов у нуль на 10–15 секунд. WAN цього ніколи не бачив, бо клієнт взагалі не був у локальній мережі під час події. «Інтернет» був невинний.

Неправильне припущення було тонким: ми припустили, що помилки додатка означають проблеми вгорі. Але журнали (WLAN AutoConfig) сказали «відключено драйвером». Це не проблема ISP. Це ваше радіо, ваш драйвер, ваш стан живлення.

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

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

Інша організація хотіла кращої автономності батареї по флоту. Розумно. Вони ввімкнули енергозбереження Wi‑Fi і підвищили агресивність роумінгу, бо люди ходили по будівлі і скаржилися на «залипання» з’єднань. Також розумно, на папері.

Потім почалися звернення до служби підтримки: «Wi‑Fi відключається під час дзвінків». Шаблон був дивний — найпомітніший у Zoom/Teams, менш помітний у веб‑браузингу. Класична симптоматика мікро‑перерв і подій повторної авторизації: TCP‑повторні спроби ховають це; реальний час медіа цього не ховає.

Ми витягли журнали з кількох машин і знайшли періодичні відключення, ініційовані драйвером. Не постійні, не випадкові. Періодичні. Налаштування агресивності роумінгу спричиняло часті сканування і спроби роумінгу у середовищі з увімкненим band steering. Клієнт постійно намагався «покращити» свій стан і врешті‑решт постійно переключався/переключав ключі. Він оптимізував одну метрику (швидкість роумінгу) в шкоду тому, що людям важливіше (стабільність).

Виправлення: ми знизили агресивність роумінгу до «Low», вимкнули U‑APSD на певних версіях драйверів і зменшили агресивність steering на voice SSID. Автономність трохи впала. Якість дзвінків значно покращилась. Урок не «ніколи не оптимізуйте». Урок — «оптимізуйте одну змінну за раз і вимірюйте правильний результат».

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

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

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

Вони зібрали WLAN‑звіт з Windows клієнтів, плюс журнали контролера для подій деавтентифікації. Часи відключень співпали з періодичним пушем політики безпеки, який примушував повторну автентифікацію для підмножини користувачів. Це не відбувалося у всіх, бо політика застосовувалася лише до певних VLAN і груп ідентичностей. Ця деталь була важливою.

Виправлення: вони відкоригували поведінку повторної автентифікації, щоб вона не різко розривала активні сесії, і провели поетапний rollout. Апаратура Wi‑Fi лишилася та сама. Клієнти — ті самі. Різниця була у контролі змін і кореляції. Непомітно, ефективно, повторювано.

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

Це шаблони, які я бачу багаторазово — особливо коли інтервал відключень підозріло регулярний.

1) Відключення приблизно кожні 10 хвилин тільки на батареї

Симптом: Стабільно при живленні від мережі, періодичне відключення на батареї.

Корінь проблеми: Режим енергозбереження бездротового адаптера змінюється разом з планом живлення; селективне призупинення/U‑APSD/SMPS стає агресивним.

Виправлення: Встановіть бездротове енергозбереження на Maximum Performance на батареї; вимкніть керування живленням NIC; вимкніть Power Save Mode/U‑APSD драйвера для тестування.

2) Відключення приблизно кожні 10 хвилин на одному SSID, але не на іншому

Симптом: Гостьовий Wi‑Fi в порядку; корпоративний Wi‑Fi відключається (або навпаки).

Корінь проблеми: Політика, що прив’язана до SSID: 802.1X повторна автентифікація, інтервал rekey для групового ключа, band steering або функції контролера.

Виправлення: Порівняйте журнали: чи AP деавтентифіковує вас? Якщо так — відрегулюйте reauth/rekey/steering на тому SSID або протестуйте з WPA2‑only/WPA3‑only режимом.

3) «Інтернет відключається», але ping до шлюзу стабільний

Симптом: Дзвінок у Teams обривається, але ви все ще можете пінгувати роутер.

Корінь проблеми: Проблема вгорі: DNS, перевід VPN, таймаути сесій фаєрвола або WAN‑сплески — не асоціація Wi‑Fi.

Виправлення: Захопіть паралельний ping до зовнішнього IP і час відповіді DNS. Дивіться логи VPN‑клієнта або журнали WAN роутера.

4) Відключення корелюють з роумінгом між AP

Симптом: BSSID змінюється навколо відключення; можливо, ви навіть не рухаєтесь.

Корінь проблеми: Надто агресивний роумінг на клієнті + steering AP + маргінальний сигнал.

Виправлення: Знизьте агресивність роумінгу; зафіксуйте бажаний діапазон; покращіть розміщення AP; вимкніть steering для цього SSID.

5) Відключення відбуваються з фіксованим інтервалом на багатьох пристроях

Симптом: Багато користувачів повідомляють подібні періодичні відключення, часто синхронізовано.

Корінь проблеми: Таймер/політика інфраструктури: reauth, rekey, планова оптимізація RF, баг контролера або періодичні перешкоди.

Виправлення: Зіставте з журналами контролера/AP. Змініть один таймер за раз і розгортайте поступово.

6) Ви «виправили» це зміною каналів, але проблема повернулась

Симптом: Зміна каналу допомагає тимчасово; періодичність повертається.

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

Виправлення: Не ганяйтесь за каналами спочатку. Доведіть події на рівні посилання; вимкніть енергозбереження клієнта; потім повертайтеся до RF.

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

Покроково: план «мені потрібно це стабільно сьогодні»

Виміряйте відмову: Запустіть ping до шлюзу за замовчуванням на 20 хвилин і зауважте, чи він падає за розкладом.
Зберіть журнали клієнта: WLAN‑звіт Windows або journald/wpa_supplicant журнали Linux для причин відключення.
Вимкніть енергозбереження клієнта:
- Windows: зніміть «Дозволити комп’ютеру вимикати цей пристрій», встановіть Wireless Adapter Settings на Maximum Performance, вимкніть Power Save Mode/U‑APSD драйвера.
- Linux: iw ... set power_save off, вимкніть NetworkManager wifi.powersave.
Зменшіть трі́ни роумінгу: Встановіть roaming aggressiveness на Low; зафіксуйте бажаний діапазон, якщо задіяно steering.
Повторно тестуйте 30–60 хвилин: Якщо 10‑хвилинний ритм зник — збережіть налаштування й задокументуйте.
Якщо все ще не вдається: Підозрюйте таймери rekey/reauth та політику AP; протестуйте на іншому SSID або хотспоті, щоб ізолювати клієнта від мережі.

Чек‑лист: докази для передачі ІТ/мережній команді

Точний інтервал (наприклад, 600 секунд) і мітки часу щонайменше трьох відключень.
Журнали клієнта, що показують, чи відключення ініційоване драйвером або AP.
BSSID/частота до і після відключення (докази роумінгу).
Чи падає ping до шлюзу (рівень посилання vs upstream).
Версія драйвера та версія ОС.
Чи відтворюється проблема в іншій мережі (тест з мобільним хотспотом дає швидку ізоляцію).

Чек‑лист: чого не робити

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

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

1) Чому воно відключається точно кожні 10 хвилин?

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

2) Яке єдине найпоширеніше налаштування драйвера, що виправляє періодичні відключення?

Вимкнення агресивного енергозбереження Wi‑Fi (Power Save Mode / U‑APSD / MIMO power save) і примус до максимальної продуктивності. Це усуває цілу категорію граничних випадків сну/пробудження.

3) Чи зіпсує вимкнення енергозбереження мій час роботи від батареї?

Це може трохи зменшити час автономної роботи, особливо на ноутбуках. Але якщо вибір — «стабільне підключення» проти «можливо 5–10% батареї» — оберіть стабільність спочатку, а потім обережно налаштовуйте назад.

4) Чи може це бути проблемою DNS?

Так, але DNS рідко відмовляє з ідеальним десятихвилинним каденсом. Якщо ваш ping до шлюзу падає — це не DNS. Якщо ping до шлюзу в порядку, але запити імен — ні, тоді досліджуйте DNS.

5) Мій Wi‑Fi каже «Підключено, захищено», коли воно відключається. Як так?

Інтерфейс — не пакетний капчер. Ви можете залишатися асоційованими, поки шлях даних зависає через буферизацію енергозбереження, баги драйвера або події політики вгорі. Довіряйте журналам і ping‑ам більше, ніж іконкам.

6) Чи це частіше трапляється з певними чіпсетами?

Періодичні відключення можуть трапитися з будь‑ким, але вони часто фіксуються на певних Intel і Realtek ноутбучних модулях, коли OEM‑профілі живлення та U‑APSD/SMPS за умов збігаються з певними AP.

7) Чи варто вимкнути WPA3 для виправлення цього?

Лише як контрольний тест. Режим переходу WPA3 (змішаний WPA2/WPA3) може вести себе дивно зі старішими клієнтами. Якщо вимкнення WPA3 робить мережу стабільною, справжнє виправлення зазвичай — оновлення прошивки/драйвера або послідовний перехід на WPA2‑only або WPA3‑only.

8) У чому різниця між roaming aggressiveness і band steering?

Roaming aggressiveness — це коли клієнт вирішує, коли покинути AP. Band steering — це коли AP підштовхує або примушує клієнтів до певного діапазону. Коли обидва агресивні, ви отримуєте поведінку «ping‑pong».

9) Чому відеоконференції страждають більше, ніж веб‑браузинг?

Браузери переносять короткі втрати пакетів за допомогою повторів і буферизації. Реальний час аудіо/відео дуже чутливий до джиттера і провалів, тому 5–15‑секундне перепідключення помітне відразу.

10) Я змінив налаштування і все ще відключається. Що далі?

Ізолюйте: протестуйте на мобільному хотспоті (щоб перевірити лише клієнта) і на іншому ноутбуку в тій самій мережі (щоб перевірити тільки мережу). Якщо тільки один пристрій падає — зосередьтеся на драйвері/ОС. Якщо кілька пристроїв падають — дивіться на таймери/прошивку/політику AP.

Практичні наступні кроки

Зробіть три речі у порядку:

Доведіть, де живе відключення за допомогою ping до шлюзу і журналів клієнта. Якщо шлюз падає — це рівень посилання Wi‑Fi, без дискусії.
Вимкніть енергозбереження Wi‑Fi повністю (план живлення ОС + керування живленням пристрою + розширені налаштування драйвера Power Save) і повторно протестуйте щонайменше 30 хвилин.
Якщо періодичність вижила, розглядайте це як таймер політики: rekey/reauth/steering. Збирайте мітки часу і коди причин, потім змінюйте одну мережну змінну за раз.

Одна перефразована ідея від фахівця з надійності пасує сюди: перефразована ідея — John Allspaw неодноразово підкреслював, що ви вчитеся надійності, досліджуючи реальні відмови, а не відгадуючи. Це вся гра: вимірювати, змінити одну річ, знову виміряти.