Xray 升级需要可恢复的二进制与配置组合；迁移主机还需要明确端点切换和资源退役安排。每次只改一个变量，启动前用目标版本检查配置，回退时继续执行之后的凭证撤销决定。

关键要点：

登记实际服务，包括 drop-in、运行用户和数据文件。

使用固定官方版本，保留可信旧二进制及配套配置。

解析成功不代表客户端兼容或流量行为正常。

本文的 Xray 升级流程适用于什么部署？

本文限定 Ubuntu 24.04 LTS 原生 Xray 与 systemd，路径参考 Xray-install 的 FHS 布局。示例目标是官方稳定版 Xray-core v26.3.27，这是固定示例，不表示每个实例都应升级到它。须阅读从现有版本到目标版本的全部相关变更说明。本文按官方文档整理，未进行完整端到端实测。［1］［2］

先结合自建网络运维框架确认管理归属。你需要 sudo、已验证的独立控制台、维护窗口、授权试切客户端、受保护备份及恢复旧版本的能力。共享生产实例未获中断许可时，不执行本流程。

本文不是面板数据库迁移。由面板、容器镜像或软件包管理器拥有的部署，应使用它的备份及生命周期流程，不覆盖其管理文件。数据库导出不能通用替代 Xray 二进制、JSON 配置、凭证、规则和证书备份。Xray 与 V2Ray 组件说明可帮助确认真正服务客户端的可执行文件。

二选一：保留端点，只升级原主机二进制；或先把可信现有版本迁到新主机，之后另行升级。把操作系统迁移、核心升级、传输变更和密钥轮换放在一起，会让试切失败难以定位。已确认泄漏例外：应在可信基础设施恢复并轮换受影响凭证，不能恢复泄漏身份。

步骤 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

私下审阅单元文本，自定义参数可能包含秘密，分享前须脱敏。登记实际可执行文件和 ExecStart 中每个 -config 或 -confdir 输入，不假定只加载 /usr/local/etc/xray/config.json。记录运行身份、capabilities、文件访问、环境文件路径和资源目录设置，但不把秘密值抄到报告。［1］［4］

恢复项目	需保留内容	原因
可执行文件及版本	可信旧二进制、架构、发布来源	新配置结构可能不能被旧程序读取
配置输入	全部加载的 JSON 及排序约定	单一文件可能遗漏有效入站或路由
服务定义	单元、准确 drop-in、启用状态、用户及 capabilities	正确 JSON 也可能在错误身份下运行
规则与外部文件	实际使用的 geoip/geosite、引用文件及路径	缺失或改变规则会改变流量选择
凭证与证书	有效凭证、使用中的证书和私钥、续期归属	恢复秘密却忽略生命周期会复活访问
网络依赖	DNS、云端及本地防火墙、上游依赖	核心配置备份不包含这些内容

独立保存附日期撤销记录，以及有效客户端的非秘密参数。备份仅允许 root 访问，异机副本加密，并确认恢复负责人能读取。使用唯一快照名称，不允许自动面板任务覆盖可信恢复集合。仅备份实际使用的证书私钥，续期秘密仍按原访问策略保管。

登记回退触发条件和适合部署的最长决策窗口，例如启动失败、必要旧客户端不兼容、流量路由错误或管理通道丢失。进程成功启动不能独立结束观察。不要为新包腾空间而删除唯一旧恢复组合。

步骤 2：准备官方目标，不执行未知脚本

打开固定发行页，确认 XTLS 项目、架构和相关变更，下载对应官方制品。保留官方提供的完整性资料，按其发布方式验证。发布校验值只验证制品，不证明随机镜像可信。不要仅因版本字符串更大就选择预发布。［2］

使用 Xray-install 时，先把官方仓库脚本下载到受保护工作区，记录审阅的修订，读清安装、服务与数据文件行为后才能执行。固定目标版本，不执行未经审阅的 curl | bash，不启用 beta，也不假定安装器只改二进制。准备阶段并不要求运行安装器。［1］

手工升级分支将已验证的目标二进制解包到 root 控制、与生产路径分开的暂存目录；示例称其为 /root/xray-change/target/xray。设置可执行权限，先核对 version。替换前将旧程序保存到 /root/xray-change/backup/xray，同时保存配套配置与其他恢复材料。这些路径仅是本次操作示例，不得覆盖以往恢复工作区。

暂存全部有效配置输入的副本，按独立记录移除已撤销凭证，只修改目标发行说明要求的内容。生产秘密保持私密，不公开合并配置，也不使用 CLI dump 作为便捷诊断，它可能暴露有效认证材料。

步骤 3：离线配置检查能证明什么？

实际单元仅加载单一配置文件时，用目标二进制检查暂存文件：

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

输入路径换成自己的副本。目录加载部署使用对应 -confdir；显式多文件部署保留真实输入及顺序。固定版本 CLI 将 -test 定义为只测试配置、不启动服务器。它仍需引用文件及正确资源路径，因此应使用审阅过的部署环境。［3］

通过仅表示目标程序能在该上下文加载配置，不证明运行用户能读文件、绑定端口、访问证书、联系依赖或兼容所有客户端。检查实际用户的目录遍历和文件权限，不将整棵秘密目录改为全员可读。保留最小必要 capabilities，不为消除报错而改用 root 运行服务。

