Как читать ошибки HAPP и логи VLESS: что искать при проблемах подключения

Ошибки HAPP и логи VLESS часто выглядят сложнее, чем проблема на самом деле.

Пользователь видит:

Timeout

или:

connection reset by peer

или:

unexpected EOF

и начинает менять:

• UUID;
• SNI;
• transport;
• DNS;
• fingerprint;
• flow.

Хотя ошибка могла означать всего лишь:

сервер подписки не ответил.

Или:

один конкретный сайт закрыл TCP соединение.

Или:

клиент вообще не дошёл до Xray.

Поэтому главный принцип диагностики VLESS:

сначала определить этап, на котором появилась ошибка, и только потом менять настройки.

Упрощённо путь выглядит так:

Импорт конфигурации
↓
Подписка
↓
DNS VLESS сервера
↓
TCP соединение
↓
TLS / REALITY
↓
Transport
↓
VLESS
↓
Routing
↓
Server outbound
↓
Целевой сайт

Если понять, на какой стрелке всё остановилось, большая часть загадочных сообщений становится вполне понятной.

Короткий ответ

Если HAPP или VLESS показывает ошибку, не начинайте с переустановки клиента.

Идите по порядку:

1. Определите: ошибка импорта, подписки или подключения?
2. Попробуйте другой сервер.
3. Сравните Wi-Fi и мобильную сеть.
4. Сделайте TCP Ping.
5. Сделайте Via Proxy.
6. Если используется TUN — сравните с Proxy Mode.
7. Обновите подписку.
8. Если сервер ваш — смотрите Xray access и error log.
9. Ищите первую конкретную причину, а не последнюю строку EOF.
10. Сопоставляйте ошибку с точным временем пользовательского сбоя.

Самая полезная мысль:

лог сообщает событие, но не всегда сразу сообщает причину.

Например:

unexpected EOF

может быть следствием:

connection reset by peer

а reset, в свою очередь, может произойти потому, что:

Nginx закрыл upstream connection.

Поэтому контекст важнее одного слова.

Сначала определите уровень ошибки

Ошибки удобно разделить на несколько групп.

1. Ошибка ещё до подключения

Например:

Конфигурация VLESS не валидная

Здесь HAPP не смог даже корректно разобрать ссылку.

2. Ошибка подписки

Например:

Timeout при добавлении подписки

HAPP не смог получить список серверов с subscription URL.

3. Сервер недоступен

Например:

Timeout

при TCP Ping.

Клиент не может нормально установить базовое соединение.

4. TCP работает, но proxy нет

Например:

TCP Ping → 35 мс
Via Proxy → Timeout

Базовая сеть до endpoint существует.

Проблема возникает позже:

• TLS;
• REALITY;
• transport;
• VLESS;
• server outbound.

5. VLESS подключился, но сайты не работают

Тогда проверяем:

• routing;
• DNS;
• TUN;
• outbound;
• destination.

6. Соединение работало и оборвалось

Тут уже появляются:

• EOF;
• connection reset;
• closed pipe;
• timeout.

Это отдельный класс ошибок.

Ошибки импорта HAPP

HAPP официально выделяет несколько ошибок ещё на этапе добавления данных.

Разберём основные.

«Буфер обмена пуст»

Самый простой вариант.

HAPP ожидал получить данные из clipboard, но там ничего нет.

Причины:

• ссылка не скопирована;
• clipboard был очищен;
• пользователь нажал Import раньше Copy.

Это вообще не VLESS ошибка.

«URL подписки не валидна»

Это значит, что переданный адрес subscription содержит:

• ошибку;
• недопустимые символы;
• повреждённый URL.

HAPP ещё не проверяет реальный VLESS сервер.

Проблема находится на уровне:

Subscription URL

а не:

VLESS node.

«Конфигурация VLESS не валидная»

HAPP сообщает эту ошибку, когда импортируемая VLESS конфигурация содержит некорректные данные или символы.

Например:

vless://...

могла:

• обрезаться;
• испортиться при копировании;
• содержать неподдерживаемые старой версией клиента параметры.

Это ещё не timeout сервера.

HAPP не смог нормально сформировать конфигурацию.

Что делать при invalid VLESS config

Порядок простой:

1. Обновить HAPP.
2. Скопировать ссылку заново.
3. Проверить, что скопирована вся строка.
4. Попробовать QR.
5. Если есть subscription — использовать её.
6. Запросить новую ссылку у оператора.

Не нужно менять UUID вручную.

«Невалидная конфигурация JSON»

Если импортируется raw JSON, HAPP может отдельно сообщить о неправильном JSON или массиве.

Это уже формат данных.

Типичные причины:

• пропущена кавычка;
• лишняя запятая;
• JSON обрезан;
• передан не тот документ.

Сам сервер опять же может быть абсолютно исправен.

«Неизвестный тип контента»

HAPP получил данные, но не смог определить, что это:

• VLESS;
• VMess;
• Trojan;
• subscription;
• другой поддерживаемый формат.

