Обновление Xray требует восстанавливаемой пары бинарного файла и конфигурации, а перенос хоста — ещё и плана Endpoint и вывода ресурсов. Меняйте по одной переменной, проверяйте настройки целевой версией до запуска и сохраняйте действие поздних отзывов учётных данных при откате.

Ключевые выводы:

Зафиксируйте эффективную службу, включая drop-in, пользователя и файлы данных.

Используйте фиксированный официальный релиз и храните доверенный старый исполняемый файл с совместимыми настройками.

Успешный разбор конфигурации не подтверждает совместимость клиентов и поведение трафика.

Для какого развёртывания подходит обновление Xray?

Инструкция относится к нативному Xray в Ubuntu 24.04 LTS с systemd и путями FHS из Xray-install. Пример целевой версии — официальный стабильный Xray-core v26.3.27; это фиксированный пример, а не рекомендация обновить до него любую установку. Прочитайте релизные изменения между своей текущей версией и целью. Материал основан на официальной документации без полного сквозного авторского тестирования.［1］［2］

Сначала определите владельца по обзору эксплуатации собственной сети. Нужны sudo, проверенная независимая консоль, окно обслуживания, разрешённый контрольный клиент, защищённые копии и возможность вернуть старую версию. Не прерывайте общий производственный экземпляр без разрешения.

Это не миграция базы панели. Если развёртыванием владеют панель, контейнерный образ или пакетный менеджер, используйте их поддерживаемый процесс резервирования и жизненного цикла вместо перезаписи управляемых файлов. Экспорт базы не является универсальной копией бинарного файла Xray, JSON, секретов, правил и сертификатов. Разбор компонентов Xray и V2Ray помогает установить, какой исполняемый файл обслуживает клиентов.

Выберите ветку: обновить программу на текущем хосте с сохранением Endpoint либо перенести доверенную текущую версию на новый хост и обновить позже. Одновременная смена ОС, ядра, транспорта и ключей затрудняет диагностику контрольного клиента. Исключение — подтверждённая компрометация: восстанавливайте доверенную инфраструктуру и меняйте затронутые секреты, не возвращая скомпрометированную идентичность.

Шаг 1: Зафиксируйте эффективную службу и пару восстановления

Читайте метаданные локально, не печатая полный JSON и секретные значения окружения:

/usr/local/bin/xray version
sudo systemctl is-enabled xray
sudo systemctl is-active xray
sudo systemctl show xray -p FragmentPath -p DropInPaths -p User -p Group -p ExecStart
sudo systemctl cat xray

Текст unit проверяйте приватно: пользовательские аргументы способны содержать секреты, которые нужно удалить перед передачей. Запишите фактический исполняемый файл и каждый вход -config либо -confdir из ExecStart; не предполагайте, что загружается только /usr/local/etc/xray/config.json. Зафиксируйте пользователя, capabilities, доступ к файловой системе, пути environment-файлов и каталога ресурсов без секретных значений в отчёте.［1］［4］

Объект восстановления	Что сохранить	Почему это важно
Программа и версия	Доверенный старый бинарный файл, архитектура, происхождение релиза	Старый исполняемый файл может не принять новую схему
Входы конфигурации	Все загружаемые JSON и порядок	Один файл может не содержать действующие входы и маршруты
Определение службы	Unit, точные drop-in, включение, пользователь и capabilities	Правильный JSON может работать под неправильной идентичностью
Правила и внешние файлы	Используемые geoip/geosite, ссылки и пути	Изменённые или отсутствующие правила меняют выбор трафика
Секреты и сертификаты	Активные данные доступа, используемые сертификаты и ключи, владелец продления	Восстановление без жизненного цикла возвращает отозванный доступ
Сетевые зависимости	DNS, локальный и облачный межсетевые экраны, upstream	Копия конфигурации ядра их не содержит

Храните отдельный датированный журнал отзывов и несекретные параметры активных клиентов. Ограничьте копию правами root, зашифруйте внешнюю копию и убедитесь, что оператор восстановления её читает. Используйте уникальные имена снимков; автоматическая задача панели не должна перезаписывать доверенный комплект. Копируйте закрытые ключи сертификатов только при фактическом использовании, сохраняя прежнюю политику доступа к секретам продления.

Запишите причину отката и максимальное окно решения под свою среду: ошибка запуска, несовместимость обязательного старого клиента, неправильный маршрут или потеря управления. Один успешный start не закрывает окно. Не удаляйте прежний комплект восстановления ради места для нового пакета.

Шаг 2: Подготовьте официальную цель без неизвестного скрипта

