WireGuard не работает в 2026: диагностика handshake, MTU и DPI

WireGuard не работает — давайте разберём по слоям, это не всегда баг конфига. Иногда устаревший public-key после ротации на сервере, иногда MTU режет большие пакеты, иногда NAT не пропускает входящий UDP. А иногда — самое неприятное в 2026 — провайдер видит характерную сигнатуру первого handshake-пакета и режет UDP-маршрут до пира. Симптом везде один: тоннель «активен», но трафик не идёт.

Ниже — последовательность от простых проверок к самым неочевидным. Если дочитаете до четвёртого шага и проблема всё ещё там — почти наверняка дело в DPI, и WireGuard на этом провайдере вы уже не вылечите.

Что чаще всего ломает WireGuard в 2026 (топ-6)

В порядке убывания частоты:

1. DPI режет сигнатуру WireGuard. 148-байтовый handshake-пакет Noise IK имеет узнаваемую форму. Крупные российские провайдеры — МТС, Билайн, Мегафон, Ростелеком — научились его опознавать и применять к таким маршрутам ограничение скорости или обрыв UDP-канала к peer’у.
2. MTU mismatch. WireGuard поверх IPv4 даёт 60 байт оверхеда. Если MTU интерфейса не выставлен в 1420 (или меньше при PPPoE), большие пакеты фрагментируются, часть пропадает. Симптом — handshake проходит, ping работает, а HTTPS-страницы зависают на загрузке.
3. NAT режет UDP. Корпоративные сети, операторы с CGNAT, гостевые Wi-Fi часто пускают только UDP/53 (DNS) и UDP/443 (QUIC). WireGuard на 51820 в такой сети до сервера не доходит.
4. Провайдер закрыл порт 51820. Реже, но бывает. Лечится сменой порта на сервере (например, 443/UDP).
5. Kill switch режет весь трафик. В iOS — «On-Demand», в WireGuard for Windows — «Block untunneled traffic». Если тоннель не поднялся, а killswitch активен, у вас не будет интернета вообще, и легко принять это за «WireGuard сломался».
6. Конфиг с устаревшим public-key. Сервер пересоздали, ключи поменялись, у вас на телефоне старый .conf. Handshake уйдёт, сервер ответит молчанием.

Давайте по слоям.

Шаг 1: проверка handshake и базовой связности

Откройте приложение WireGuard и найдите строку «Last handshake».

• Секунды назад — криптографически тоннель здоров. Проблема дальше: MTU, маршрутизация или DNS.
• Минуты назад и не обновляется — peer вас слышит, вы peer’а нет. Обычно NAT-таймаут или провайдер начал резать UDP в одну сторону.
• Никогда — сервер вас не слышит. Либо неправильный endpoint, либо порт закрыт, либо сервер лежит, либо сигнатура первого пакета режется DPI до того, как дойдёт до peer’а.

Базовая проверка из командной строки. Linux/macOS:

sudo wg show
ping -c 4 10.0.0.1     # IP сервера внутри тоннеля
ping -c 4 1.1.1.1      # выход в интернет уже через тоннель

Если первый ping работает, второй — нет, проблема в маршрутах: либо AllowedIPs не охватывает 0.0.0.0/0, либо у системы есть конфликтующий default route, либо DNS не резолвится.

На Windows из PowerShell от администратора:

Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Get-NetRoute | Where-Object { $_.DestinationPrefix -eq "0.0.0.0/0" }

Если в default route есть и физический интерфейс, и WireGuard — выигрывает тот, у кого ниже метрика. Иногда после Windows Update метрики переставляются, и трафик идёт мимо тоннеля.

Шаг 2: MTU — самая недооценённая причина

Стандартный MTU Ethernet — 1500 байт. WireGuard поверх IPv4 добавляет 60 байт заголовков. Безопасный MTU внутри тоннеля — 1420. Поверх PPPoE (Ростелеком, Дом.ру, многие регионалы) оверхед ещё 8 байт, итого 1412.

При неправильном MTU маленькие пакеты — DNS, ping, начало TCP-handshake — пролезают. Но как только начинается реальный трафик (HTTPS-страница, видео), система пытается отправить пакет 1500 байт. Он не пролезает в туннель целиком, должен фрагментироваться. Часто фрагментация отключена (DF-флаг) или теряется по пути. Соединение зависает, TCP начинает retransmit, страница грузится бесконечно.

