Xray и XTLS на сервере: частые ошибки и решения

MAATRIX

Xray с XTLS — мощная, но чувствительная к деталям связка: одна неверная строка в JSON, просроченный сертификат или несовпадение SNI, и клиент перестаёт подключаться. Ниже — частые ошибки Xray и XTLS на сервере, разобранные по симптомам, с командами диагностики прямо на VPS, чтобы находить причину за минуту и не переустанавливать всё заново.

Где смотреть при любой проблеме

Xray подробно пишет в журнал, и именно с него начинается любая диагностика. Смотрите статус сервиса и последние строки лога:

systemctl status xray
journalctl -u xray -n 50 --no-pager

Затем проверьте валидность конфига встроенной командой — она разберёт JSON и укажет на ошибки формата ещё до запуска:

xray -test -config /usr/local/etc/xray/config.json

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

Сервис не стартует

Xray падает сразу после запуска. Почти всегда виноват конфиг: xray -test покажет, где именно. Частые случаи — пропущенная запятая или скобка в JSON, неверный путь к сертификату или ключу, опечатка в названии протокола или транспорта. Отдельно проверьте, что файлы сертификата и приватного ключа существуют по указанным путям и доступны для чтения процессу Xray — если путь неверный, сервис не поднимется. Ещё одна причина — занятый порт 443: если на нём уже слушает nginx или apache, Xray не стартует. Найдите конфликт:

ss -lntp | grep 443

Освободите порт или разведите сервисы. После любой правки конфига перезапускайте сервис — иначе изменения не применятся.

Отдельно отметим права доступа к файлам. Xray обычно работает под непривилегированным пользователем, и если сертификат с ключом лежат в каталоге, куда этому пользователю нет доступа, сервис не сможет их прочитать и не стартует, хотя пути в конфиге верные. В журнале это выглядит как ошибка открытия файла. Решение — положить сертификат и ключ туда, где процесс Xray имеет право чтения, и выставить корректные права на файлы. Эта мелочь особенно часто всплывает после ручного переноса сертификатов с другого сервера, когда владелец и права файлов не совпадают с ожидаемыми.

Ошибка сертификата

Клиент не подключается, а в логе жалобы на TLS или сертификат. Первая причина — истёкший сертификат: бесплатные TLS живут 90 дней, и если автопродление не настроено, однажды всё встанет. Проверьте срок и при необходимости перевыпустите. Вторая — неверный путь к сертификату или ключу в конфиге после переустановки или переноса. Третья — сертификат выпущен на один домен, а клиент подключается с другим SNI, и проверка не проходит. Убедитесь, что домен в сертификате, SNI на клиенте и A-запись домена указывают на одно и то же. Рассинхрон здесь — типичная причина «вроде всё настроил, а TLS рвётся».

Чтобы истёкший сертификат не превращался в регулярную аварию, стоит раз и навсегда закрыть вопрос автопродления. Проверьте, что механизм обновления (acme.sh или certbot) действительно запускается по расписанию и после обновления перезагружает Xray, иначе сервис продолжит держать в памяти старый сертификат даже после успешного продления файла на диске. Хорошая привычка — раз в месяц заглядывать в срок действия сертификата вручную: минута проверки экономит часы разбирательств в тот день, когда доступ внезапно отвалится у всех сразу.

Клиент не подключается

Сервис работает, сертификат в порядке, а клиент не заходит. Проверьте совпадение параметров: UUID, тип потока (flow) XTLS-Vision, SNI и порт на клиенте должны точно соответствовать серверу. Неверный UUID — и сервер просто не отвечает, будто его нет; это сделано намеренно для скрытности, поэтому внятной ошибки вы не увидите. Несовпадение flow (например, на сервере XTLS-Vision, а на клиенте другой) тоже рвёт соединение. Второй пласт причин — сеть: порт 443 должен быть открыт во внешнем фаерволе облака, а не только в системе. И проверьте, что домен по-прежнему резолвится в IP сервера: если A-запись сменилась или домен переехал, клиент стучится не туда.

Конфликт на порту 443

Отдельная частая ситуация — на сервере уже есть веб-сервер, который держит 443, и Xray с ним конфликтует. Есть два пути. Простой — выделить Xray отдельный VPS, где 443 свободен целиком; это надёжнее всего и убирает целый класс проблем. Более тонкий — настроить совместную работу, когда фронтенд-сервер по SNI раздаёт трафик между сайтом и Xray. Второй вариант мощный, но требует аккуратной настройки и легко ломается при ошибке. Если ваша задача — просто стабильный обход, а не хостинг сайта на том же адресе, проще держать Xray на отдельном чистом сервере.

Блокировка и нестабильность

Xray с XTLS обходит фильтры лучше многих, но не абсолютно. Если соединение внезапно перестало работать, а сервис жив, проверьте, пингуется ли сам IP. Если IP не отвечает даже напрямую — адрес заблокирован, и нужен новый чистый сервер; никакая настройка это не обойдёт. Если IP жив, но трафик подрезают, попробуйте сменить SNI на более нейтральный популярный домен и убедитесь, что маскировка выглядит правдоподобно. Обрывы и просадки скорости часто идут не от протокола, а от качества ноды: перегруженный сервер с плавающей полосой будет нестабилен при любой настройке. Под устойчивый обход берите VPS с чистым IP и гарантированными ресурсами — у MAATRIX его можно арендовать в США или Европе с оплатой из России картой, СБП или криптой.

Подытоживая, ошибки Xray с XTLS почти всегда сводятся к четырём источникам: невалидный конфиг, проблема с сертификатом, несовпадение клиентских параметров и сеть (порт или блокировка IP). Если при каждой проблеме сначала прогонять xray -test, затем проверять срок и пути сертификата, потом сверять UUID, flow и SNI, и только в конце смотреть на фаервол и пинг IP, вы будете закрывать неисправности за минуты. Большинство «мистических» отказов Xray на поверку оказываются одной из этих четырёх причин, просто найденных не в том порядке.

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