Откройте фиксированную страницу релиза, подтвердите проект XTLS, архитектуру и необходимые изменения, получите соответствующий официальный артефакт. Сохраните предоставленные сведения целостности и выполните документированную проверку релиза. Контрольная сумма проверяет артефакт, но не делает случайное зеркало доверенным. Не выбирайте prerelease лишь потому, что его строка версии больше.［2］

Если используете Xray-install, скачайте скрипт официального репозитория в защищённую рабочую область, запишите проверенную ревизию и изучите его работу с установкой, службой и файлами данных до выполнения. Закрепите целевую версию; не запускайте непроверенный curl | bash, beta-режим и не считайте, что установщик меняет только программу. Подготовка не требует исполнения установщика.［1］

Для ручного обновления распакуйте проверенную цель в staging под контролем root отдельно от /usr/local/bin/xray; здесь это /root/xray-change/target/xray. Сделайте файл исполняемым и проверьте version. До замены сохраните старую программу как /root/xray-change/backup/xray вместе с её конфигурацией и другими предметами восстановления. Это пример путей конкретной операции, не разрешение перезаписать прежнюю рабочую область.

Подготовьте копии всех действующих входов конфигурации, удалите отозванные данные по отдельному журналу и внесите только обязательные для релиза изменения. Сохраняйте производственные секреты приватными. Не публикуйте объединённый JSON и не используйте CLI dump ради удобства диагностики: он может показать действующую аутентификацию.

Шаг 3: Что доказывает офлайн-проверка конфигурации?

Если эффективный unit загружает один файл, проверьте его подготовленную копию целевой программой:

sudo /root/xray-change/target/xray version
sudo /root/xray-change/target/xray run -test -config /root/xray-change/target/config.json

Подставьте свой staging-путь. Для каталога используйте соответствующий -confdir; для нескольких явных файлов сохраните реальные входы и порядок. Закреплённый CLI определяет -test как проверку конфигурации без запуска сервера. Ему всё равно нужны внешние файлы и корректные пути ресурсов, поэтому используйте проверенное окружение развёртывания.［3］

Успех означает загрузку этих настроек целевой программой в этом контексте. Он не доказывает, что пользователь службы читает файлы, привязывает порт, получает сертификаты, достигает зависимостей и совместим со всеми клиентами. Проверьте проход по каталогам и права фактического пользователя, не делая всё дерево секретов общедоступным. Сохраните минимальные capabilities вместо перевода службы на root ради устранения ошибки.

Аналогично проверьте доверенным старым бинарным файлом конфигурацию отката после применения текущих отзывов. Если рабочую старую пару подготовить нельзя, остановитесь до переключения. Новые поля могут требовать старого файла настроек: замена одной программы на прежнюю версию не является полным откатом.

Шаг 4: Переключите либо версию, либо хост

Обновление на текущем хосте

Сохраните Endpoint, протокол и клиентские параметры, если релиз не требует конкретного изменения. В разрешённом окне остановите только xray, установите проверенную цель и staging-конфигурацию в записанные рабочие пути с прежним владельцем и правами, запустите тот же unit. При изменении unit или drop-in сначала выполните daemon-reload; одной правке конфигурации он не нужен.［4］

Используйте проверенный платформенный процесс замены, чтобы прерванное копирование не оставило частичный исполняемый файл. Не объединяйте это с новой маршрутизацией и очисткой посторонних служб. Приватно зафиксируйте версию, состояние unit и первую значимую ошибку journal. При отказе переходите к парному восстановлению, не перебирая версии наугад.

Миграция сервера Xray на новый хост

Сначала соберите замену с доверенной текущей версией. Передайте только необходимые настройки и материалы восстановления по аутентифицированному каналу с проверенными ключами хоста. Воссоздайте пользователя, capabilities, пути ресурсов и ограниченный доступ межсетевого экрана. Не клонируйте весь хост или базу панели в другую структуру с предположением, что эффективный unit остался тем же.

Создайте отдельный контрольный профиль на новый Endpoint с нужной идентичностью и данными доступа. Публичные серверные параметры, доменные и сертификатные зависимости или REALITY меняйте только по требованиям выбранной ветки. Не копируйте вслепую владельца продления сертификата, не публикуйте новый профиль. Старый Endpoint сохраняйте только пока он доверенный и разрешённый.

Правка DNS не заставляет каждое приложение отбросить активное соединение или кэш профиля. Используйте документированное переподключение либо импорт и проверьте фактическое назначение. Проверки актуальности клиентского профиля отделяют отказ новой службы от клиента со старыми параметрами.

