在进行 VPS 迁移或系统重构之前，对当前服务器中正在运行的服务进行一次系统级审计是非常必要的。这不仅可以避免迁移过程中出现端口占用、服务冲突，还可以发现隐藏的云厂商组件与多余的后台服务，从而为构建一个“干净、可控的中继节点”打下基础。
本文记录了一次对云服务器 systemd 服务的完整盘点、来源识别以及迁移前停机处理的全过程。
一、列出正在运行的服务
在 Linux VPS 上，可以通过 systemd 查询当前所有处于 running 状态的服务：
systemctl list-units --type=service --state=running --no-pager
这一步可以看到当前系统里有哪些 daemon 正在常驻运行，例如网络服务、日志系统、安全组件以及第三方业务服务。
二、识别服务来源（系统 vs 用户 vs 云厂商）
仅仅看到服务名是不够的，关键在于知道它们是：
- 系统自带
- 云厂商镜像预装
- 用户自行安装
最重要的信息是每个 service unit 的 FragmentPath，即它的 .service 文件位于哪里：
for s in $(systemctl list-units --type=service --state=running --no-legend | awk '{print $1}'); do
systemctl show -p FragmentPath "$s"
done
经验规律：
| 路径 | 含义 |
|---|---|
/lib/systemd/system/ | 系统包提供 |
/usr/lib/systemd/system/ | 系统或第三方包 |
/etc/systemd/system/ | 用户或云厂商手动放入 |
这一步可以精确区分哪些服务是系统必须的，哪些是后期被引入的。
三、识别“真正的业务服务”
通过 unit 路径与已手动安装的软件包列表（apt-mark showmanual）对照，可以清晰分离出真正用于公网通信与远程访问的核心服务：
| 类型 | 作用 |
|---|---|
| 代理服务 | 提供对外的网络代理入口 |
| 穿透服务 | 为内网节点提供公网访问能力 |
| 远程桌面中继 | 支撑远程控制与设备连接 |
| 安全防护 | 防止 SSH 被暴力破解 |
这些构成了 VPS 作为“中继节点”的全部业务价值。
四、发现云厂商控制组件
在云服务器镜像中，通常会预装一套云厂商 Agent，例如：
- 远程命令执行
- 云端监控
- 安全扫描
- 故障诊断
这些组件以 systemd 服务的形式存在，且 unit 文件通常位于 /etc/systemd/system/，而对应的软件包也会出现在手动安装列表中。
从技术角度看，这意味着：
云厂商对该 VPS 拥有持续的远程控制与监控能力。
在构建代理、中继或邮件服务器等对隐私与网络行为高度敏感的用途时，这是一个必须被纳入威胁模型的因素。
五、识别 VPS 场景中“无意义”的服务
云镜像往往基于“桌面或通用 Linux”构建，会带来一些在 VPS 上完全没有价值的后台服务，例如：
- 固件升级守护进程
- U 盘与热插拔设备管理
- 调制解调器管理
- 多路径存储
- 桌面软件管理服务
这些服务：
- 占用内存与 CPU
- 增加攻击面
- 增加 systemd 依赖复杂度
但对代理、中继、远程访问没有任何贡献。
六、迁移前：安全关闭公网服务
在进行 VPS 迁移（例如快照、磁盘复制、重建实例）前，必须先停掉所有对外服务，避免：
- 端口占用
- 活跃连接锁定
- 数据不一致
标准操作：
systemctl stop <服务1> <服务2> ...
systemctl disable <服务1> <服务2> ...
这样可以让 VPS 进入一个干净、无业务的静态状态，非常适合迁移、镜像或克隆。
迁移完成后，只需重新 enable + start 即可原样恢复全部公网功能。
七、最终目标：中继专用的最小化 VPS
理想状态下，这类服务器只需要：
- systemd
- 网络与 DNS
- SSH
- 日志
- 防火墙
- 代理 / 穿透 / 中继服务
其它云厂商 Agent、桌面组件、硬件管理服务，都可以被剥离。
这将带来：
- 更少的进程
- 更少的攻击面
- 更稳定的网络行为
- 更可控的长期运行环境
结语
VPS 并不是“买来就干净的服务器”。
通过 systemd 与包管理器的交叉审计，才能真正看清一台云服务器的真实构成。
在任何迁移、重构或长期部署之前，做一次这样的体检，都是极其值得的。