Официальное описание связывает это с некорректным или нераспознанным содержимым.

Частый сценарий:

пользователь скопировал не ссылку, а окружающий текст сообщения.

«Неизвестное действие DeepLink»

Это уже ошибка HAPP deeplink.

Приложение получило специальную ссылку, но не распознало указанное действие.

То есть проблема относится не к:

VLESS server

а к:

способу передачи данных в HAPP.

Ошибка профиля маршрутизации

HAPP отдельно умеет сообщать:

неправильные данные для импортирования профиля маршрутизации.

Это значит, что некорректным оказался routing profile.

И здесь особенно важно не смешивать:

VLESS config

и:

routing config.

Сам VLESS сервер способен подключаться нормально, но маршрутизация в клиенте будет сломана.

Ошибки загрузки geo файлов

Routing HAPP может использовать дополнительные geo файлы.

Если загрузка нужных файлов не завершилась в течение трёх минут, HAPP останавливает процесс и показывает ошибку; рядом с проблемным профилем появляется красный восклицательный знак.

Это тоже не означает:

VLESS сервер умер.

Проблема относится к локальному routing profile.

Timeout при добавлении подписки

Очень полезная конкретная ошибка.

При добавлении или обновлении subscription HAPP обращается к серверу подписки.

Если ответа нет в течение 9 секунд, приложение показывает timeout.

Схема:

HAPP
↓
subscription.example.com
↓
9 секунд без ответа
↓
Timeout

Важно:

это ещё не проверка VLESS сервера.

Старые серверы могут работать при timeout подписки

Потому что существуют два отдельных пути.

Получение конфигурации

HAPP
↓
Subscription Server

Использование уже сохранённого VLESS node

HAPP
↓
VLESS Server
↓
Internet

Первый может быть недоступен, а второй продолжать работать.

Поэтому при subscription timeout не удаляйте рабочую подписку первым действием.

У HAPP может быть резервный URL подписки

Provider может настроить Fallback URL.

Если основной subscription URL:

• недоступен;
• вернул HTTP 300–599;
• не ответил за 9 секунд,

HAPP способен перейти на резервный адрес, если оператор его предусмотрел.

Обычному пользователю вручную это настраивать чаще всего не требуется.

Что проверять при subscription timeout

Порядок:

1. Открывается ли интернет вообще.
2. Попробовать другую сеть.
3. Повторить Refresh позже.
4. Не удалять сохранённые servers.
5. Сообщить оператору адрес подписки приватно.

Не нужно менять transport VLESS.

Subscription ещё даже не дошла до этого уровня.

После импорта переходим к Ping

HAPP поддерживает три разных типа проверки:

• ICMP Ping;
• TCP Ping;
• Via Proxy.

И они отвечают на разные вопросы.

ICMP Ping

Обычная базовая проверка:

Client
↓ ICMP
Server

Она показывает сетевую доступность и задержку ICMP.

Но:

ICMP работает

не означает:

VLESS работает.

И наоборот, сервер может блокировать ICMP и при этом отлично обслуживать VLESS.

TCP Ping

Значительно интереснее для VLESS.

HAPP измеряет время установки TCP соединения до сервера.

Например:

TCP Ping → 42 мс

Это означает:

до TCP endpoint удалось быстро установить соединение.

Но пока не доказано:

• TLS;
• REALITY;
• XHTTP;
• VLESS authentication;
• server outbound.

TCP Ping и CDN

Если VLESS находится за CDN, TCP Ping может фактически измерять путь лишь до ближайшего CDN edge, а не до origin Xray. HAPP прямо предупреждает об этом.

Например:

Client
↓ 18 мс
CDN
↓ ???
Xray

HAPP покажет красивые:

18 ms

а реальный proxy path может быть заметно хуже.

Via Proxy — самый полезный пользовательский тест

HAPP Via Proxy проверяет значительно более полный путь.

Официальная последовательность включает:

1. DNS VLESS сервера.
2. TCP connect.
3. TLS handshake при необходимости.
4. DNS тестового ресурса на стороне сервера.
5. TLS соединение с тестовым ресурсом.
6. Получение ответа.

Поэтому Via Proxy гораздо ближе к вопросу:

сервер реально работает как VPN?

Как читать TCP Ping и Via Proxy вместе

Вот здесь начинается полезная диагностика.

TCP быстрый, Via Proxy быстрый

Например:

TCP       35 ms
Via Proxy 60 ms

Выглядит нормально.

TCP быстрый, Via Proxy медленный

TCP       30 ms
Via Proxy 1800 ms

Базовая сеть до endpoint быстрая.

Задержка появляется позже.

Проверяем:

• TLS/REALITY;
• transport;
• reverse proxy;
• server load;
• server DNS/outbound.

TCP работает, Via Proxy timeout

TCP       40 ms
Via Proxy Timeout

Очень полезный сценарий.

Порт доступен.

Но полноценный proxy request не проходит.

Подозреваем:

• VLESS configuration;
• transport;
• security;
• Xray;
• server outbound.

