Низкая скорость VPN на телефоне и upload на VPS: причины и фикс

Низкая скорость VPN-подключения на телефоне и маленький upload на VPS в Нидерландах чаще всего вызваны сетевыми ограничениями на стороне хостинга/провайдера, однопоточной природой TCP и настройками x-ui/Xray (лимиты, шифрование, MTU). Ваш iperf3 показывает, что при нескольких потоках суммарная пропускная способность выше, чем single‑flow — это сильный признак per‑flow/throttling или TCP‑бутылочного горлышка; ниже — пошаговая диагностика и набор проверок/фикс для повышения upload и скорости VPN.

Содержание

• Краткий разбор вашей ситуации
• Что показывает iperf3 и почему один поток медленный
• Основные возможные причины
• Пошаговая диагностика (что и как проверять)
• Практические решения и настройки для увеличения upload и скорости VPN
• Чек‑лист быстрых исправлений
• Источники
• Заключение

Краткий разбор вашей ситуации

Вы получили Speedtest: download 610 Мбит/с, upload 28 Мбит/с — и через x-ui VPN скорость не превышает ~28 Мбит/с. Такой асимметричный результат и iperf3‑вывода (суммарно ~100 Мбит/с при 4 потоках, но отдельные потоки — 6–50 Мбит/с) указывает на несколько вероятных факторов: провайдер/хостер ограничивает исходящую полосу или вводит per‑flow throttle; TCP‑однопоточные ограничения (окно/RTT) и/или ресурсы VPS (CPU/шифрование) и настройки x‑ui. Это типичная картина, когда один поток «упирается» в ~25–40 Мбит/с, а параллельные потоки дают больший суммар — значит канал агрегирует, но лимит на поток/политику всё ещё есть. Для общего обзора причин можно посмотреть материалы о влиянии VPN на скорость и факторах шифрования у NordVPN и VPN Unlimited.

Что показывает iperf3 и почему один поток медленный

Ваш iperf3 с 4 потоками:

[SUM] ... 107 Mbits/sec
[SUM] ... 87.7 Mbits/sec

Это значит: суммарно канал способен дать ~90–110 Мбит/с в тесте, но отдельные потоки сильно различаются (6–50 Мбит/с). Такое поведение объясняется:

• Один TCP‑поток ограничивается либо провайдерским per‑flow cap, либо TCP‑оконным/RTT ограничением (через большие задержки и медленное увеличение cwnd). Об этом пишет сообщество и админы в обсуждениях iperf3 и TCP tuning (см. wiki.donapex про iperf3 и обсуждения на linux.org.ru).
• Speedtest часто использует один поток/несколько коротких потоков и может показать именно то ограничение, которое видит ваш x‑ui‑профиль. Если провайдер режет исходящий трафик по IP/портам или в зависимости от протокола — speedtest покажет ~28 Мбит/с.
• Многопоточный iperf3 показывает «потенциал» — канал не полностью мёртв, но распределение по потокам несправедливо.

Рекомендация для замера: запускайте iperf3 в обе стороны, с разным числом потоков и длительностью:

iperf3 -c <server> -P 1 -t 60 # одиночный поток, 60 секунд
iperf3 -c <server> -P 8 -t 60 # 8 параллельных потоков
iperf3 -c <server> -P 8 -t 60 -R # reverse (с сервера -> клиент)

Так вы увидите, ограничение на одном потоке или глобальная проблема.

Основные возможные причины