Тест MTU — отправьте ping с конкретным размером и флагом «не фрагментировать».

Linux/macOS:

ping -M do -s 1372 10.0.0.1   # 1372 + 28 = 1400
ping -M do -s 1392 10.0.0.1   # 1420, граница для WG поверх Ethernet
ping -M do -s 1472 1.1.1.1    # тест физического канала: 1500 байт

Windows:

ping -f -l 1372 10.0.0.1
ping -f -l 1472 1.1.1.1

Найдите максимальный размер, который проходит без «Packet needs to be fragmented». Прибавьте 28 — это реальный path MTU. Отнимите 60 (или 80 на PPPoE) — это безопасный MTU для WireGuard. Пропишите в .conf:

[Interface]
MTU = 1380

Перезапустите тоннель. Если страницы перестали зависать на загрузке — причина была в MTU. Универсального значения нет, но 1380 на мобильном интернете и 1420 на домашнем Ethernet — рабочая дефолтная пара.

Шаг 3: NAT и фаерволы

Если handshake не проходит, а сервер живой (другой клиент с другого провайдера подключается нормально) — между вами и сервером сидит что-то, что режет UDP.

Корпоративный или гостевой Wi-Fi. Часто разрешён только DNS (UDP/53) и QUIC (UDP/443), всё остальное по UDP закрыто. Лечится пересозданием конфига с endpoint’ом на 443/UDP. Если у вас управляемый сервис — попросите поддержку перевыпустить конфиг с альтернативным портом.

Мобильный интернет с CGNAT. У большинства российских операторов клиенты сидят за одним публичным IPv4 на сотни абонентов. Запись в conntrack-таблице протухает за 30-180 секунд бездействия. Если в .conf нет PersistentKeepalive, тоннель висит активным, но фактически уже умер — пакет наружу уйдёт, ответ обратно — нет.

Лечится одной строкой в [Peer]-секции:

PersistentKeepalive = 25

25 секунд — стандартное безопасное значение. Каждые 25 секунд клиент шлёт серверу маленький keepalive-пакет, conntrack-запись на стороне оператора обновляется, тоннель не протухает.

Локальный фаервол. Windows — Defender Firewall иногда режет исходящий UDP к нестандартным портам после крупных обновлений. macOS — Application Firewall в System Settings → Network → Firewall, добавьте WireGuard в исключения. Linux — ufw или nftables, обычно дефолт пропускает исходящий.

Антивирус с модулем «защита сети» (Касперский, ESET, BitDefender) иногда фильтрует UDP по эвристикам. Временно отключите модуль и попробуйте подключиться — если заработало, добавьте WireGuard в исключения.

Шаг 4: когда виноват ваш провайдер (DPI-сигнатура)

Самый частый сценарий в России в 2026, и при этом самый сложный для диагностики: провайдер не пишет «вы используете WireGuard» — соединение просто ведёт себя странно.

Характерные признаки:

• На домашнем Wi-Fi WireGuard работает, на мобильном — нет. Или наоборот.
• Тоннель подключается, минут 10-15 всё хорошо. Потом скорость падает в 5-10 раз. Перезапуск даёт ещё 10 минут.
• Через сутки handshake перестаёт проходить вообще, хотя ничего не меняли.
• На том же сервере другой протокол (OpenVPN, IKEv2) работает стабильно, а WireGuard — нет.

Что происходит технически. WireGuard в первом handshake-пакете шлёт сообщение типа 0x01 фиксированной длины — 148 байт. DPI сопоставляет это с шаблоном «UDP-пакет, первый байт 0x01, длина 148, далее 32 байта псевдослучайных данных в характерных смещениях». Совпадение — соединение помечается как WireGuard. Дальше провайдер выбирает одно из трёх — режет скорость до неюзабельной, рвёт соединение по таймауту, либо молча дропает все последующие UDP-пакеты к этому peer’у.

Что обычно пробуют (и почему это не работает надолго):