TCP timeout

TCP Timeout

Проблема возникает ещё раньше.

Проверяем:

• IP;
• порт;
• firewall;
• маршрут;
• сеть;
• IPv4/IPv6.

Via Proxy тоже не является магическим абсолютным тестом

Via Proxy включает обращение к дополнительному test destination.

Поэтому timeout способен возникнуть не только из-за VLESS inbound, но и дальше:

Xray
↓
server DNS
↓
test resource

HAPP прямо включает эти этапы в Via Proxy measurement.

Поэтому сравнивайте несколько servers одинаковым методом.

Самый ценный тест — сравнение серверов

Например:

NL:
TCP 30 ms
Via Proxy Timeout

FR:
TCP 38 ms
Via Proxy 65 ms

TR:
TCP 55 ms
Via Proxy 82 ms

HAPP работает.

Устройство работает.

Сеть в целом работает.

Проблема почти наверняка специфична для NL path.

Сравните Wi-Fi и мобильную сеть

Следующий очень сильный A/B тест:

один device
один HAPP
один VLESS server

Меняется только:

Wi-Fi ↔ LTE/5G

Wi-Fi timeout, LTE работает

Ключ явно способен работать.

Смотрите:

• домашнего ISP;
• роутер;
• DNS;
• маршрут;
• IPv6.

LTE timeout, Wi-Fi работает

Проверяем:

• мобильного оператора;
• IP path;
• 4G/5G;
• IPv6;
• другой node.

Это гораздо полезнее случайной смены UUID.

HAPP показывает Connected, но интернет не работает

Это отдельный тип проблемы.

Connected может означать:

локальный tunnel/client поднят.

Но это ещё не гарантирует, что весь нужный пользовательский traffic успешно проходит до интернета.

Проверяем:

• Via Proxy;
• routing;
• DNS;
• TUN;
• outbound.

Proxy Mode работает, TUN нет

Очень характерный desktop сценарий.

Например:

Browser
↓
HAPP Proxy
↓
Internet

работает.

Но:

HAPP TUN
↓
No Internet

Тогда VLESS server уже доказал свою работоспособность.

Проблема скорее локальная:

• TUN adapter;
• routes;
• firewall;
• другой VPN;
• network filter.

TUN работает, но одно приложение нет

Проверяйте routing.

Например, приложение может попадать:

Direct

вместо:

Proxy.

Или использовать:

• IPv6;
• собственный DNS;
• UDP.

Не всякая проблема приложения означает ошибку VLESS.

Что означают логи Xray

Когда клиентских тестов недостаточно, переходим на server side.

Xray имеет два основных типа журнала:

• access log;
• error log.

Это принципиально разные источники информации.

Access log Xray

Access log отвечает прежде всего на вопрос:

какой пользовательский traffic Xray увидел и обработал?

В конфигурации можно указать отдельный файл:

{
  "log": {
    "access": "/var/log/xray/access.log"
  }
}

Если путь не указан, Xray выводит журнал в stdout. Значение none отключает access log.

Почему access log очень полезен

Представим:

1. Пользователь нажал Connect.
2. Открыл сайт.
3. На сервере в access log появилась соответствующая запись.

Мы уже знаем:

traffic дошёл до Xray.

Проблема находится позже или внутри обработки Xray.

Если access log полностью молчит

Тут важно сначала убедиться, что logging вообще включён.

Если включён, а во время воспроизведения server ничего не видит, проблема может находиться до Xray:

Client
↓
DNS
↓
Network
↓
Firewall
↓
CDN / Nginx
↓
Xray

Очень полезное сужение поиска.

Error log Xray

Error log содержит диагностические сообщения Xray.

Его тоже можно направить в отдельный файл:

{
  "log": {
    "error": "/var/log/xray/error.log"
  }
}

или оставить stdout.

У Xray несколько loglevel

Актуальная документация определяет:

debug
info
warning
error
none

Значение по умолчанию:

warning

Что означает debug

debug показывает подробную диагностическую информацию и включает сообщения уровня info.

Использовать полезно:

временно при воспроизведении сложной проблемы.

На нагруженном production сервере держать максимальный debug постоянно обычно бессмысленно.

Что означает info

info содержит рабочую runtime информацию, которая сама по себе не означает неисправность. Также включает warning и error.

Это полезный компромисс для диагностики.

Что означает warning

warning используется для ситуаций, которые могут влиять на пользовательский опыт, но не обязательно полностью ломают работу Xray.

Именно поэтому слово:

warning

не означает:

сервер аварийно сломан.

Что означает error

Уровень error предназначен для проблем, при которых Xray не может нормально выполнить соответствующую операцию и ситуация требует внимания.

Но даже тогда нужно читать сам текст.

Не считайте количество строк warning количеством сломанных пользователей

Proxy server постоянно обслуживает множество сетевых соединений.

Клиенты:

• закрывают приложения;
• теряют Wi-Fi;
• переходят на LTE;
• отменяют requests.

