目录布局、验证与日常运维
/srv 是服务运行区
/srv适合存放这台机器所提供服务的站点数据和运维文件。先创建 统一空目录，可以让后续 Compose 项目有稳定位置：
[REMOTE: VPS]
sudo mkdir -p \
/srv/caddy \
/srv/rsshub \
/srv/infohub \
/srv/uptime-kuma \
/srv/backups
sudo chown -R "$VPS_USER:$VPS_USER" /srv
在执行递归 chown前必须先查看 /srv；如果已有其他用户或服务的数据，不能盲目改变所有权。空的 /srv/backups也不是备份系统：没有备份计划、版本、异地副本和恢复演练，就只有一个名字很有希望的目录。
systemd 的三个常用问题
systemctl is-active docker # 现在是否正在运行？
systemctl is-enabled docker # 下次开机是否自动启动？
systemctl status docker --no-pager
active与enabled互不替代。服务故障时：
sudo journalctl -u docker --since today --no-pager
sudo journalctl -u tailscaled --since today --no-pager
sudo journalctl -u ssh --since today --no-pager
systemctl --failed --no-pager
日志可能包含 IP、用户名、路径或应用数据，公开前先脱敏。
软件更新例行流程
[REMOTE: VPS]
sudo apt update
apt list --upgradable
sudo apt upgrade
先阅读升级摘要。如果需要自动化，可先用 apt-get -s模拟。Ubuntu phased updates 会让一部分普通更新暂时保持不升级；这是分批发布，不应与依赖冲突混为一谈。
检查重启需求：
if [ -f /var/run/reboot-required ]; then
cat /var/run/reboot-required
else
echo "No reboot required"
fi
需要重启时，先验证当前 OpenSSH-over-Tailscale，保留会话，执行 sudo reboot，等待机器返回后重新连接并复查内核与失败服务。
完整健康检查
[REMOTE: VPS]
hostnamectl
timedatectl
nproc
free -h
df -h /
ip -brief addr
ip route
tailscale status
tailscale ip -4
systemctl is-active tailscaled
sudo ufw status verbose
sudo ufw status numbered
sudo sshd -t
sudo sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
docker --version
docker compose version
systemctl is-active docker
docker info --format \
'ServerVersion={{.ServerVersion}} Driver={{.Driver}} CgroupDriver={{.CgroupDriver}}'
docker ps -a
systemctl --failed --no-pager
find /srv -maxdepth 2 -printf '%M %u:%g %p\n' | sort
再从 WSL2 验证：
[LOCAL: WSL2]
# 应成功
ssh -o ConnectTimeout=10 "$VPS_USER@$TAILSCALE_IPV4"
# 应失败
ssh -o ConnectionAttempts=1 -o ConnectTimeout=5 \
"$VPS_USER@$VPS_PUBLIC_IPV4"
建议的检查节奏
| 频率 | 检查 |
|---|---|
| 每次变更后 | 新 SSH 会话、相关服务状态、UFW、docker ps |
| 每周 | 可升级包、失败单元、磁盘、容器状态 |
| 每月 | Tailscale 设备、SSH key、暴露端口、日志增长 |
| 每次部署 | Compose diff、端口绑定、卷、健康检查、回滚方案 |
| 定期演练 | 从备份恢复，而不只是确认备份文件存在 |
故障处理优先级
- 保住访问：不要关闭最后一个工作会话。
- 停止扩大变更：不要连续尝试互相覆盖的“修复”。
- 确认层次：路由、端口、防火墙、daemon、认证逐层检查。
- 收集非敏感证据：状态、退出码、时间和最近日志。
- 恢复最近的安全状态：优先添加临时访问，而不是重置系统。
- 验证恢复：仍需一个全新连接或完整请求。
长时间操作可以放在 Tmux 中，避免本地网络抖动让升级或排障过程失去终端。Tmux 保护远程 shell 进程，但不能替代第二条 SSH 访问路径。
基础阶段之后
下一阶段才适合部署反向代理和监控，再迁移一个低风险服务。每个服务至少需要回答：入口在哪里、数据存哪里、怎样升级、怎样回滚、怎样备份、怎样确认它真的健康。