• Сменить порт с 51820 на любой другой UDP-порт. Провайдер смотрит не на порт, а на форму пакета. Помогает на день-два.
• Перезагрузить роутер, перезапустить WireGuard. Иногда даёт окно — провайдеру нужно время «опознать» новый поток.
• Через мобильный интернет вместо домашнего. Помогает, пока тот провайдер ещё не научился. У всех крупных российских операторов сейчас сигнатура WG в фильтрах.

Альтернативные порты и obfsproxy — рабочие или нет

Перед переходом на AmneziaWG есть смысл попробовать пару косметических вещей.

Порт 443/UDP. 443 — это HTTPS и QUIC, такой UDP-трафик провайдеру резать рискованно (вместе с настоящими сайтами накроется). Иногда WireGuard на 443/UDP живёт дольше. Минус — требует доступ к серверной стороне.

Порт 53/UDP. Это DNS. Идея та же. Минус — некоторые провайдеры перехватывают весь UDP/53 на свой DNS-сервер (DNS hijacking), и WireGuard вообще не дойдёт.

obfsproxy / Cloak / shadow-tls перед WireGuard. Идея — обернуть UDP-трафик WireGuard в TCP с TLS-фасадом. На бумаге работает: провайдер видит обычное TLS. На практике — два отдельных процесса, MTU заново, обрывы каждого ловить отдельно. Для техножужжителя — нормально, для повседневной работы — хрупко.

Все эти варианты — попытка сделать WireGuard невидимым средствами поверх протокола. AmneziaWG-форк решает ту же задачу изнутри: меняет именно те параметры пакета, по которым DPI распознаёт WireGuard.

Если все эти попытки уже выматывают — смена порта на день-два, obfsproxy с отдельным процессом и хрупкими обрывами, мобильный интернет как костыль — это не решение, а откладывание. AmneziaWG меняет форму handshake-пакета изнутри протокола, конфиг по структуре идентичен обычному .conf. У нас Molystrix — туннель на AmneziaWG, 249 ₽ в месяц за три устройства, конфиг QR-кодом на email. → Посмотреть тарифы

Когда WireGuard не починить и пора смотреть в сторону AmneziaWG

Эмпирическое правило: если прошли первые три шага, MTU выставлен правильно, NAT решён через PersistentKeepalive, физический канал здоров, а WireGuard всё равно работает по схеме «10 минут хорошо, потом тормозит» — лечить уже нечего. Это не баг конфига, не баг клиента, не баг сервера. Это решение вашего провайдера.

Рабочих путей дальше два.

XRay/sing-box с VLESS+Reality. Другой стек, не WireGuard-семейство. Мимикрирует под TLS-handshake к произвольному настоящему сайту, изнутри даёт прокси через свой сервер. Сильнее против DPI, но настройка сложнее, throughput чуть ниже (TCP вместо UDP), на iOS клиентов мало.

AmneziaWG. Тот же WireGuard, но российская команда Amnezia добавила маскировку первого handshake-пакета: junk-байты случайной длины перед handshake, изменённые header-bytes вместо 0x01-0x04. Для DPI это уже не WireGuard. Криптография та же, скорость та же, расход батареи тот же. Конфиг по структуре идентичен обычному .conf плюс несколько строк с параметрами обфускации. Подробное сравнение — в статье про разницу AmneziaWG и WireGuard.

Важный нюанс: для AmneziaWG-конфига нужно отдельное приложение AmneziaWG (не путать с AmneziaVPN). Стандартное приложение WireGuard конфиг откроет, тоннель поднимет — но без обфускации. Клиенты под все платформы — в материале про AmneziaWG для iPhone, Android, Windows и macOS. Для iPhone настройка идентична обычному WireGuard (гайд по WireGuard на iPhone подходит, только из App Store ставите AmneziaWG). Для десктопа — инструкция для macOS и Windows.

Часто задаваемые вопросы

WireGuard handshake не проходит — что это значит?

Handshake — первый обмен ключами между клиентом и сервером. Если не проходит, клиент шлёт пакет, сервер не отвечает (или ответ не доходит). Причины три. Первая — неправильный endpoint, public-key или preshared-key в конфиге. Вторая — порт закрыт у провайдера или роутера (проверьте 51820/UDP исходящий). Третья — DPI режет сигнатуру первого пакета до сервера. Третий сценарий стал самым частым в России в 2026 — диагностируется методом исключения: попробовать другого провайдера или мобильный интернет.