Поэтому в журналах неизбежно возникают события закрытия соединений.

Лог нужно связывать с реальным симптомом.

В Xray можно включить DNS log

В конфигурации есть:

"dnsLog": true

Xray тогда записывает DNS queries и ответы, включая время разрешения.

Это особенно полезно, когда симптомы выглядят так:

VLESS подключён, но сайты открываются очень долго.

Или:

часть доменов вообще не разрешается.

DNS log помогает отделить сеть от DNS

Например:

VLESS connection → нормально
DNS query → несколько секунд

Тогда бессмысленно менять:

• UUID;
• REALITY public key;
• transport.

Tunnel уже работает.

Тормозит name resolution.

Но DNS log может быть очень шумным

Современное приложение делает огромное количество DNS запросов.

Поэтому включать его стоит:

на время конкретного теста.

И смотреть:

• нужный домен;
• точное время.

Xray умеет маскировать IP в логах

Очень полезная функция для поддержки и публичных обсуждений.

Параметр:

"maskAddress": "half"

или другие варианты позволяет автоматически скрывать часть IP адресов в журналах.

Доступны, в частности:

quarter
half
full

Зачем маскировать адреса

В server logs могут оказаться:

• IP клиентов;
• IP destinations;
• внутренняя инфраструктура.

Если лог отправляется:

• разработчику;
• на GitHub;
• в публичный чат;

полезно сначала убрать лишние персональные данные.

Не публикуйте credentials вместе с логом

Особенно:

• полный VLESS URI;
• UUID пользователя;
• subscription token;
• QR;
• REALITY private key.

Для диагностики большинства network ошибок они вообще не нужны.

Как смотреть systemd log

Если Xray запущен отдельным systemd service, часто используется:

journalctl -u xray -f

или:

journalctl -u xray --since "10 minutes ago"

Но имя unit может отличаться.

Например, при панельной установке Xray может запускаться иначе.

Главное — смотреть лог в момент воспроизведения

Не:

открыть 10 ГБ log
↓
найти слово error

А:

1. Запомнить текущее время.
2. Запустить journalctl -f или tail.
3. На клиенте нажать Connect.
4. Открыть конкретный проблемный сайт.
5. Посмотреть появившиеся строки.

Так сразу видно причинную последовательность.

Что искать первым

Не самое страшное слово.

А:

первую конкретную ошибку в цепочке.

Например:

connection reset by peer
↓
unexpected EOF
↓
closed pipe

Первичной проблемой скорее является:

connection reset by peer

а остальные сообщения могут быть следствиями уже закрытого connection.

Что означает Timeout

Timeout означает:

операция не завершилась в установленное время.

Но операция может быть разной.

Например:

DNS timeout

TCP connect timeout

subscription timeout

TLS timeout

destination timeout

Поэтому слово timeout без контекста почти бесполезно.

Как читать timeout правильно

Задайте два вопроса:

Где он появился?

• HAPP subscription?
• TCP Ping?
• Via Proxy?
• Xray outbound?

Что происходило перед ним?

• DNS?
• TCP connect?
• TLS?
• запрос к destination?

После этого timeout становится гораздо конкретнее.

Timeout подписки

Мы уже знаем:

HAPP
↓
subscription server
↓
9 секунд
↓
Timeout

Это документированная логика HAPP.

Timeout TCP Ping

Значит:

базовое TCP соединение до выбранного endpoint не установилось вовремя.

Проверяем:

• IP;
• port;
• firewall;
• ISP;
• IPv4/IPv6.

Timeout Via Proxy

TCP endpoint может быть доступен, но полный proxy request не завершился.

Проверяем:

• transport;
• TLS/REALITY;
• Xray;
• server outbound;
• test destination.

Connection refused

Очень отличительная ошибка.

Обычно она означает:

удалённый host ответил, но на указанном TCP endpoint соединение принимать некому или оно отклоняется.

Например:

server reachable
↓
port 443
↓
connection refused

Это сильно отличается от timeout.

Timeout и refused — не одно и то же

Timeout

SYN
↓
тишина

условно.

Refused

SYN
↓
RST

условно.

В первом случае endpoint не отвечает вовремя.

Во втором — ответ есть, но connection отвергнуто.

Что проверять при connection refused

На сервере:

ss -lntp

Проверьте:

• слушает ли нужный port;
• правильный ли process;
• правильный ли address.

Также:

• firewall;
• reverse proxy;
• Xray process.

Connection reset by peer

Это означает, что существующее TCP connection было аварийно сброшено противоположной стороной конкретного соединения.

Но peer может быть:

• клиентом;
• Nginx;
• CDN;
• destination.

Поэтому нельзя автоматически читать:

reset by peer

как:

VLESS сервер заблокировал пользователя.

Пример с reverse proxy

HAPP
↓
CDN
↓
Nginx
↓
Xray

Если Xray пишет:

connection reset by peer

peer для Xray может быть именно:

Nginx

а не пользовательский компьютер.

Что делать при reset