用可信旧二进制检查已重放当前撤销记录的回退配置。无法准备可加载旧组合时，在切换前停止。新版本专有字段可能需要旧配置配对，只换回可执行文件不构成完整恢复。

步骤 4：选择升级版本或迁移主机

在原主机升级

除非发行说明明确要求，保持端点、协议与客户端设置稳定。在授权窗口只停止 xray，把审阅目标程序和暂存配置按登记路径、归属与权限安装到位，再启动同一单元。单元或 drop-in 改变时先 daemon-reload；纯配置变更不需要。［4］

使用平台经审阅的替换流程，避免复制中断留下不完整程序。不要同时重设计路由或清理无关服务。私下记录报告版本、单元状态和首个相关 journal 错误。启动失败进入成套恢复，不随机尝试多个版本。

迁移 Xray 服务器基础设施

先以可信现有版本建立新主机。通过已认证且主机密钥已核验的管理通道转移必要配置和恢复材料，重建运行身份、capabilities、资源路径及严格防火墙入口。不要整机或数据库克隆到不同布局后就假定有效单元仍相同。

使用指向新端点的独立试切配置，填写预期身份和凭证。服务器公有参数、证书或域名依赖、REALITY 设置仅按所选分支需要修改。不要盲目复制证书续期归属，不公开新配置；旧端点仅在仍可信且获授权时保留。

DNS 变更不会强制每个应用丢弃现有连接或缓存配置。按客户端文档重连或导入，并核对实际目的地。客户端配置更新检查可区分新服务器失败与客户端仍使用旧设置。

步骤 5：验证旧客户端、流量和撤销拒绝

测试必须支持的最旧客户端版本，以及实际不同的客户端类型，记录版本，不承诺全版本兼容矩阵。VLESS/REALITY 分支核对必要认证与传输参数，使用REALITY 失败检查表，不要猜新字段名。保持证书验证开启。

检查方法	预期现象	失败处理
读取运行版本及有效单元	使用所选程序和目标配置	客户端测试前修路径或归属
授权旧客户端发起必要请求	支持范围内的应用流量经指定实例成功	查实际配置与版本差异
使用专用已撤销测试凭证	不获得受保护代理服务	停止验收，各处重放撤销
检查出口与 DNS 路径	指定应用按声明路由和解析	分开查路由与客户端覆盖
检查必要 UDP、IPv6 与断线	各项符合声明的部署范围	拒绝未验证覆盖主张，恢复安全策略

互联网代理应从实际配置的应用路径核对应用公网 IP。服务器查询或未走代理的浏览器不等价。TCP 成功不证明 UDP，IPv4 不证明 IPv6，进程 active 不证明断线保护。

拒绝测试同时用合法凭证做正向对照。不要尝试未知用户凭证，也不要把回落伪装网站响应当作代理认证成功。无法完成某种客户端或负向测试时，明确未验证并保留对应验收项。

步骤 6：完成 Xray 备份恢复与退役

试切失败时，通过独立控制台只停本次改变的实例。按清单成套恢复可信旧可执行文件、配套配置、必要规则、单元或 drop-in 和实际使用的证书。启动前重放此后全部凭证撤销。泄漏密钥或过期证书应走正确恢复流程更换，不从便利备份复活。

恢复登记用户、权限和 capabilities；只在单元定义恢复时 daemon-reload。用旧程序自己的检查命令验证旧组合，启动一次，重做版本、合法客户端、撤销客户端及流量检查。主机迁移则让试切客户端返回可信旧端点和配置，重新验证实际目的地及服务；放弃迁移时停替代实例。

成功后观察到约定窗口结束，验证获授权的开机持久化，并核对休眠客户端再退役。移除临时凭证和迁移入口，按政策保留受保护恢复材料，验证移除结果。停止并禁用旧服务；另行取消云计算、磁盘、地址和快照，进程停止不等于计费结束。

若反复维护窗口超过自建出口价值，可权衡 VPS 控制权与托管 VPN 运维。这改变责任，不会修复 Xray 或退役旧凭证。相邻的WireGuard 启动生命周期检查可说明服务归属，但命令不适用于 Xray。

总结

保存可信恢复组合及有效服务依赖。
先做配置检查，再验证真实客户端和流量。
恢复前重放撤销，按步骤退役基础设施。

常见问题

仅复制 config.json 足够备份吗？

只有它确为全部配置、所有引用依赖又另行保存时才足够。先登记实际单元，再决定复制哪些文件。

可以在同一窗口升级和迁移吗？

尽量分开变量，让失败有明确原因。先迁移可信现有版本并验收，再独立计划升级。

run -test 证明服务能工作吗？

它只检查配置加载，不启动服务器。运行权限、端口绑定、客户端兼容与流量策略仍须分别验证。

应自动选择最新预发布吗？

应为部署选择经过审阅且受支持的目标。本文固定示例 v26.3.27，不证明后续预发布适合你的客户端。

回退只换可执行文件可以吗？

还要恢复兼容配置与依赖。旧程序本身完整，也可能无法识别新版配置字段。

恢复备份会恢复已删除用户吗？

旧备份可能包含其凭证。启动前重放当前撤销记录，并用授权测试身份验证拒绝。

面板备份能代替本文原生流程吗？

面板备份只针对它自己管理的状态。采用它文档规定的恢复方式，不把数据库与原生文件手工替换混用。

来源:

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 2026 年 10 月 11 日。

延伸阅读:

Xray 升级与迁移：备份、兼容验证和成套回退步骤