Коротко — причин много; поведение «днём работает, вечером нет», «на ПК стабильно, на телефоне — выборочно» типично для сетевых ограничений/фильтрации или проблем с путём (MSS/MTU, IPv6, UDP) + особенностей мобильной ОС (Private DNS, режимы энергосбережения). Ниже план диагностики и список наиболее вероятных причин + конкретные команды/проверки.
Что проверять в первую очередь (быстро)
1. Сравните среды:
- Рабает ли подключение по тому же Wi‑Fi с другим телефоном или ноутбуком? (если да — проблема в конкретном телефоне).
- Работает ли подключение этого телефона через другую Wi‑Fi сеть? (если да — проблема в роутере/провайдере Wi‑Fi).
2. Отключите на телефоне Private DNS (Android: Настройки → Сеть → Частный DNS) или поставьте 1.1.1.1 / 8.8.8.8. Иногда DoT/DoH ломают подключение к SNI/реальности.
3. Попробуйте переключить транспорт: reality (UDP) ↔ gRPC (TCP) ↔ WebSocket (TLS). Если UDP-шлюз (reality) падает на Wi‑Fi — вероятно блокировка UDP/фильтрация на роутере/провайдере.
4. Посмотрите логи сервера и клиента в момент неудачной попытки (включите debug‑уровень).
Диагностика — какие данные собрать
1. Лог сервера (v2ray/3xui): включите logLevel = debug и соберите фрагменты вокруг попыток подключения.
2. Клиентский лог (v2rayNG, hiddify и т. п.) — включите подробный лог.
3. Поймать трафик на сервере:
- sudo tcpdump -nni any host <IP_телефона> and port <порт> -w dump.pcap
- или просто: sudo tcpdump -nni any port <порт>
Если пакеты не доходят — проблема между клиентом и сервером (роутер/ISP).
4. На сервере посмотреть, слушает ли порт:
- ss -tunlp | grep <порт>
5. Проверить TLS/ALPN/SNI (с ПК или Termux на телефоне):
- openssl s_client -connect your.domain:443 -servername your.domain
Посмотрите, проходит ли TLS‑рукопожатие и какой сертификат отдаётся.
6. Трассировка/пинг:
- traceroute / mtr с телефона (Termux) и с сервера, чтобы посмотреть, где теряются пакеты.
7. Проверить IPv6:
- Может телефон по Wi‑Fi пытаться соединяться по IPv6, но IPv6 маршрут у сервера/провайдера битый. Отключите IPv6 на Wi‑Fi для теста.
Типичные причины и как их проверить/исправить
1. Блокировка/фильтрация UDP или специфических портов на роутере/провайдере
- Симптом: reality (UDP) падает, TCP‑транспорты работают.
- Тест: tcpdump — видите ли UDP пакеты от клиента? Попробуйте временно открыть UDP порт или использовать TCP‑транспорт.
- Решение: использовать gRPC/websocket over TLS (TCP), либо менять порт на 443, либо обфускацию.
2. DPI / провайдерская фильтрация (чаще по вечерам — нагрузка/политика)
- Симптом: нестабильность по времени, выборочность по устройствам.
- Тест: поменяйте транспорт (ws, http2, grpc), поменяйте SNI/имя домена, посмотрите server log на TLS‑handshake drop.
- Решение: маскировка под обычный HTTPS (ws+TLS, корректный SNI и валидный cert), CDN (Cloudflare) или использовать reality с правильной маскировкой.
3. Проблемы с SNI / сертификатом / ALPN (gRPC требует h2)
- Симптом: gRPC не устанавливается, в логах TLS handshake/ALPN mismatch.
- Тест: openssl s_client + check ALPN; включите debug и найдите ошибки TLS.
- Решение: убедиться, что SNI совпадает с cert, ALPN настроено на h2 для gRPC.
4. IPv6/dual‑stack конфликты
- Симптом: на ПК (обычно IPv4) всё ок, телефон по Wi‑Fi пытается в первую очередь IPv6 и падает.
- Тест: на телефоне временно выключить IPv6 или принудительно подключаться по IPv4.
- Решение: настроить сервер/сертификат/маршруты для IPv6 корректно или предпочитать IPv4.
5. MTU/PMTU проблемы (особенно при TCP+TLS+ws/H2)
- Симптом: соединение устанавливается, но висит/падают при первой передаче данных; чаще проявляется на мобильных клиентах.
- Тест: уменьшить MTU на клиенте (например, до 1200) или включить MSS clamping на роутере.
- Решение: настроить MTU/MSS.
6. Роутер Wi‑Fi/оператор блокирует нестандартный исходящий порт/через прокси/каптивный портал
- Симптом: с этого Wi‑Fi не доходит до сервера вообще (нет SYN/UDP пакетов).
- Тест: попробовать другой порт (443), проверить HTTP прокси/переадресацию в роутере.
- Решение: использовать 443/TCP, masquerading как обычный HTTPS.
7. Мобильная ОС/приложение
- Симптом: только одно устройство/только мобильные ОС.
- Проверьте: энергосбережение/ограничение фоновых данных, разрешения приложению, настройки VPN в ОС.
- Тест: временно отключить оптимизацию батареи, разрешить приложению фоновые данные.
Конкретные команды/действия (примеры)
- На сервере: включить debug и смотреть логи
- tail -f /path/to/v2ray.log
- Посмотреть приходят ли пакеты:
- sudo tcpdump -nni any host <IP_клиента> and port <порт>
- Проверить TLS:
- openssl s_client -connect your.domain:443 -servername your.domain
- На телефоне (Termux):
- ping <IP>
- traceroute <IP>
- curl --http2 -v --resolve your.domain:443:<IP> https://your.domain/ (если доступен)
Порядок действий, который рекомендую выполнить сейчас
1. Включите debug‑логи на сервере и на клиенте; попытайтесь подключиться в момент отказа.
2. Одновременно запускайте tcpdump на сервере и делайте попытку подключения — увидите, доходят ли пакеты.
3. Если пакеты доходят, смотрите логи TLS/ALPN/gRPC на сервере — ищите ошибки handshake/unsupported alpn.
4. Если пакеты не доходят — проблема на пути (роутер/ISP). Поменяйте порт на 443, проверьте NAT/UDP, попробуйте другой Wi‑Fi.
5. Проверьте и временно отключите Private DNS/DoT/DoH на телефоне и IPv6.
Если поможете — могу расшифровать логи
- Пришлите (без приватных ключей) фрагменты server log (debug) и клиентский лог, а также результат tcpdump/tail (или сообщите, приходят ли пакеты на сервер). По этим данным дам более точную причину и рекомендации по правке конфигурации.
Если хотите быстро обойти проблему для всех клиентов — временное решение: использовать TLS+WebSocket на порту 443 с валидным сертификатом и правильным SNI (маскировка под обычный HTTPS) — это чаще всего проходит через фильтры.