Сначала сравните:

1. Другой server.
2. Direct path, если вы администратор.
3. Reverse proxy logs.
4. Точное время reset.
5. Другую сеть.

Не менять UUID наугад.

Что означает EOF

EOF буквально означает конец входного потока.

В network application это часто означает просто:

больше данных читать нельзя.

Поэтому обычный EOF не обязательно является аварией.

EOF может быть нормальным

Например:

1. Browser получил страницу.
2. Закрыл connection.
3. Xray дошёл до конца stream.
4. Появился EOF.

Если пользователь ничего не заметил:

чинить нечего.

Что означает unexpected EOF

Это уже более интересный случай.

Программа ожидала продолжение структуры или блока данных, но stream завершился раньше.

Например:

ожидали:
[header][payload]

получили:

[header][часть payload]
↓
connection closed

Результат:

unexpected EOF

Но причина всё равно может быть ниже:

• reset;
• timeout;
• reverse proxy;
• network loss.

Поэтому unexpected EOF — не окончательный диагноз

Читайте соседние строки.

Например:

unexpected EOF
>
connection reset by peer

В таком случае полезнее исследовать reset.

Closed pipe

Ошибка типа:

read/write on closed pipe

часто появляется уже после закрытия connection.

Например:

RST
↓
stream закрыт
↓
другая часть программы пытается писать
↓
closed pipe

Сама closed pipe обычно менее интересна, чем событие, закрывшее поток.

No route to host

Такое сообщение указывает на проблему network routing.

Условно:

Xray
↓
destination IP
↓
нет usable route

Проверяем:

• route table;
• gateway;
• IPv4/IPv6;
• host networking.

Менять VLESS credential здесь бессмысленно.

DNS errors

Если лог сообщает, что доменное имя не удалось разрешить:

proxy может быть полностью исправен.

Проблема возникла на DNS stage.

Проверяем:

• Xray DNS;
• system resolver;
• DoH/DoT;
• IPv4/IPv6 connectivity.

TLS errors

TLS/REALITY находится между базовым TCP и полноценным VLESS connection.

Для REALITY Xray использует отдельные параметры:

• serverName;
• fingerprint;
• shortId;
• public/private keys.

Сам REALITY является отдельным transport security layer и поддерживается только с RAW, XHTTP и gRPC.

Поэтому ошибка на REALITY stage ещё не означает неправильный UUID VLESS.

Как понять, что TCP уже работает

Если:

TCP Ping → 30 ms

а:

Via Proxy → Timeout

TCP connectivity есть.

Начинаем смотреть:

• TLS/REALITY;
• transport;
• Xray;
• outbound.

Ошибка VLESS authentication

VLESS является лёгким stateless protocol и использует ID/UUID для аутентификации.

Если клиент использует:

• старый ID;
• удалённого server user;
• неправильный server profile,

базовый TCP может работать, но VLESS session нормально не поднимется.

Но не диагностируйте UUID по одному timeout

Timeout слишком общий.

Сначала:

другой node
↓
другая сеть
↓
TCP
↓
Via Proxy

И только потом углубляйтесь в auth.

Ошибки transport

После security участвует transport:

• RAW;
• XHTTP;
• gRPC;
• WebSocket;
• другие поддерживаемые Xray методы.

Если клиент ожидает XHTTP, а server настроен иначе:

connection не станет рабочим только потому, что UUID правильный.

Почему нельзя просто поменять XHTTP на WebSocket

Transport обеих сторон должен соответствовать инфраструктуре.

Ручная смена:

XHTTP → WebSocket

на клиенте не заставит сервер автоматически сделать то же самое.

Используйте конфигурацию из subscription.

Ошибка только одного node

Очень важный диагностический паттерн.

NL → Timeout
FR → работает
TR → работает

Одинаковы:

• HAPP;
• устройство;
• сеть.

Значит общая клиентская конфигурация работает.

Смотрите NL.

Ошибка всех nodes

Тут сильнее подозреваются:

• сеть;
• HAPP;
• TUN;
• подписка;
• общая provider infrastructure.

Пробуйте другую сеть.

Все nodes работают в Proxy Mode, но не TUN

Это уже почти наверняка не server-side VLESS проблема.

Смотрите:

• TUN core;
• system/gVisor;
• firewall;
• adapters;
• другие VPN.

Один сайт не работает, остальные работают

Не стоит читать весь Xray error log как доказательство поломки VPN.

Если:

Google → работает
YouTube → работает
example.com → reset

проблема может находиться у:

• destination;
• его CDN;
• конкретного route;
• DNS.

Все сайты не работают через один node

Это уже более системно.

Смотрите:

• server outbound;
• DNS;
• routing;
• gateway;
• firewall.

Access log помогает понять destination

Если включён access log, он может показать, какие destinations реально пытается открыть Xray.

Это полезно для вопросов:

пользователь вообще попадает в Proxy?

или:

traffic ушёл не туда?

Routing тоже нужно читать отдельно

HAPP умеет строить правила:

