3x-ui 部署只有在管理入口受控、未授权用户被拒绝、数据库恢复不会复活已撤销访问时，才算完成。本流程使用私有 SSH 管理通道和一个加密入站，恢复验收须由你在自己的获授权环境中执行。

关键要点

隐藏 URL 路径不是认证，也不是网络边界。

管理员凭据必须和每个代理用户的身份分开。

数据库、证书、版本及后续撤销属于同一恢复计划。

面板运行和代理流量成功是两项不同验收。

3x-ui 部署会带来哪些维护责任？

自建运维责任图区分主机、管理面和用户流量的所有者。面板简化录入，也成为值得保护的控制点。不愿承担数据库和证书维护时，应先比较自管 VPS 与托管出口的责任。

WireGuard 设备管理应使用wg-easy 的设备管理路线。本文任务是 3x-ui 及其 Xray 核心；VLESS、REALITY 与 Vision 的区别说明这些名称为什么不是可以随意互换的设置。

适用范围： 专用 Ubuntu 24.04 LTS 主机、原生 3x-ui v3.9.0、默认 SQLite、另一台兼容客户端，以及你控制的域名已有的有效证书。不涵盖 PostgreSQL、容器或既有生产面板。本文依据官方来源，作者未完成端到端实测；标题的恢复验证指读者必须执行下列验收，不是作者成功声明。［1］

步骤 1：授予 root 前审阅固定版本安装器

私下记录原端口、防火墙、路由、DNS、服务单元和证书续期任务。确认新的 SSH 连接及独立提供商控制台可用。安装期间在提供商侧关闭除已知管理路径外的入站，因为安装器可能在你修改设置前启动服务。

官方原生路线使用特权脚本。下载确切发行版本的脚本，检查软件包变更、归档下载、服务安装和证书分支，不直接执行远程管道。语法检查不等于安全审阅。版本参数固定归档，不带参数可能解析到其它发行版。［2］［3］

umask 077
curl --fail --show-error --location \
  https://raw.githubusercontent.com/MHSanaei/3x-ui/v3.9.0/install.sh \
  -o install-3x-ui-v3.9.0.sh
less install-3x-ui-v3.9.0.sh
bash -n install-3x-ui-v3.9.0.sh

确认项目归属、审阅所选分支全部下游下载后才继续。核对官方发行完整性资料；安装器报告不匹配或无法获取必需文件时停止，不更换不明镜像、不关闭 TLS 校验，也不为继续而改用开发版。

在真实终端交互执行，选择 SQLite。SSH 专用管理路线应选择明确标为 Skip SSL — behind reverse proxy / SSH tunnel only 的选项，并确认只绑定回环地址。不要默认进入证书分支，也不为此开放 80 端口。步骤 3 的代理入站使用自己的已有证书。［2］

sudo bash install-3x-ui-v3.9.0.sh v3.9.0
sudo systemctl stop x-ui
sudo /usr/local/x-ui/x-ui setting -listenIP 127.0.0.1 -port 2053
sudo systemctl start x-ui
sudo ss -lntup

显式设置命令再次固定管理地址和端口。前面任一命令失败就停止调查，不盲目继续。生成的凭据、路径和安装结果文件应私下保存。确认管理监听为 127.0.0.1:2053；即使提供商暂时挡住，通配监听也属于边界失败。［5］

步骤 2：建立 3x-ui SSH 通道并保护账户

在工作站替换大写占位符，本地 2053 必须空闲。指定信任文件中的主机密钥须经过独立核验；不匹配就停止，不为了打开面板接受未知密钥。

ssh -N -T -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile=/PATH/TO/VERIFIED_KNOWN_HOSTS \
  -L 127.0.0.1:2053:127.0.0.1:2053 ADMIN@SERVER_IP

访问 http://127.0.0.1:2053/BASE_PATH/，把 BASE_PATH 改成真实生成路径。这里的 HTTP 经 SSH 传输，不是公开管理入口。登录后设置独立管理员名称和强密码；能够安全保留恢复材料时，启用本版本支持的第二因素。

关闭浏览器会话，用新的隐私窗口确认必须登录，错误凭据不能执行特权操作。从获授权外部主机检查公网 TCP 2053 在相关两种地址族均不可达，重启后仍应如此。随机端口或路径只减少意外发现，不能替代这些检查。

