Задержка (latency) VPN-сервера: как уменьшить

MAATRIX

Высокий пинг через VPN обычно списывают на «плохого провайдера» и меняют сервер вслепую — иногда помогает, иногда нет, потому что причина не всегда в расстоянии. На задержку в туннеле влияют минимум три независимых фактора: физический маршрут до сервера, поведение TCP при потере пакетов и накладные расходы самого протокола шифрования. Ниже — что реально можно подкрутить в каждом из трёх мест, без магии и без обещаний «пинг в два раза ниже».

Из чего складывается задержка в VPN-туннеле

Прежде чем что-то оптимизировать, стоит понимать, что именно вы меряете. Итоговая задержка приложения через VPN — это сумма нескольких независимых слагаемых:

• Физическая задержка канала — определяется расстоянием и маршрутом, ограничена скоростью света в оптоволокне (~200 000 км/с) и количеством промежуточных узлов. Это тот минимум, который никаким тюнингом не обойти.
• Задержка обработки на сервере — шифрование/расшифровка пакета, работа планировщика ОС, нагрузка на CPU. У современных протоколов (WireGuard) это доли миллисекунды на пакет, но при высокой нагрузке или на слабом CPU может стать заметной.
• Оверхед протокола — каждый пакет VPN оборачивается в дополнительные заголовки (UDP/TCP + шифрование + служебные поля). Это не столько задержка, сколько «съеденная» полоса, но при узком канале или MTU-проблемах превращается в реальные задержки из-за фрагментации и ретрансмиссий.
• Поведение TCP под потерями — congestion control алгоритм решает, как быстро восстанавливать скорость после потери пакета. На маршрутах с потерями (а почти любой международный маршрут их периодически даёт) разница между CUBIC и BBR ощущается сильнее всего.

Дальше по каждому пункту — что можно сделать руками, а не просто «попробовать другой сервер».

Локация сервера: главный рычаг, который часто недооценивают

Физику не обмануть: если между вами и сервером 8000 км и десяток транзитных автономных систем, ниже 70-80 мс RTT вы не получите никаким тюнингом ОС. Поэтому первый и самый эффективный шаг — выбор дата-центра, а не подкрутка sysctl.

Практическое правило: выбирайте локацию не по географии на карте, а по фактическому маршруту вашего оператора. Иногда сервер в соседней стране даёт пинг хуже, чем более далёкий, но с прямым пирингом. Проверяется это до оплаты — методика описана в статье про как измерить реальный пинг до сервера, а ориентировочные диапазоны задержек между популярными направлениями собраны в таблице задержек между локациями.

Что важно на этом шаге:

• Разделяйте RTT и джиттер. Стабильные 90 мс лучше нестабильных 60±25 мс — для VoIP, игр и интерактивного трафика джиттер бьёт больнее среднего пинга.
• Проверяйте несколько ближайших локаций, а не одну. Разница в 10-20 мс между дата-центрами в одной стране — обычное дело из-за разных пирингов у разных операторов.
• Учитывайте, где находится ваша аудитория, а не вы сами. Если VPN нужен для доступа к сервисам конкретного региона, близость к точке выхода часто важнее близости к точке подключения.

Быстрая проверка нескольких кандидатов одной командой (Linux/macOS), если у вас есть их IP или домены:

for h in de.example.net us.example.net uk.example.net; do
  echo "== $h =="
  ping -c 10 -q "$h"
done

Если разница между лучшим и худшим кандидатом меньше 15-20 мс — дальше имеет смысл заниматься не сменой локации, а настройками ниже: физика уже отработана, остаётся софт.

Congestion control: почему BBR часто выигрывает у CUBIC

По умолчанию в большинстве дистрибутивов Linux (а значит, и на VPS) используется алгоритм управления перегрузкой TCP — CUBIC. Он спроектирован в 2000-х под предположение, что потеря пакета почти всегда означает перегрузку сети, и в ответ агрессивно снижает окно отправки. На стабильных LAN-каналах это нормально. На дальних международных маршрутах, где пакеты иногда теряются просто из-за качества линии (а не из-за перегрузки), CUBIC реагирует избыточно — и после каждой такой потери скорость проседает, а вслед за ней растёт и субъективная задержка (буферы наполняются, растёт bufferbloat).

BBR (Bottleneck Bandwidth and RTT), алгоритм из Google, оценивает реальную пропускную способность и RTT канала напрямую, а не реагирует только на потери. На маршрутах с эпизодическими потерями и высоким RTT (типичный сценарий международного VPN) это обычно даёт более стабильную скорость и меньше просадок задержки под нагрузкой. Насколько именно — сильно зависит от конкретного маршрута и загрузки, универсальную цифру в процентах здесь честно дать нельзя.

Включается BBR на сервере (важно: настройка на сервере VPN влияет только на исходящий от сервера трафик, для симметричного эффекта в обе стороны алгоритм должен поддерживаться и на клиенте, но для большинства сценариев «сервер отдаёт много данных клиенту» выигрыш заметен уже с одной стороны):

# проверить доступные алгоритмы
sysctl net.ipv4.tcp_available_congestion_control

# если bbr нет в списке — подгрузить модуль
modprobe tcp_bbr
echo tcp_bbr >> /etc/modules-load.d/modules.conf

# включить BBR и fq (fair queueing, рекомендуется вместе с BBR)
cat >> /etc/sysctl.conf << 'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

sysctl -p

Проверить, что применилось:

sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr

Нюанс: BBR влияет на TCP-трафик. Если ваш VPN-протокол работает поверх UDP (WireGuard, большинство конфигураций OpenVPN) — сам туннель BBR не почувствует. Но весь TCP-трафик внутри туннеля (веб-серфинг, SSH, скачивание файлов) и трафик самого сервера к внешним хостам пойдёт по новому алгоритму, и субъективно ощущение «залипаний» под нагрузкой обычно уменьшается. Для OpenVPN в TCP-режиме (не рекомендуется вообще, но иногда единственный вариант через жёсткий DPI) эффект BBR будет прямым — он влияет непосредственно на сам туннель.

Протокол с меньшим оверхедом: WireGuard против альтернатив

Каждый уровень инкапсуляции добавляет заголовки и, что важнее для задержки, вычислительную работу на пакет. Разница между протоколами здесь не только в «весе» пакета, но и в архитектуре — сколько операций требуется на обработку каждого пакета в обе стороны.

Практический вывод для минимизации задержки:

1. UDP всегда предпочтительнее TCP для VPN-транспорта. TCP поверх TCP (когда внутри OpenVPN-туннеля на TCP идёт обычный TCP-трафик приложения — например, HTTPS) даёт эффект «TCP meltdown»: при потере пакета срабатывают сразу два независимых механизма ретрансмиссии — внутренний и внешний, они друг друга не видят и усиливают задержку вместо компенсации. Используйте TCP-режим только если UDP заблокирован сетью — и это отдельная, вынужденная мера, не про оптимизацию.
2. WireGuard даёт наименьший оверхед на пакет за счёт компактного кода в ядре и современной криптографии (ChaCha20-Poly1305), которая не требует обязательного аппаратного ускорения, в отличие от AES. На слабых CPU (бюджетные VPS, некоторые роутеры) это даёт заметно более низкую задержку обработки, чем OpenVPN.
3. IKEv2/IPsec с AES-NI на современном сервере может быть сопоставим с WireGuard по задержке, если у CPU есть аппаратное ускорение AES — тогда разница в основном сводится к оверхеду заголовков, а не к вычислениям.

Если стоит выбор с нуля — сравнение протоколов по сценариям разобрано подробнее в статье какой протокол VPN выбрать, а если уже есть рабочий OpenVPN и вопрос в переходе — процесс миграции без даунтайма описан отдельно в миграции между VPN-протоколами.

MTU и фрагментация: незаметный источник задержек

Даже на идеальном маршруте с быстрым протоколом задержку может убивать банальная фрагментация пакетов из-за неверного MTU (Maximum Transmission Unit). Если пакет VPN с учётом заголовков шифрования превышает MTU канала, он либо фрагментируется (дополнительная работа на каждом хопе и риск потери одного из фрагментов — теряется весь пакет), либо, если фрагментация запрещена, отбрасывается с ICMP «Fragmentation Needed», который многие сети режут — тогда соединение просто зависает на крупных пакетах, а мелкие пакеты (пинг, SSH) при этом работают нормально. Классический симптом: SSH и пинг работают, а загрузка страницы или passive FTP подвисает.

Для WireGuard типичный безопасный MTU — 1420 (при стандартном Ethernet MTU 1500 и оверхеде WireGuard около 60-80 байт), но точное значение зависит от того, сколько инкапсуляций уже есть на пути (например, если сервер сам находится за PPPoE или другим туннелем):

# в конфиге WireGuard интерфейса
[Interface]
MTU = 1420

Проверка правильного MTU без догадок — методом бинарного поиска через ping с запретом фрагментации:

# Linux
ping -M do -s 1392 8.8.8.8   # 1392 + 28 (IP+ICMP) = 1420

# если не проходит — снижаем размер, пока не пройдёт
ping -M do -s 1372 8.8.8.8

Найдя рабочий размер без фрагментации, прибавьте 28 байт (заголовки IP+ICMP) — это и есть безопасный MTU для внешнего интерфейса; MTU самого WireGuard-туннеля обычно на 60-80 байт меньше него.

Для OpenVPN аналогичная логика, но настраивается через tun-mtu и mssfix в конфиге сервера и клиента — и это одна из самых частых причин «случайных» зависаний, разобранных в статье про частые ошибки OpenVPN на сервере.

Буферы и bufferbloat: скачки задержки под нагрузкой

Отдельная причина скачков задержки — bufferbloat: слишком большие буферы на сетевом интерфейсе или у провайдера накапливают пакеты вместо того, чтобы отбрасывать их при перегрузке. В результате RTT под нагрузкой может вырасти в разы по сравнению с RTT в покое, хотя формальных потерь пакетов нет — они просто подолгу стоят в очереди. Связка fq (fair queueing) + BBR, включённая выше, частично решает проблему на стороне сервера: BBR учитывает rtt-минимум и не даёт буферам разрастаться бесконтрольно. Менять размеры сокетных буферов (net.core.rmem_max/wmem_max) вслепую не стоит — стандартные значения современных ядер обычно уже адекватны, тюнинг имеет смысл только при доказанной проблеме, а не «для профилактики».

Как проверить эффект от изменений

Любая оптимизация без замера до/после — это вера, а не инженерия. Минимальный набор проверок:

# задержка в покое и под нагрузкой (во втором терминале запустить iperf3 -c к серверу)
ping -c 50 -q <IP-сервера>

# путь и промежуточные узлы (важно после смены локации/маршрута)
mtr -r -c 50 <IP-сервера>

# реальная пропускная способность и retransmits TCP
iperf3 -c <IP-сервера> -t 20 -V

В выводе iperf3 -V смотрите на поле Retr (retransmits) — если оно заметно ниже при BBR по сравнению с CUBIC, это прямое подтверждение эффекта, а не субъективное ощущение. Сравнивайте mtr до и после смены локации — иногда «более быстрый» по рекламе дата-центр на практике даёт больше хопов и худший маршрут именно от вашего провайдера.

Частые вопросы