• Proxy;
• Direct;
• Block.

Routing profiles управляют также DNS и загрузкой geo данных.

Поэтому ситуация:

VLESS работает, но конкретный домен не открывается

может вообще не попадать на VLESS server.

Например

example.com
↓
Direct rule
↓
прямой интернет
↓
Timeout

Пользователь думает:

VLESS сервер не открывает сайт.

Но Xray server этот запрос вообще не видел.

Как это доказать

Очень простой тест:

временно Global Proxy.

Если:

Selective Routing → сайт не работает
Global Proxy → работает

сервер VLESS исправен.

Проблема в routing rules.

Block тоже может выглядеть как ошибка VPN

Например рекламный или tracking domain сознательно попадает в:

Block.

Приложение может показать:

• Network Error;
• failed request.

Но система работает именно так, как была настроена.

Поэтому server log может молчать

Если traffic заблокирован или отправлен Direct на клиенте:

он вообще не приходит на server.

Отсутствие server access entry здесь совершенно ожидаемо.

Как диагностировать медленный сайт

Если подключение есть, но домен долго открывается:

1. Via Proxy.
2. DNS.
3. Global Proxy.
4. Другой node.
5. Server DNS log.

Так быстрее, чем менять transport.

Что смотреть администратору при проблеме XHTTP

Разделите path:

Client
↓
CDN
↓
Nginx/Caddy
↓
Xray

Смотрите журналы каждого слоя.

Если:

CDN получил запрос,

но:

Xray не получил,

проблема находится между ними.

Reverse proxy имеет собственные логи

Например Nginx:

tail -f /var/log/nginx/access.log

и:

tail -f /var/log/nginx/error.log

Сопоставляйте время с Xray.

Пример хорошей корреляции

10:21:04 Nginx upstream timeout
10:21:04 Xray unexpected EOF
10:21:04 HAPP Network Error

Уже появляется логичная цепочка:

upstream problem
↓
stream terminated
↓
Xray EOF
↓
client error

Не начинайте с последней строки

Пользователь увидел:

EOF

и гуглит:

как исправить EOF VLESS.

Но первичная причина в примере:

Nginx upstream timeout.

Именно поэтому нужны несколько строк контекста.

Сколько строк лога сохранять

Для поддержки обычно полезно взять:

• 10–30 строк до события;
• саму ошибку;
• несколько строк после.

И обязательно точное время.

Не нужно отправлять весь журнал за месяц.

Что ещё указать поддержке

Хороший отчёт:

Время: 14:32 МСК
Устройство: Windows 11
Клиент: HAPP
Режим: TUN
Сеть: домашний Ethernet
Сервер: NL
TCP Ping: 31 ms
Via Proxy: Timeout
FR из той же подписки: работает

И небольшой log fragment.

Это практически готовая диагностика.

Плохой отчёт

VPN не работает.

Здесь неизвестно вообще всё:

• клиент;
• сервер;
• сеть;
• симптом;
• время.

Ещё один хороший пример

Через Wi-Fi NL даёт timeout Via Proxy, через LTE тот же профиль работает. TCP Ping по Wi-Fi тоже timeout. FR работает в обеих сетях.

Тут сразу видно направление:

network path до NL.

И ещё один

TCP Ping NL — 28 ms, Via Proxy — 2200–4000 ms. Через FR TCP 40 ms и Via Proxy 75 ms.

Здесь базовый TCP до NL быстрый.

Нужно смотреть позже:

• security;
• transport;
• server processing;
• outbound.

Как отправить bug report HAPP

У HAPP есть официальный bug report form.

Форма запрашивает, среди прочего:

• platform;
• OS version;
• device model;
• app version;
• шаги воспроизведения.

Также можно приложить screenshots, videos и logs.

Это полезно, если проблема воспроизводится именно в HAPP, а другой клиент на том же profile работает.

Но сначала отделите client bug от server bug

Например:

HAPP → не работает
другой актуальный Xray client → работает

на:

• одном device;
• одной сети;
• одном config.

Это уже хороший аргумент смотреть клиент.

Если не работает везде

HAPP Android → нет
HAPP Windows → нет
другой клиент → нет
Wi-Fi → нет
LTE → нет

а другие nodes работают:

гораздо вероятнее проблема server/profile.

Как читать логи без ложных выводов

Есть несколько правил.

Правило 1. Один error не равен массовой проблеме

Смотрите частоту.

Правило 2. Смотрите время

Ошибка должна совпадать с пользовательским событием.

Правило 3. Смотрите полную цепочку

Не только EOF.

Правило 4. Сравнивайте контрольный server

Другой node — лучший reference.

Правило 5. Меняйте одну переменную

Например:

только сеть

а не одновременно:

• DNS;
• transport;
• server;
• HAPP version.

Почему одна переменная так важна

Представим:

Было:

NL + Wi-Fi + XHTTP

не работало.

Пользователь поменял:

TR + LTE + WebSocket + другой DNS

и заработало.

Что было причиной?

Невозможно понять.