没有独立需求和策略时，不启用远程 API、机器人或订阅监听。检查全部监听，不能只看面板端口。导出 URL 可能含凭据，即使订阅端点私有，也须遵守订阅链接的秘密处理规则。

步骤 3：创建一个加密入站和独立用户

有限示例使用普通 TLS 上的 VLESS/TCP，不使用 REALITY 或 Vision。在 Inbounds 按表新增条目，再添加一个独立命名客户端，由面板生成 UUID。VLESS 自身不提供传输加密，本例必须有 TLS。［6］［7］［8］

字段	值或要求
协议／传输	VLESS／TCP，不设置 Vision flow
监听／端口	`0.0.0.0`／TCP `8443`，初始由提供商阻断
VLESS decryption	`none`，这是协议字段，不代表允许移除 TLS
传输安全	启用 TLS，证书有效且对应 `proxy.example.com`
证书／密钥	`/etc/x-ui/tls/fullchain.pem`／`/etc/x-ui/tls/privkey.pem`
客户端身份	每人或每设备新 UUID，不复用管理员密码
可选监听	未使用的订阅、API、机器人保持关闭

替换示例域名，通过已批准的签发方法准备证书。开放入口前确认名称、有效期、链、匹配私钥及续期负责人。按实际服务用户所需读取权限把文件安装到上述路径，私钥不能全员可读，也不通过递归放宽权限解决问题。

保存入站并应用面板的 Xray 配置变更，检查服务状态和配置/证书错误日志，私下保留导出。在独立客户端填写实际入口、端口、新 UUID、TCP、TLS 及对应服务器名称，启用证书验证，Vision flow 留空。本地代理只绑定 127.0.0.1，不要对局域网公开。

步骤 4：分别验证代理流量和拒绝

通过提供商及主机策略，只临时允许获授权测试客户端来源访问 TCP 8443，不开放管理端口。为受测应用明确选择新配置，再核对它的可见出口 IP，与主机已知出口比较。经 SSH 打开面板不能证明这条业务路径成功。

sudo systemctl status x-ui --no-pager
sudo journalctl -u x-ui --since "10 minutes ago" --no-pager
sudo ss -lntup

检查	预期条件	失败处理
无登录会话访问面板	特权操作被拒绝	关闭访问，检查账户和会话策略
正确 UUID 与验证通过的 TLS	新代理 TCP 请求成功且出口正确	区分证书/名称、身份、路由和核心错误
独立错误 UUID 测试配置	无新授权代理请求	停止开放，核对真正接收流量的入站/配置
DNS、IPv6、应用 UDP	各自符合选定覆盖策略	记录未支持路径，不外推 TCP 结果
客户端断开	实际回退符合策略	不从应用代理推导断线保护

负向配置只使用受控测试流量。本例验收 TCP；UDP 要求客户端和协议模式确实承载它、目标受控，并单独取得结果。DNS 可能在应用代理外解析，支持 IPv6 的应用也可能走另一条路，必须分开检查。

撤销前建立第二个独立身份用户作对照。删除或停用第一个用户并应用 Xray 变更，终止其已有客户端会话，用保留 UUID 重连，要求新请求被拒绝且对照用户仍正常。在批准的维护窗口重启 x-ui 后重复。旧连接流和累计流量不能充当负向验证。

步骤 5：进行 3x-ui 备份恢复并保持撤销有效

私下登记面板/核心版本、SQLite 路径、TLS 文件、续期配置、服务设置、用户、令牌和提供商规则。默认数据库为 /etc/x-ui/x-ui.db；即使证书位于同一目录，也仍是独立恢复输入。PostgreSQL 需要自己的数据库备份方法，不适用本文件复制流程。［4］

使用新快照目录，在维护窗口停止面板/核心，每条命令都确认成功。复制整个已停止的 SQLite 目录也保留伴随数据库文件。复制失败时保持源数据，排查后有意识地恢复服务。

sudo install -d -m 700 /root/3x-ui-backup-20261011
sudo systemctl stop x-ui
sudo cp -a /etc/x-ui /root/3x-ui-backup-20261011/x-ui
sudo chmod -R go-rwx /root/3x-ui-backup-20261011
sudo systemctl start x-ui

实际证书路径若不同，还需纳入外部证书、续期及账户材料。限制备份权限前记录原所有权和模式。加密受限异机副本；可读数据库含敏感客户端及管理员状态，不能为了方便用机器人或公开聊天发送。