Шаг 5: Проверьте старые клиенты, трафик и отказ отозванным данным

Протестируйте самую старую обязательную клиентскую версию и каждый существенно отличающийся тип клиента. Запишите версии, не обещая универсальную матрицу совместимости. Для VLESS/REALITY сравните необходимые параметры аутентификации и транспорта; используйте диагностику отказов REALITY, не угадывая новые имена полей. Не отключайте проверку сертификатов.

Метод проверки	Ожидаемый признак	Действие при ошибке
Прочитать версию и эффективный unit	Используются выбранная программа и нужные настройки	Исправить путь или владельца до клиентских тестов
Разрешённый старый клиент делает обязательный запрос	Поддерживаемое приложение работает через выбранный экземпляр	Проверить реальный профиль и изменения версии
Использовать отдельные отозванные тестовые данные	Защищённый прокси-сервис не предоставляется	Прекратить приёмку и применить отзывы везде
Проверить публичный выход и DNS-путь	Выбранные приложения следуют заявленным маршрутам и резолверу	Отдельно проверить маршрутизацию и охват клиента
Проверить необходимые UDP, IPv6 и разрыв	Каждый пункт соответствует заявленной области	Не принимать неподтверждённый охват, вернуть безопасную политику

Для интернет-прокси проверьте публичный IP приложения через его фактически настроенный путь. Запрос на сервере или браузер без прокси не эквивалентны. TCP не подтверждает UDP, IPv4 не доказывает IPv6, а активный процесс не создаёт защиту при отключении.

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

Шаг 6: Выполните восстановление резервной копии Xray и вывод ресурсов

При отказе контрольного клиента через независимую консоль остановите только изменённый экземпляр. По реестру восстановите доверенную старую программу вместе с совместимыми настройками, нужными правилами, unit/drop-in и используемыми сертификатами. До запуска повторите все поздние отзывы. Скомпрометированный ключ или просроченный сертификат заменяют надлежащим процессом, а не возвращают из удобной копии.

Восстановите пользователя, права и capabilities; daemon-reload требуется только для возвращённых определений unit. Проверьте старую пару её собственной командой конфигурационного теста, запустите один раз и повторите версию, разрешённый и отозванный клиент, поведение трафика. При переезде верните контрольное устройство на доверенный старый Endpoint и профиль, снова подтвердите назначение и службу. Остановите замену при отказе от миграции.

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

Если регулярные окна обслуживания превышают ценность собственного выхода, сопоставьте контроль VPS и обслуживание управляемого VPN. Это выбор ответственности, а не способ ремонта Xray или отзыва его ключей. Соседние проверки загрузочного жизненного цикла WireGuard поясняют владение службой, но их команды не применимы к Xray.

Итоги

Храните доверенную пару восстановления и реальные зависимости службы.
Сначала проверяйте конфигурацию, затем клиентов и трафик.
Применяйте отзывы перед восстановлением и выводите инфраструктуру осознанно.

Часто задаваемые вопросы (FAQ)

Достаточно скопировать config.json?

Только если это действительно вся конфигурация, а все внешние зависимости сохранены отдельно. Сначала изучите эффективный unit, затем определяйте состав копии.

Можно обновить программу и переехать в одном окне?

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

Run -test доказывает работу службы?

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

Стоит автоматически выбирать новейший prerelease?

Выбирайте проверенную поддерживаемую цель для своего развёртывания. Пример закрепляет v26.3.27 и не подтверждает пригодность позднего prerelease для ваших клиентов.

Можно откатить только исполняемый файл?

Нужно вернуть также совместимые настройки и зависимости. Старая программа может отвергать новые поля, даже если сам бинарный файл полностью исправен.

Резервная копия восстановит удалённых пользователей?

В старой копии могут остаться их данные доступа. До запуска примените текущий журнал отзывов и подтвердите отказ разрешённой тестовой идентичностью.

Может резервирование панели заменить нативный процесс?

Копия панели относится к её собственному управляемому состоянию. Применяйте документированное восстановление панели, не смешивая базу с ручной заменой нативных файлов.

Источники:

XTLS — Xray-install — https://github.com/XTLS/Xray-install
XTLS — Xray-core v26.3.27 release — https://github.com/XTLS/Xray-core/releases/tag/v26.3.27
XTLS — v26.3.27 command-line configuration checks — https://github.com/XTLS/Xray-core/blob/v26.3.27/main/run.go
Ubuntu Noble — systemd.service(5) — https://manpages.ubuntu.com/manpages/noble/man5/systemd.service.5.html

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Обновление Xray и миграция: резервирование и откат