Хороший A/B тест

NL + Wi-Fi → Timeout
NL + LTE → работает

Изменилась одна переменная:

network.

Это полезный результат.

Другой хороший тест

NL + Wi-Fi → Timeout
FR + Wi-Fi → работает

Изменилась:

server.

И ещё

NL + HAPP TUN → нет интернета
NL + HAPP Proxy → работает

Изменился:

local tunnel mode.

Так строится диагностика.

Что означают самые частые симптомы

Как диагностировать проблему за пять минут

Вот универсальный алгоритм.

Шаг 1. Не менять настройки

Зафиксировать исходное состояние.

Шаг 2. Другой server

работает?

Если да — клиент в целом исправен.

Шаг 3. TCP Ping

Понять, доступен ли endpoint.

Шаг 4. Via Proxy

Проверить полноценный path.

Шаг 5. Другая сеть

Wi-Fi ↔ LTE.

Шаг 6. Refresh subscription

Исключить старый profile.

Шаг 7. Proxy/TUN

Если проблема desktop application.

Шаг 8. Server logs

Если всё выше не объяснило проблему.

Алгоритм администратора

Если сервер ваш:

Пользователь воспроизводит ошибку
↓
Access log
↓
Error log
↓
Reverse proxy log
↓
DNS log при необходимости
↓
tcpdump при необходимости

Если Xray вообще не видит клиента

Проверяйте до него:

• DNS;
• server IP;
• firewall;
• port;
• CDN;
• Nginx.

Если Xray видит inbound, но нет outbound

Смотрите:

• VLESS auth;
• routing;
• DNS;
• server outbound.

Если outbound начинается и reset

Смотрите:

• destination;
• route;
• peer;
• packet capture.

Если всё работает, но лог содержит EOF

Возможно:

ничего чинить не нужно.

Это очень важный вывод.

Лог не обязан быть идеально пустым.

Когда действительно нужно беспокоиться

Например:

• каждый Connect заканчивается одной ошибкой;
• все пользователи node одновременно жалуются;
• error rate резко вырос;
• проблемы начались после update;
• server process рестартует;
• соединения массово падают через одинаковое время.

Тогда лог становится настоящим диагностическим сигналом.

Проверьте, не перезапускается ли Xray

Если process рестартовал:

все существующие connections естественно оборвутся.

Клиенты могут увидеть:

• EOF;
• reset;
• timeout;
• reconnect.

В этом случае первичная проблема:

Xray restart

а не каждая отдельная ошибка пользователя.

Проверьте systemd

Например:

systemctl status xray

или ваш panel service.

Смотрите:

• uptime;
• restart count;
• exit status.

Проверьте OOM

Linux может завершить process при нехватке памяти.

Например:

journalctl -k | grep -i -E 'oom|killed process'

Если Xray был убит OOM killer:

пользовательские EOF являются следствием.

Проверьте файловые дескрипторы

На сервере с большим количеством connections можно столкнуться с resource limits.

Тогда ошибки могут выглядеть как network problem, хотя процесс просто не способен открыть очередной descriptor.

Проверяйте:

• open files;
• system limits;
• socket count.

Это уже server administration, а не клиентская настройка HAPP.

Проверяйте conntrack при больших нагрузках

На VPN gateway с огромным количеством соединений ограничение conntrack тоже может приводить к странным network symptoms.

Но это уже поздний этап диагностики.

Не нужно проверять conntrack пользователю, у которого один VLESS server просто не импортируется.

Уровень диагностики должен соответствовать проблеме

Очень простое правило:

Invalid URL

Не нужен tcpdump.

TCP timeout

Не нужен анализ VLESS UUID первым действием.

TUN не работает

Не нужен server conntrack первым действием.

Массовые server resets

Вот здесь уже системные метрики действительно интересны.

Не перегружайте пользователя логами

Оператору сервиса не нужно просить клиента:

установите Wireshark и снимите PCAP

если уже видно:

NL не работает
FR работает

Сначала нужно проверить NL server.

И наоборот

Если проблема существует только на одном домашнем ПК, а:

• телефон работает;
• другая сеть работает;
• server работает у других пользователей,

тогда server logs могут вообще ничего интересного не показать.

Нужно смотреть client side.

Что НЕ стоит делать при любой ошибке

Не нужно автоматически:

• переустанавливать HAPP;
• удалять subscription;
• менять UUID;
• менять SNI;
• менять REALITY public key;
• менять flow;
• переключать XHTTP/WebSocket;
• отключать IPv6 навсегда;
• менять DNS на случайный;
• перезагружать сервер.

Каждое такое действие меняет ещё одну переменную.

Сначала собрать доказательства

Минимум:

какой server?
какая сеть?
TCP Ping?
Via Proxy?
другой node работает?
Proxy/TUN?
точный текст ошибки?

Уже этого обычно достаточно, чтобы значительно сузить поиск.

Очень короткая шпаргалка пользователя

INVALID
→ проверить ссылку

