Почему VPN не работает через мобильный интернет, но на Wi-Fi да?

VPN не работает через мобильный интернет чаще всего из‑за действий оператора (DPI, «белые/серые» списки, блокировка портов/IP) или из‑за особенностей транспорта (MTU/IPv6/DNS), а потому на одном и том же сервере по Wi‑Fi всё выглядит нормально. Поскольку у вас VLESS через X‑UI PRO и раньше работал Amnezia VPN, вероятнее всего провайдер мобильной сети выцелил трафик VLESS/Reality или порт/IP сервера — но проверить это можно последовательно с помощью логов, tcpdump, openssl и смены транспорта на ws+tls (порт 443) с прокси TLS (nginx/Caddy). Ниже — причины, подробная диагностика, конкретные команды и проверенные обходы (nginx/CLOUDFLARE, ws+tls, MSS clamp, отключение AAAA/IPv6 и т.п.).

Содержание

• Причины: почему VPN не работает через мобильный интернет
• Диагностика: какие тесты выполнить и как интерпретировать результаты
• Конкретные команды и примеры (tcpdump, openssl, ss, curl)
• Быстрые исправления и обходы (порт, ws+tls, SNI, nginx, CDN)
• Настройки VLESS/X‑UI PRO, пример конфигурации и nginx-прокси
• Логи, tcpdump — что искать и как читать pcap
• Чеклист: порядок действий (шаг за шагом)
• Источники
• Заключение

Причины: почему VPN не работает через мобильный интернет

Коротко — почему один и тот же сервер работает по Wi‑Fi, но не по мобильной сети:

• Блокировка/фильтрация у мобильного оператора (DPI, SNI‑фильтр, белые/серые списки). Операторы массово начали фильтровать VPN‑протоколы и даже TLS‑фингерпринты, поэтому OpenVPN, WireGuard и VLESS/Reality могут блокироваться выборочно в сетях мобильных операторов [https://www.comnews.ru/content/227971/2023-08-08/2023-w32/rossiyskie-op].
• IP/порт‑блокировка и репутация хостера. Операторы часто «палят» диапазоны крупных облачных провайдеров и ограничивают трафик по IP — поэтому смена VPS у вас не всегда решит проблему (нужен «не палёный» IP). Есть много жалоб на VLESS, особенно с реализацией Reality/XTLS — мобильные сети стали точечно блокировать эти комбинации (см. отчёты пользователей) [https://qna.habr.com/q/1405378].
• DPI и распознавание протоколов: если TLS/Handshake не похож на обычный браузерный, DPI может контейнеризировать/тормозить/сбрасывать соединение; обфускация (ws+tls, h2, grpc) часто помогает [https://habr.com/ru/articles/768778/].
• MTU / фрагментация: мобильные сети часто имеют меньший эффективный MTU и могут «ломать» туннели, если не настроено MSS clamp или MTU корректно [https://kb.netgear.com/ru/22384/Максимальный-размер-передаваемого-блока-данных-MTU-частичная-потеря-интернет-соединения-и-производительность-1479991184052].
• IPv6/AAAA: если у домена есть AAAA и оператор даёт IPv6 путь, а ваш сервер не принимает IPv6 — клиент попытается по IPv6 и упадёт.
• DNS/редиректы: мобильный оператор может подменять DNS или направлять часть трафика на своих «заглушек» (white‑list).
• Локальные приложения/фирменные фильтры (особенно на корпоративных/модифицированных прошивках). Но вы проверили разные телефоны и операторы — поэтому большая вероятность на уровне оператора/сети.

Диагностика: какие тесты выполнить и как интерпретировать результаты

Цель диагностики — быстро понять, где «умирает» соединение: не доходит SYN на сервер, доходит, но TLS не состоится, или TLS проходит, но данные не идут.

1. Быстрое сравнение Wi‑Fi vs Mobile

• На сервере запустите логирование (системный журнал) и tcpdump, потом попытайтесь подключиться с телефона по Wi‑Fi и по мобильной сети, сохраняя две сессии pcap. Сравните их.

2. Что смотреть в логах

• Сервер: системный журнал xray/x-ui — проверка наличия ClientHello/accept и ошибок авторизации.
• Клиент: включите debug/verbose в V2RayNG/V2RayN/Kitsunebi, экспортируйте логи для Wi‑Fi и Mobile и сравните.

3. Как понять результат tcpdump

• Если при попытке с мобильной сети на сервер не приходит даже SYN — значит трафик режут раньше (оператор/межсетевые экраны).
• Если приходит SYN, но потом нет TLS ClientHello — проблема у клиента (MTU, NAT).
• Если TLS ClientHello доходит, а сервер отвечает RST/ICMP unreachable — блок на стороне оператора/провайдера.
• Если TLS проходит, но данные «тормозят» или сессия обрывается — возможно DPI после установления канала.

4. Проверьте DNS/IPv6/CGNAT

• Сравните разрешение домена (A/AAAA) с Wi‑Fi и с мобильной (dig/nslookup).
• На телефоне проверьте внешний IP (what is my ip) — если 100.64.0.0/10 или частный — CGNAT; это обычно не мешает исходящим соединениям, но усложняет некоторые сценарии.
• Временная проверка: удалите AAAA или временно займите A‑запись в другом месте и протестируйте.

Конкретные команды и примеры (tcpdump, openssl, ss, curl)

Примеры команд (выполняйте на сервере; замените порт/домен):

• Проверить, слушает ли процесс порт:

sudo ss -tunlp | grep ':443\|:ВашПорт'

• Журналы systemd (xray/x‑ui):

sudo systemctl status xray x-ui
sudo journalctl -u xray -f
sudo journalctl -u x-ui -f

• Захват трафика при попытке соединения (Wi‑Fi):

sudo tcpdump -i any -nn -s0 port 443 -w /tmp/vless-wifi.pcap
# затем повторите попытку с телефона по Wi‑Fi, остановите tcpdump

и для мобильного:

sudo tcpdump -i any -nn -s0 port 443 -w /tmp/vless-mobile.pcap

• Понимающие сигналы SYN:

sudo tcpdump -i any -nn -s0 'tcp[tcpflags] & (tcp-syn) != 0 and port 443'

• TLS / SNI тест с рабочего ПК:

openssl s_client -connect your.server.ip:443 -servername your.domain.com -alpn h2 -tls1_3

Если openssl показывает корректный сертификат и ServerHello — TLS работает.

• Проверка HTTP(S) с заданным IP (обход DNS):

curl -vk --resolve your.domain.com:443:your.server.ip https://your.domain.com/

• Проверка DNS с конкретным резолвером:

dig @1.1.1.1 your.domain.com A +short
dig @1.1.1.1 your.domain.com AAAA +short

• Тест MTU (Linux):

ping -M do -s 1400 8.8.8.8 -c 4
# уменьшайте размер, пока пинг не пройдет; это покажет ceiling MTU

• Проверка iptables/nft/ufw:

sudo iptables -S
sudo nft list ruleset
sudo ufw status verbose

Интерпретация: если pcap для Wi‑Fi содержит SYN→SYN/ACK→TLS handshake, а для мобильной нет SYN — значит блокировка до сервера. Если SYN есть, но TLS не доходит — DPI/проверка TLS/обрыв.

Быстрые исправления и обходы (порт, ws+tls, SNI, nginx, CDN)

Перечислю рабочие шаги — от простых к более сложным:

1. Простые быстрые проверки (делать сразу)

• Смените порт на 443 (TLS) — часто помогает, т.к. порт 443 открыт для HTTPS.
• Пропишите в клиенте явный SNI = ваш домен (serverName) и используйте корректный cert.
• Пропишите в клиенте transport = ws + tls с path = случайный (не /ray) и Host = ваш.

2. Обойти DPI: ws+tls + reverse proxy (nginx/Caddy)

• Настройте nginx на 443 с валидным сертификатом (Let’s Encrypt), проксируйте WebSocket на локальный порт Xray. Это даёт «натуральный» TLS handshake, похожий на веб‑трафик; часто убирает распознавание VLESS «в лоб». Многие используют именно такой подход как базовый обход. См. пример ниже.

3. Если Reality/XTLS не работает на мобильной — временно переключитесь на ws+tls/h2/grpc

• Сообщения пользователей показывают, что VLESS+Reality в некоторых мобильных сетях перестаёт работать, тогда ws+tls либо h2/grpc чаще проходят [https://qna.habr.com/q/1405378].

4. CDN / domain fronting / Cloudflare

• Прозрачная маскировка: свой домен + CDN (Cloudflare) — прячут реальный IP и дают «легитимный» TLS. Но не панацея: иногда блокируют и CDN. В обсуждениях люди отмечали, что Cloudflare помогает не всегда, но часто — стоит попробовать.

5. MTU/MSS

• Включите MSS clamp (если сервер маршрутизирует трафик) или уменьшите MTU:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# или временно:
sudo ip link set dev eth0 mtu 1400
sudo sysctl -w net.ipv4.tcp_mtu_probing=1

Это помогает, если по мобильной сети пакеты фрагментируются и туннель ломается [https://kb.netgear.com/ru/22384/…].

6. DNS / IPv6

• Уберите AAAA запись, если сервер не поддерживает IPv6, или обеспечьте корректный IPv6. На телефоне установите Private DNS (1dot1dot1dot1.cloudflare-dns.com или dns.google) и попробуйте снова. Переключение на IPv4 часто решает «вдруг перестал работать только на мобильном» случаи.

7. Смена IP/провайдера VPS

• Вы уже пробовали — но учтите: лучше брать у провайдера с «чистой» репутацией (не популярные «известные» диапазоны, small VPS или специальные провайдеры), либо использовать «residential proxy»/reverse proxy через другой поставщик.

8. Обфускация: tls + ws + случайный path + реальные заголовки

• Путь и Host задаются в wsSettings, выбирайте случайный путь и корректный Host. ALPN: [“http/1.1”,“h2”].

Источники и отчёты пользователей показывают, что комбинация: домен со справочным cert + nginx/Caddy + ws+tls на 443 + случайный path даёт наибольшее практическое попадание в сеть операторов [https://habr.com/ru/articles/768778/, https://qna.habr.com/q/1405378].

Настройки VLESS (X‑UI PRO) — пример конфигурации и nginx‑прокси

Пример inbound для Xray (ws+tls на вспомогательном локальном порту, nginx делает TLS):

{
 "inbounds":[
 {
 "port": 12345,
 "protocol": "vless",
 "settings": {
 "clients":[{"id":"ВАШ‑UUID","flow":""}],
 "decryption":"none"
 },
 "streamSettings":{
 "network":"ws",
 "wsSettings":{"path":"/x123aB9"},
 "security":"none"
 }
 }
 ]
}

Nginx (терминирует TLS, проксирует WebSocket на 127.0.0.1:12345):

server {
 listen 443 ssl http2;
 server_name your.domain.com;

 ssl_certificate /etc/letsencrypt/live/your.domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/your.domain.com/privkey.pem;

 location /x123aB9 {
 proxy_redirect off;
 proxy_pass http://127.0.0.1:12345;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }

 location / {
 try_files $uri /index.html;
 }
}

В X‑UI PRO: в настройках профиля укажите transport = ws, path = /x123aB9, TLS = enabled, serverName = your.domain.com, port = 443. Путь должен быть нестандартный, host = your.domain.com.

Если раньше использовали Amnezia — проверьте, не оставились старые правила iptables/nft, которые мешают новым inbound’ам.

Логи, tcpdump — что искать и как читать pcap

На что обратить внимание при анализе pcap/journalctl:

• Наличие SYN от клиентского IP (для мобильной сети) — если нет, значит блокируют до сервера.
• TLS ClientHello — если видите ClientHello, проверьте SNI и cipher suites; несовпадение с тем, что вы ожидаете, может выдать трафик DPI.
• RST или ICMP unreachable сразу после ClientHello — признак активного блокирования.
• Если TLS завершён, но приложение не передаёт данные — проверьте MSS/MTU и ошибки TCP retransmission.

Пример: сравнили pcap_wiFi.pcap и pcap_mobile.pcap; в первом — полная последовательность SYN→SYN/ACK→TLS→AppData; во втором — SYN не доходит или приходит клиентский SYN, а серверу не виден ответ — отвечайте на это как на «находится в пути блок».

Чеклист: порядок действий (шаг за шагом)

1. На сервере: ss, journalctl -u xray -f, sudo tcpdump (сохраняйте pcap для Wi‑Fi и Mobile).
2. На телефоне: включите debug‑логи клиента, смените Private DNS на 1.1.1.1/8.8.8.8, временно отключите IPv6.
3. Выполните openssl s_client / curl с PC, чтобы проверить TLS/SNI.
4. Если нет SYN с мобильной — связывайтесь с оператором или пробуйте другой исходящий порт (443).
5. Настройте ws+tls + nginx (приведён пример) и проверьте снова.
6. Включите MSS clamp / уменьшите MTU при подозрении на фрагментацию.
7. Если ничего не помогает — попробуйте прятать origin через CDN/Cloudflare или другой «чистый» IP/провайдера.

Источники

• ComNews — Российские операторы связи массово блокируют протоколы OpenVPN и WireGuard: https://www.comnews.ru/content/227971/2023-08-08/2023-w32/rossiyskie-op
• Habr — Обфускация и обход DPI: https://habr.com/ru/articles/768778/
• Habr Q&A — VLESS+Reality перестал работать на мобильном интернете (пример проблем): https://qna.habr.com/q/1405378
• Netgear KB — MTU и проблемы с VPN/производительностью: https://kb.netgear.com/ru/22384/Максимальный-размер-передаваемого-блока-данных-MTU-частичная-потеря-интернет-и-производительност-1479991184052
• SecureVPN — Как разблокировать VPN в России (обзор методов и операторских ограничений): https://www.securevpn.pro/rus/blog/view/26
• GitHub zapret — примеры обхода DPI и iptables‑подсказки: https://github.com/bol-van/zapret
• NTC / форум — жалобы на VLESS и 3x‑ui: https://ntc.party/t/vless-vpn-не-работает-у-некоторых-пользователей/13547

Заключение

Коротко: VPN не работает через мобильный интернет почти всегда из‑за операторской фильтрации (DPI/белые списки/блокировка IP и протоколов) или из‑за сетевых нюансов (MTU/IPv6/DNS). Для вашего случая (VLESS через X‑UI PRO, ранее Amnezia VPN работал) начните с логов и tcpdump (сравните Wi‑Fi и mobile), затем переведите VLESS на ws+tls на 443 с валидным доменом и nginx/Caddy в качестве TLS‑прокси, проверьте MTU/MSS и отключите AAAA/IPv6 на время — эти шаги в 80% случаев дают результат. Если после последовательной диагностики SYN‑пакеты от мобильной сети до сервера не доходят — это подтверждение операторской блокировки и потребуется маскировка через CDN/другой IP или более глубокая обфускация.