独立保存带日期的用户撤销和凭据轮换台账。恢复使用隔离替代主机，安装相同面板与 Xray 核心版本，关闭业务及可选监听入口。将替代主机当前目录保留在下面新的回退名称；快照源须存在，新回退目标须未占用。没有独立回退副本时，不在唯一在线实例执行。

sudo systemctl stop x-ui
sudo mv /etc/x-ui /etc/x-ui.before-restore-20261011
sudo cp -a /root/3x-ui-backup-20261011/x-ui /etc/x-ui

备份副本已去除组及其他用户访问。复制后先按清单恢复原属主和权限，特别是实际服务身份对 SQLite 与 TLS 文件的读取权限；私钥仍不得让无关用户读取。完成后才执行以下启动命令。

sudo /usr/local/x-ui/x-ui setting -listenIP 127.0.0.1 -port 2053
sudo systemctl start x-ui

旧数据库可能恢复旧用户及管理员凭据。开放前经 SSH 面板重放后续全部撤销和轮换，检查证书所有者、名称、到期时间及续期任务。重复正确/错误凭据、撤销/对照用户、重启和监听检查。旧撤销 UUID 重新可用说明恢复失败，应关闭入口并修复持久化与核心运行态。不要强塞旧结构进新安装，也不把恢复和升级混在一起。［4］

步骤 6：恢复管理或退役主机

丢失认证时，经获授权主机控制台及文档规定的 x-ui 菜单重置账户，随后登录并重建原定认证策略。不要为了诊断关闭第二因素或公开面板。恢复权限不明确时保持入口关闭并停止。

退役先关闭本入站提供商规则，撤销用户和导出，停止并禁用 x-ui。检查本安装拥有的全部监听及续期任务，按保留期限保存加密备份后，再使用官方卸载路线。只删除本部署 DNS 和云资源，检查无关服务及新管理连接。卸载软件不等于取消主机计费。

总结

管理边界与代理连接分开验收。
保存一致数据库和证书快照，另保留后续撤销台账。
恢复后负向检查经重启仍成立，才重新开放服务。

常见问题

隐藏路径能保护面板吗？

不能，路径可能通过历史、导出或日志泄露。应限制管理监听，并为每次特权操作要求真正的身份认证。

SSH 通道会保护公网代理入站吗？

SSH 通道只保护这里的管理浏览器路径。独立 VLESS 入站仍需要自己的 TLS、用户身份、防火墙策略及客户端验证。

为什么 VLESS decryption 写 none？

这是 VLESS 协议配置值，不是建议使用公网明文传输。本例另行要求普通 TLS，客户端必须正常验证证书。

能直接复制运行中的 SQLite 文件吗？

应使用一致备份机制，或先停止本专用安装再复制数据库目录。写入期间复制，可能无法取得一致可恢复状态。

数据库导出包含证书吗？

不要假设包含，应独立保存真实证书和私钥路径、访问权限及续期配置。即使它们和数据库相邻，也属于不同恢复材料。

恢复是否会复活已删除用户？

备份早于删除时可能复活。开放入口前应重放独立撤销台账，并验证旧 UUID 的新请求在重启后仍被拒绝。

作者执行过恢复验证吗？

本文不宣称作者已经实测恢复。标题描述读者必须执行的验收，结果须来自你的获授权环境，不能把预期当成功。

来源:

3x-ui v3.9.0 — https://github.com/MHSanaei/3x-ui/releases/tag/v3.9.0
3x-ui v3.9.0 — Installer — https://github.com/MHSanaei/3x-ui/blob/v3.9.0/install.sh
3x-ui — Installation — https://github.com/MHSanaei/3x-ui/wiki/Installation
3x-ui v3.9.0 — Backup & Restore — https://github.com/MHSanaei/3x-ui/blob/v3.9.0/docs/content/docs/en/operations/backup-restore.mdx
3x-ui v3.9.0 — Command-line settings — https://github.com/MHSanaei/3x-ui/blob/v3.9.0/main.go
3x-ui — Configuration — https://github.com/MHSanaei/3x-ui/wiki/Configuration
Xray — VLESS inbound — https://xtls.github.io/en/config/inbounds/vless.html
Xray — Transport — https://xtls.github.io/en/config/transport.html

Sources checked 2026 年 10 月 11 日。

延伸阅读:

3x-ui 部署与加固：限制管理入口、独立用户与恢复验证