SUBSCRIPTION TIMEOUT
→ проверить сервер подписки

TCP TIMEOUT
→ проверить endpoint/network

TCP OK + VIA PROXY FAIL
→ проверить TLS/transport/Xray

CONNECTED + NO INTERNET
→ DNS/routing/TUN

RESET/EOF
→ смотреть контекст закрытия соединения

Очень короткая шпаргалка администратора

Нет записи Xray
→ проблема до Xray

Inbound есть
→ клиент дошёл

Outbound error
→ routing/DNS/destination

Nginx error одновременно
→ reverse proxy path

Process restart
→ сначала выяснить причину restart

Массово у всех
→ infrastructure

Только у одного клиента
→ client/network

Что отправить в поддержку VLESS.ART

Не нужно присылать огромный log без объяснения.

Лучше:

Windows 11, HAPP, TUN. NL не подключается, TCP Ping 32 ms, Via Proxy Timeout. FR и TR работают. Через мобильный hotspot результат NL тот же. Началось сегодня около 14:20.

Это уже очень полезный отчёт.

Если есть error message:

добавить точный текст.

Нужен ли полный VLESS ключ

Обычно нет.

Поддержка сервиса и так знает конфигурацию вашего server profile.

Если credential нужен для проверки, передавайте его только через приватный канал поддержки.

Никогда не публикуйте полный VLESS доступ в комментариях.

Готовый VLESS и диагностика

При использовании готовой подписки пользователь не должен вручную разбирать каждый Xray parameter.

Нормальный порядок:

другой node
↓
Via Proxy
↓
другая сеть
↓
Refresh
↓
поддержка

VLESS.ART предоставляет несколько серверных локаций через подписку для HAPP, поэтому проблемный node можно временно заменить другим, пока причина диагностируется.

Посмотреть тарифы:
https://vless.art/#tarif

Почему несколько серверов важны именно для диагностики

Один server не даёт контрольной точки.

Если он не работает, неизвестно:

• client;
• ISP;
• server.

Если есть три:

NL → нет
FR → да
TR → да

картина становится значительно понятнее.

Логи — не цель диагностики

Не нужно стремиться:

понять каждую строку Xray.

Нужно ответить на конкретный вопрос:

где находится проблема?

Если другой node работает:

уже полезно.

Если LTE работает, а Wi-Fi нет:

ещё полезнее.

Если Xray не видит клиента:

область поиска резко сократилась.

Это и есть задача логов.

Итог

Ошибки HAPP и логи VLESS намного проще читать, если не воспринимать их как один общий поток сообщений.

Сначала разделите проблему по уровням:

Import
↓
Subscription
↓
DNS
↓
TCP
↓
TLS / REALITY
↓
Transport
↓
VLESS
↓
Routing
↓
Outbound
↓
Destination

HAPP уже предоставляет несколько полезных диагностических точек.

Ошибки вроде:

• invalid subscription;
• invalid VLESS config;
• unknown content;
• invalid deeplink;

возникают ещё до реального VLESS соединения. А subscription timeout означает, что HAPP не получил ответ от сервера подписки в течение 9 секунд.

После успешного импорта особенно полезны TCP Ping и Via Proxy.

TCP Ping проверяет базовое TCP connection, тогда как Via Proxy проходит через DNS сервера, TCP, TLS при необходимости, proxy и обращение к тестовому ресурсу. Поэтому именно Via Proxy лучше отражает реальную работу VLESS соединения.

Сочетание:

TCP быстро
Via Proxy Timeout

уже говорит намного больше, чем простое:

VPN не работает.

Если нужны server side данные, Xray разделяет access log и error log и поддерживает уровни debug, info, warning, error и none. Также можно отдельно включить DNS logging и маскировку IP адресов перед передачей журнала третьим лицам.

Главное при чтении error log:

ищите первичное событие.

EOF может быть обычным завершением потока.

unexpected EOF может быть следствием reset.

closed pipe часто появляется уже после закрытия connection.

connection reset by peer сообщает, что TCP connection сброшено, но peer может быть не конечным пользователем, а Nginx, CDN или destination.

timeout означает только то, что какая-то операция не завершилась вовремя — необходимо понять, какая именно.

Поэтому универсальная диагностика выглядит так:

другой server → другая сеть → TCP Ping → Via Proxy → Refresh subscription → Proxy/TUN → client/server logs.

Для администратора:

точное время → Xray access → Xray error → reverse proxy log → DNS log → tcpdump при необходимости.

И самое важное правило:

не исправляйте текст ошибки — исправляйте причину, которая появилась перед ним.

Если unexpected EOF появился после connection reset, исследуйте reset.

Если Xray не видел клиента вообще — не меняйте VLESS UUID.

Если TCP работает, а Via Proxy нет — смотрите следующий уровень.

Если один node падает, а два других работают — начинайте с этого node.

Так даже довольно длинный Xray log перестаёт выглядеть набором случайных ошибок и превращается в обычную последовательность сетевых этапов, каждый из которых можно проверить отдельно.