Как починить MTU для WireGuard?

Найдите path MTU через ping -M do -s SIZE (Linux/macOS) или ping -f -l SIZE (Windows), увеличивая SIZE пока пакет не перестанет проходить. Прибавьте 28 — реальный path MTU. Отнимите 60 (Ethernet) или 80 (PPPoE) — это безопасный MTU для WireGuard. Пропишите в [Interface]: MTU = 1380. Симптом, который лечит правильный MTU — handshake проходит, ping работает, но HTTPS-страницы зависают на загрузке.

WireGuard работает дома, не работает на мобильной сети — почему?

Два сценария. Первый — у мобильного оператора NAT-таймаут короче, conntrack-запись протухает, обратные пакеты не доходят. Лечится PersistentKeepalive = 25 в [Peer]-секции. Второй — у мобильного оператора уже работает DPI на сигнатуру WireGuard (МТС, Билайн, Мегафон, Tele2 — у всех в фильтрах), а на домашнем провайдере пока нет. Если keepalive не помог — почти наверняка второй сценарий.

Можно ли скрыть WireGuard от DPI провайдера?

Косметические меры — сменить порт на 443/UDP или 53/UDP — иногда дают день-два, но DPI смотрит на форму пакета, а не на порт. Полноценное решение — обфускация на уровне самого протокола. Способа два. AmneziaWG — форк от команды Amnezia, который меняет первый handshake-пакет так, что характерная сигнатура исчезает. XRay/sing-box с VLESS+Reality — другой стек, мимикрирует под TLS к настоящему сайту. AmneziaWG проще в настройке, VLESS+Reality сильнее против активных проб.

WireGuard на iPhone не подключается — что проверить?

По порядку. Settings → General → VPN & Device Management — посмотрите, что Personal VPN profile с тоннелем установлен. В приложении WireGuard рядом с тоннелем должен быть зелёный переключатель. Если строка «Last handshake» пустая или давно — проверьте endpoint в конфиге и public-key сервера. Если на Wi-Fi работает, на сотовой связи — нет, либо включите PersistentKeepalive = 25 (NAT-таймаут), либо у оператора уже работает DPI (тогда обычный WG не починить, нужен AmneziaWG). Если включён On-Demand — попробуйте отключить, иногда iOS не даёт пересоздать тоннель в этом режиме.

WireGuard internal error — где смотреть логи?

macOS — приложение WireGuard, Help → Export log. Windows — WireGuard.exe → Log → Save. iOS — иконка тоннеля → On-Demand → Logs. Android — три точки в правом верхнем углу → Log viewer. Linux — journalctl -u wg-quick@wg0. Что искать: handshake did not complete after 5 seconds (handshake не доходит — DPI или порт закрыт), Receiving handshake response from peer без следующего Keypair established (обратный путь режется), MTU или fragment (проблема с MTU).

Стоит ли использовать другой порт вместо 51820?

В 2026 — попробовать стоит, но без иллюзий. Смена 51820 → 443/UDP или 53/UDP иногда даёт день-два нормальной работы, потому что фильтр по нестандартным портам срабатывает жёстче. Через несколько дней новый порт режется так же. Если стало хорошо на неделю — у провайдера фильтр пока по портам, цените момент. Если эффект — день-два, DPI у вас по форме пакета, и порты не помогут, нужна обфускация (AmneziaWG).

Итог

WireGuard в России в 2026 — отличный протокол с одной оговоркой: его сигнатура опознаётся всеми крупными провайдерами и операторами. Если MTU выставлен правильно, NAT-keepalive включён, public-key актуальный, физический канал здоров — а тоннель всё равно работает по схеме «десять минут хорошо, потом плохо», — это не баг конфига. Это решение вашего провайдера про UDP-маршруты с характерной формой пакета.

Лечится обфускацией на уровне самого протокола. AmneziaWG — рабочий путь: тот же по структуре .conf, та же скорость и криптография, плюс маскировка первого handshake-пакета. У нас Molystrix всё это настроено на серверной стороне с подобранными параметрами, конфиг приходит на email после оплаты, тариф 249 ₽ в месяц за три устройства. Если на конкретном маршруте начнутся просадки — поддержка перевыпускает конфиг с другим набором параметров, сервер тот же.