• Провайдер / хостинг ограничивает исходящую полосу или делает per‑flow throttling. Многие VPS дают «порт 1 Гбит/с», но применяют fair‑use/egress‑limits или отдельно ограничивают исходящие потоки; есть примеры таких ситуаций в сообществах и службах поддержки хостеров (см. searchengines.guru и кейсы на TimeWeb).
• X‑UI / Xray / VLESS: panel или конфигурация пользователя могут иметь лимиты по скорости или некорректные stream‑settings (плохие transport/obfs/семантика reality). В обсуждениях пользователи отмечают падения скорости при использовании x‑ui/Reality/VLESS (Habr, rwsite).
• Однопоточный TCP‑эффект: при большом RTT и без BBR/оптимального окна один поток не выжимает канал. Это классическая причина, когда iperf3 -P 1 даёт 20–30 Мбит/с, а -P 8 — >100 Мбит/с.
• CPU/шифрование: если VPS не имеет AES‑NI или у процесса Xray/V2Ray нет доступа к ускорению, шифрование может быть CPU‑bound. Проверка CPU во время теста покажет, упирается ли процесс в CPU.
• MTU / фрагментация: неправильно подобранный MTU для туннеля ведёт к фрагментации/потере и падению throughput. Особенно критично при UDP‑туннелях (WireGuard) и при использовании obfuscation.
• Offload / виртуальный драйвер: отключённые GRO/GSO/TSO в виртуальной среде или баги драйвера замедляют большие пакеты.
• Маршрутизация и пирация: плохие маршруты (плохой peering) в сторону клиента или сервера могут давать низкий upload конкретно к тестовым точкам.

Пошаговая диагностика (что и как проверять)

1. Повторите измерения локально и удалённо:

• На VPS:
• Установите iperf3: apt install iperf3 или yum install iperf3
• Запустите сервер: iperf3 -s
• На удалённом клиенте (или в телефоне, через Termux / Android‑iperf3 app):
• iperf3 -c <IP VPS> -P 1 -t 60
• iperf3 -c <IP VPS> -P 8 -t 60
• iperf3 -c <iperf.donapex.net> -P 8 -t 60 -R (пример публичного сервера: https://wiki.donapex.net/test-network/iperf3/)

2. Сравните направления:

• -R делает тест в обратную сторону (VPS → клиент). Если reverse лучше — значит upload с VPS к интернету хуже.

3. Наблюдайте CPU и процессы:

• top / htop во время теста; смотрите, не 100% ли загружен процесс xray/v2ray: ps aux | grep xray
• nethogs / iftop — какие процессы/сессии загружают интерфейс.

4. Проверка интерфейса и ошибок:

• ip -s link show eth0 (замените eth0), cat /proc/net/dev
• ethtool -k eth0 — посмотреть GRO/GSO/TSO
• tc qdisc show dev eth0 — есть ли shaping (cake/htb)

5. Проверка TCP/системных параметров:

• sysctl net.ipv4.tcp_congestion_control
• sysctl net.core.rmem_max/wmem_max
• Включение BBR: sysctl -w net.core.default_qdisc=fq; sysctl -w net.ipv4.tcp_congestion_control=bbr (см. инструкции и совместимость ядра)

6. Проверка MTU:

• Пробный ping с DF‑флагом: ping -M do -s 1472 8.8.8.8 (уменьшайте размер), чтобы найти Path MTU.
• Для туннеля/WireGuard: уменьшите MTU до 1400 или 1380 и протестируйте.

7. Проверка логики x‑ui:

• В панели x‑ui проверьте, нет ли лимитов скорости/конфигурации пользователя. Посмотрите конфиги Xray для транспортов (ws, tcp, tcp+tls, reality) — некоторые обфускации замедляют.

8. Обратитесь к техподдержке хостера:

• Спросите про egress limits, per‑flow caps, DDoS‑proxy/bandwidth shaping. Часто провайдеры применяют ограничения по направлению (egress) или per‑port.

Полезные инструкции про измерения/ограничения и iperf3 — wiki.donapex и обсуждения в сообществе linux.org.ru.

Практические решения и настройки для увеличения upload и скорости VPN

Порядок действий по приоритету — делайте сначала простые проверки, затем системные правки:

1. Свяжитесь с хостером (первый шаг)

• Уточните, есть ли per‑flow или egress‑лимиты, и нет ли активного «DDoS‑proxy»/traffic‑shaping. Если есть — попросите снять лимит или объяснить тариф.

2. Тест и смена протокола на клиенте

• Попробуйте WireGuard на сервере/телефоне — он часто быстрее из‑за меньшей нагрузки на CPU и оптимизации в ядре. В ряде случаев это даёт заметный прирост (см. опыт в сообществах и статьи про замены).
• Если x‑ui используется только для VLESS/Reality, попробуйте временно настроить WireGuard и сравнить throughput.

3. Тюнинг TCP (BBR + fq)

• Включите BBR и fq:

sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
# Для сохранения в /etc/sysctl.conf:
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 87380 268435456
net.core.netdev_max_backlog = 250000

• Проверьте, поддерживает ли ядро BBR (uname -r, sysctl net.ipv4.tcp_available_congestion_control).

4. MTU и фрагментация

• Установите MTU для туннеля/интерфейса 1400–1420 и проверьте. Для WG: ip link set dev wg0 mtu 1420.

5. Offload/виртуальные настройки

• Проверьте и включите GSO/GRO/TSO если они отключены: ethtool -K eth0 gro on gso on tso on.
• Если в виртуальной среде это недоступно — обсудите с провайдером.

6. X‑UI / Xray оптимизации

• Проверьте в панели x‑ui лимиты скорости пользователя.
• Используйте простые streamSettings (например plain WireGuard или VLESS без лишней обфускации) для теста.
• Если процесс xray загружает CPU — переключитесь на WireGuard или оптимизируйте конфиг.

7. Аппаратный ресурс

• Если VPS имеет малый CPU (например 1 vCPU без AES‑NI), то шифрование будет тормозить. Решение — апгрейд CPU/RAM или переход на протокол с меньшей нагрузкой на CPU.

8. Тестирование разных направлений и длительность

• Длительные тесты (60–120 секунд) дают точную картину устойчивой пропускной способности. Используйте iperf3 -t 120 -P 8.

Ссылки для чтения и идей по оптимизации: общая статья по ускорению VPN — xvpn.io, причины падения скорости VPN — VPN Unlimited.

Чек‑лист быстрых исправлений

• [ ] Запустить iperf3: single поток (‑P1) и многопоток (‑P8/‑P16), сравнить.
• [ ] Проверить CPU‑нагрузку на xray/v2ray во время теста (top/htop).
• [ ] Проверить интерфейс на ошибки (ip -s link show) и offload (ethtool).
• [ ] Проверить qdisc/tc на shaping: tc qdisc show dev eth0.
• [ ] Изменить MTU туннеля на 1400 и протестировать.
• [ ] Включить BBR (если ядро поддерживает) и fq.
• [ ] Временно запустить WireGuard и сравнить скорость.
• [ ] Обратиться в поддержку VPS: спросить про egress/per‑flow limits.
• [ ] Если всё равно CPU‑bound — поменять тариф/сервер или снизить нагрузку на шифрование.

Источники

• Почему низкая скорость VPN — VPN Unlimited
• Почему VPN замедляет интернет — NordVPN
• Тестирование iperf3 — Wiki Donapex
• Низкая скорость при Xray VLESS/Reality — Habr Q&A
• Опыт с x-ui и скорость — rwsite
• Как увеличить скорость загрузки сайта / серверные задержки — AdminVPS
• Проблемы с upload/FTP на хостинге — TimeWeb Community
• Как улучшить скорость подключения VPN — XVPN blog
• Обсуждение iperf3 и многопотоков — linux.org.ru
• Тестирование пропускной способности: методики — winitpro

Заключение

Коротко: ваша ситуация — классический случай, когда канал VPS в Нидерландах не «умирает» полностью (download 610 Мбит/с и суммарный iperf3 ≈100 Мбит/с), но один поток/исходящий egress ограничен — это даёт низкий upload и тормозит VPN‑соединение на телефоне через x‑ui. Первые шаги: повторные iperf3‑тесты (1 поток и многопоток), проверка CPU/MTU/ethtool, включение BBR и, в первую очередь, запрос в техподдержку хостинга про per‑flow/egress‑лимиты. Если нужно — временно переведите трафик на WireGuard для сравнения; часто это решает проблему или покажет, что причина — в политике провайдера. Удачи в тестах — если пришлёте результаты iperf3 с командами выше и выводы top, tc qdisc show и ethtool -k, помогу расшифровать и дать точечные команды под ваш случай.