[GH-ISSUE #1532] High CPU usage

bsakaguchi commented

2026-10-13 20:25:31 +00:00

Owner

Originally created by @andrey-kalistratov on GitHub (Apr 13, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1532

OS: Ubuntu 24.04.2
AmneziaVPN Client version: 4.8.5.0
Protocol: AmneziaWG
Server: self-hosted in Netherlands

I face such problems:

If the Wi-Fi is turned off while Amnezia is used, CPU usage of Amnezia processes become very high, up to 100%. And actually the net is not working. When then Wi-Fi is turned on, nothing changes. Sometimes systemd-resolved CPU usage is also very high. It disappers only after turning off and turning on Amnezia connection to server.
Same happens if I switch from Wi-Fi through a router to Wi-Fi connection through a phone as the modem or another router.

Since I usually make such switches, the problem is very actual and I will be grateful, if somebody explains me how to solve it.

Originally created by @andrey-kalistratov on GitHub (Apr 13, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1532 **OS**: Ubuntu 24.04.2 **AmneziaVPN Client version**: 4.8.5.0 **Protocol**: AmneziaWG **Server**: self-hosted in Netherlands I face such problems: - If the Wi-Fi is turned off while Amnezia is used, CPU usage of Amnezia processes become very high, up to 100%. And actually the net is not working. When then Wi-Fi is turned on, nothing changes. Sometimes systemd-resolved CPU usage is also very high. It disappers only after turning off and turning on Amnezia connection to server. - Same happens if I switch from Wi-Fi through a router to Wi-Fi connection through a phone as the modem or another router. Since I usually make such switches, the problem is very actual and I will be grateful, if somebody explains me how to solve it.

bsakaguchi commented

2026-10-13 20:25:33 +00:00

Author

Owner

@shvchk commented on GitHub (Apr 22, 2025):

Try Settings → Connection → KillSwitch → Off

@shvchk commented on GitHub (Apr 22, 2025): Try Settings → Connection → KillSwitch → Off

bsakaguchi commented

2026-10-13 20:25:34 +00:00

Author

Owner

@andrey-kalistratov commented on GitHub (Apr 22, 2025):

Unfortunately, it doesn't help

@andrey-kalistratov commented on GitHub (Apr 22, 2025): Unfortunately, it doesn't help

bsakaguchi commented

2026-10-13 20:25:34 +00:00

Author

Owner

@isbur commented on GitHub (May 6, 2025):

У меня похожая проблема, но, правда, при восстановлении соединения нагрузка пропадает (но я не меняю сеть, просто я часто подключаюсь к мобильному вай-фай и забываю его включить перед следующим сеансом использования).

UPD: и забыл добавить, я использую другой протокол — XRay
UPD2: а, и клиент вообще виндовый ¯_(ツ)_/¯

@isbur commented on GitHub (May 6, 2025): У меня похожая проблема, но, правда, при восстановлении соединения нагрузка пропадает (но я не меняю сеть, просто я часто подключаюсь к мобильному вай-фай и забываю его включить перед следующим сеансом использования). UPD: и забыл добавить, я использую другой протокол — XRay UPD2: а, и клиент вообще виндовый ¯\_(ツ)_/¯

bsakaguchi commented

2026-10-13 20:25:34 +00:00

Author

Owner

@Eiztrips commented on GitHub (May 9, 2025):

AmneziaVPN-service.log

Here's the logs if anyone needs them

@Eiztrips commented on GitHub (May 9, 2025): [AmneziaVPN-service.log](https://github.com/user-attachments/files/20125305/AmneziaVPN-service.log) Here's the logs if anyone needs them

bsakaguchi commented

2026-10-13 20:25:34 +00:00

Author

Owner

@isbur commented on GitHub (May 31, 2025):

Мы побеседовали на тему данного issue с нейросеточкой и у нас формировалось следующее предположение: возможно, следует накатить патчем изменения, которые Mozilla внесли в свой mozilla-vpn-client, так как у них, судя по имеющимся правкам в их репозитории, есть механизмы для отслеживания статуса соединения и экспоненциального увеличения таймаутов при неуспешной попытке приконнектиться. У клиента amnezia мы соответствующих классов не нашли.

@isbur commented on GitHub (May 31, 2025): Мы побеседовали на тему данного issue с нейросеточкой и у нас формировалось следующее предположение: возможно, следует накатить патчем изменения, которые Mozilla внесли в свой mozilla-vpn-client, так как у них, судя по имеющимся правкам в их репозитории, есть механизмы для отслеживания статуса соединения и экспоненциального увеличения таймаутов при неуспешной попытке приконнектиться. У клиента amnezia мы соответствующих классов не нашли.

bsakaguchi commented

2026-10-13 20:25:35 +00:00

Author

Owner

@Volzhanka63 commented on GitHub (Aug 27, 2025):

Yeah, experiencing the same problem. As OP says, the issue appears after Wi-Fi reconnection, and after hibernation, so I try to keep my laptop open throughout the day.
The fix is to reconnect the VPN, but it takes a solid minute or two to have an actual connection.

OS: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble
AmneziaVPN Client version: 4.8.8.3
Protocol: XRay
Server: self-hosted in France and GB

Doesn't happen on my Windows machine.

@Volzhanka63 commented on GitHub (Aug 27, 2025): Yeah, experiencing the same problem. As OP says, the issue appears after Wi-Fi reconnection, and after hibernation, so I try to keep my laptop open throughout the day. The fix is to reconnect the VPN, but it takes a solid minute or two to have an actual connection. **OS**: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble A**mneziaVPN Client version**: 4.8.8.3 **Protocol**: XRay **Server**: self-hosted in France and GB Doesn't happen on my Windows machine.

bsakaguchi commented

2026-10-13 20:25:35 +00:00

Author

Owner

@11me commented on GitHub (Aug 27, 2025):

Yeah, experiencing the same problem. As OP says, the issue appears after Wi-Fi reconnection, and after hibernation, so I try to keep my laptop open throughout the day. The fix is to reconnect the VPN, but it takes a solid minute or two to have an actual connection.

OS: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble AmneziaVPN Client version: 4.8.8.3 Protocol: XRay Server: self-hosted in France and GB

Doesn't happen on my Windows machine.

Yep, same, also restarting NetworkManager and Amnezia service helps

@11me commented on GitHub (Aug 27, 2025): > Yeah, experiencing the same problem. As OP says, the issue appears after Wi-Fi reconnection, and after hibernation, so I try to keep my laptop open throughout the day. The fix is to reconnect the VPN, but it takes a solid minute or two to have an actual connection. > > **OS**: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble A**mneziaVPN Client version**: 4.8.8.3 **Protocol**: XRay **Server**: self-hosted in France and GB > > Doesn't happen on my Windows machine. Yep, same, also restarting NetworkManager and Amnezia service helps

bsakaguchi commented

2026-10-13 20:25:35 +00:00

Author

Owner

@sergDash commented on GitHub (Sep 4, 2025):

Нагрузка процессора возникает потому что нагрузка на сетевой интерфейс достигает 100%. На мини-пк помогает вот такое решение https://github.com/geerlingguy/internet-pi/issues/401 Неясно что за stub там придумали, который вызывает проблемы.

На полноценных linux машинах stub вроде как не мешает, но стоит поиграться с докером, появляются кучу интерфейсов, и вышеприведенное решение уже не помогает.

В общем и целом проблема в диком трафике на интерфейсе amn0. Что его порождает, неверные маршруты, кривой DNS или что еще - не ясно.

@sergDash commented on GitHub (Sep 4, 2025): Нагрузка процессора возникает потому что нагрузка на сетевой интерфейс достигает 100%. На мини-пк помогает вот такое решение https://github.com/geerlingguy/internet-pi/issues/401 Неясно что за stub там придумали, который вызывает проблемы. На полноценных linux машинах stub вроде как не мешает, но стоит поиграться с докером, появляются кучу интерфейсов, и вышеприведенное решение уже не помогает. В общем и целом проблема в диком трафике на интерфейсе amn0. Что его порождает, неверные маршруты, кривой DNS или что еще - не ясно.

bsakaguchi commented

2026-10-13 20:25:36 +00:00

Author

Owner

@sergDash commented on GitHub (Sep 4, 2025):

Если руками выполнить до включения впн:
ip route add 123.123.123.123 via 192.168.0.1 dev eth0
то последующее подключение работает нормально.
Для тех кто не шарит - первый IP это адрес вашего впн-сервера, второй IP - адрес маршрутизатора, eth0 устройство, подсмотреть можно командой ifconfig и проинтуитивить где же оно.

ИИ вот что говорит:

В чем проблема?

В вашей таблице маршрутизации отсутствует ключевой элемент: исключающий маршрут для самого VPN-сервера.

Представьте, что происходит с пакетом, который клиент должен отправить на VPN-сервер, чтобы поддерживать соединение:

Клиент формирует зашифрованный пакет для IP-адреса вашего VPN-сервера (допустим, его адрес 1.2.3.4).
Система смотрит в таблицу маршрутизации, чтобы понять, куда отправить этот пакет.
Она видит правила 0.0.0.0/1 и 128.0.0.0/1, которые говорят: «Отправляй любой трафик в интерфейс amn0».
Пакет, предназначенный для VPN-сервера, отправляется... обратно в VPN-туннель amn0.
Система снова видит этот пакет, снова смотрит в таблицу и снова отправляет его в amn0.
Возникает бесконечный цикл, который мгновенно загружает интерфейс amn0 на 100% и полностью парализует сеть.

Как должно быть правильно?

В вашей таблице маршрутизации должна была появиться еще одна строка, которая создала бы исключение для IP-адреса VPN-сервера. Она бы выглядела примерно так:

1.2.3.4 via 192.168.0.1 dev eth0

Почему это не произошло?

В коде wireguardutilslinux.cpp есть строка, которая отвечает за добавление этого исключения:

// /home/user/src/amnezia-client/client/platforms/linux/daemon/wireguardutilslinux.cpp

// ...
// Exclude the server address, except for multihop exit servers.
if ((config.m_hopType != InterfaceConfig::MultiHopExit) &&
(m_rtmonitor != nullptr)) {
m_rtmonitor->addExclusionRoute(IPAddress(config.m_serverIpv4AddrIn));
m_rtmonitor->addExclusionRoute(IPAddress(config.m_serverIpv6AddrIn));
}
// ...

Тот факт, что маршрут не был добавлен, указывает на сбой в работе этой части кода. Возможные причины:

Произошла ошибка при выполнении системной команды ip route add.
Клиент не смог корректно определить IP-адрес шлюза (192.168.0.1 в вашем случае).
Конфигурация соединения по какой-то причине не содержит IP-адреса сервера (config.m_serverIpv4AddrIn).

Вывод: Ваша диагностика абсолютно верна. Отсутствие исключающего маршрута для VPN-сервера является прямой причиной возникновения маршрутной петли и отказа сети.

@sergDash commented on GitHub (Sep 4, 2025): Если руками выполнить до включения впн: ip route add 123.123.123.123 via 192.168.0.1 dev eth0 то последующее подключение работает нормально. Для тех кто не шарит - первый IP это адрес вашего впн-сервера, второй IP - адрес маршрутизатора, eth0 устройство, подсмотреть можно командой ifconfig и проинтуитивить где же оно. --- ИИ вот что говорит: В чем проблема? В вашей таблице маршрутизации отсутствует ключевой элемент: исключающий маршрут для самого VPN-сервера. Представьте, что происходит с пакетом, который клиент должен отправить на VPN-сервер, чтобы поддерживать соединение: Клиент формирует зашифрованный пакет для IP-адреса вашего VPN-сервера (допустим, его адрес 1.2.3.4). Система смотрит в таблицу маршрутизации, чтобы понять, куда отправить этот пакет. Она видит правила 0.0.0.0/1 и 128.0.0.0/1, которые говорят: «Отправляй любой трафик в интерфейс amn0». Пакет, предназначенный для VPN-сервера, отправляется... обратно в VPN-туннель amn0. Система снова видит этот пакет, снова смотрит в таблицу и снова отправляет его в amn0. Возникает бесконечный цикл, который мгновенно загружает интерфейс amn0 на 100% и полностью парализует сеть. Как должно быть правильно? В вашей таблице маршрутизации должна была появиться еще одна строка, которая создала бы исключение для IP-адреса VPN-сервера. Она бы выглядела примерно так: 1.2.3.4 via 192.168.0.1 dev eth0 Почему это не произошло? В коде [wireguardutilslinux.cpp](code-assist-path:/home/user/src/amnezia-client/client/platforms/linux/daemon/wireguardutilslinux.cpp) есть строка, которая отвечает за добавление этого исключения: // /home/user/src/amnezia-client/client/platforms/linux/daemon/wireguardutilslinux.cpp // ... // Exclude the server address, except for multihop exit servers. if ((config.m_hopType != InterfaceConfig::MultiHopExit) && (m_rtmonitor != nullptr)) { m_rtmonitor->addExclusionRoute(IPAddress(config.m_serverIpv4AddrIn)); m_rtmonitor->addExclusionRoute(IPAddress(config.m_serverIpv6AddrIn)); } // ... Тот факт, что маршрут не был добавлен, указывает на сбой в работе этой части кода. Возможные причины: - Произошла ошибка при выполнении системной команды ip route add. - Клиент не смог корректно определить IP-адрес шлюза (192.168.0.1 в вашем случае). - Конфигурация соединения по какой-то причине не содержит IP-адреса сервера (config.m_serverIpv4AddrIn). Вывод: Ваша диагностика абсолютно верна. Отсутствие исключающего маршрута для VPN-сервера является прямой причиной возникновения маршрутной петли и отказа сети.

bsakaguchi commented

2026-10-13 20:25:36 +00:00

Author

Owner

@DimoNimitSU commented on GitHub (Sep 8, 2025):

I have the same issue on Intel N150. systemd-resolve uses 100% of one CPU core, and the internet does not work.

OS: Ubuntu 24.04
AmneziaVPN Client version: 4.8.10.0

@DimoNimitSU commented on GitHub (Sep 8, 2025): I have the same issue on Intel N150. systemd-resolve uses 100% of one CPU core, and the internet does not work. OS: Ubuntu 24.04 AmneziaVPN Client version: 4.8.10.0

bsakaguchi commented

2026-10-13 20:25:36 +00:00

Author

Owner

@Fullerite commented on GitHub (Sep 9, 2025):

Same issue. CPU usage (100+ %) and network upload (80-100 MBps) spikes after waking up from suspend, but I don't see any network traffic spikes on my VPS graphs for some reason — maybe this is some sort of loopback issue.

OS: Ubuntu 24.04.3
Amnezia Version: 4.8.9.2
Protocol: Both XRay and AmneziaWG
Server: Self-hosted NL and FR

@Fullerite commented on GitHub (Sep 9, 2025): Same issue. CPU usage (100+ %) and network upload (80-100 MBps) spikes after waking up from suspend, but I don't see any network traffic spikes on my VPS graphs for some reason — maybe this is some sort of loopback issue. **OS:** Ubuntu 24.04.3 **Amnezia Version:** 4.8.9.2 **Protocol:** Both XRay and AmneziaWG **Server:** Self-hosted NL and FR

bsakaguchi commented

2026-10-13 20:25:36 +00:00

Author

Owner

@den1251 commented on GitHub (Apr 20, 2026):

Any updates? Still an issue

@den1251 commented on GitHub (Apr 20, 2026): Any updates? Still an issue

bsakaguchi commented

2026-10-13 20:25:37 +00:00

Author

Owner

@qaooie commented on GitHub (May 8, 2026):

Any updates?

@qaooie commented on GitHub (May 8, 2026): Any updates?

bsakaguchi commented

2026-10-13 20:25:38 +00:00

Author

Owner

@apavlychev commented on GitHub (Jun 13, 2026):

I turn off Kill swith like workaround

@apavlychev commented on GitHub (Jun 13, 2026): I turn off `Kill swith` like workaround

bsakaguchi commented

2026-10-13 20:25:38 +00:00

Author

Owner

@versusbassz commented on GitHub (Jun 16, 2026):

OS: Ubuntu 24.04.4 LTS (Noble Numbat)
AmneziaVPN Client version: 4.8.19.0
Protocol: AmneziaWG, AmneziaWG Legacy
Server: self-hosted

if a connection is active then systemd-resolved consumes 100% of one CPU core.
when I switch off a connection the load disappears.

Disabling KillSwitch resolves the issue.

@versusbassz commented on GitHub (Jun 16, 2026): OS: Ubuntu 24.04.4 LTS (Noble Numbat) AmneziaVPN Client version: 4.8.19.0 Protocol: AmneziaWG, AmneziaWG Legacy Server: self-hosted if a connection is active then systemd-resolved consumes 100% of one CPU core. when I switch off a connection the load disappears. Disabling KillSwitch resolves the issue.

bsakaguchi referenced this issue

2026-10-13 21:17:21 +00:00

[PR #634] [MERGED] Update Qt in deploy.yml #1984

Rows
Columns

[GH-ISSUE #1532] High CPU usage #634