跳到主要内容

个人 VPS 入门

这组笔记记录的是一条稳妥的个人服务器建设路线：先确认机器身份，建立不会把自己锁在门外的远程访问，再安装容器运行环境和共享入口，最后用 RSSHub 验证第一个真实应用部署路径。Phase 3 仍是影子部署：新 RSSHub 已经可用，但既有 feed consumer 继续使用本地 RSSHub，尚未切换生产消费者。

如果还在选择应用运行在哪里，可以把这里的自管服务器方案与 Cloudflare Workers、Google Cloud 的 Cloud Run 教程对照阅读。后两篇介绍托管运行、权限、存储和计费；这组笔记着重说明怎样维护 Linux 主机本身。

先看整体：这台服务器有两扇门​

可以先把 VPS 想成一间放在互联网上的机房。现在有两条完全不同的进入路线：

  1. 管理入口只给自己使用：WSL2 先走 Tailscale 私网，再由 OpenSSH 验证密钥并打开远程终端。
  2. 网站入口给互联网访客使用：所有公开 HTTP/HTTPS 请求先到 Caddy，再由 Caddy 决定交给哪个网站或 API。

Uptime Kuma 是管理工具，不是公共网站。它没有公网入口；自己查看时，要临时建立一条 SSH 隧道。

[自己：WSL2]
    `-- Tailscale 私人道路
          `-- OpenSSH 上锁的管理门
                `-- [Ubuntu VPS]

[互联网访客]
    `-- TCP 80/443
          `-- Caddy 公共前台
                |-- 基础设施健康检查
                `-- infra-edge 内部走廊 -> RSSHub:1200

[VPS 内部]
    |-- Docker：分别运行 Caddy、Uptime Kuma 与 RSSHub
    |-- UFW：控制哪些主机端口允许进入
    |-- Uptime Kuma：只在 127.0.0.1:3001 等待 SSH 隧道
    `-- RSSHub：1200 只在 Docker 网络中可达，不发布到主机

[现有本地环境]
    `-- feed consumer -> 本地 RSSHub（继续作为生产路径和回退）

这里有三层经常被混为一谈：

  1. 网络可达性决定数据包能否到达 VPS。
  2. OpenSSH提供加密会话并验证服务器身份。
  3. SSH 公钥认证证明登录者拥有对应私钥。

Tailscale 在这套结构中只提供私有网络路径。真正监听 22 端口和验证用户公钥的仍是 Ubuntu 的 OpenSSH；没有启用另一个名为 Tailscale SSH 的产品功能。

先认识这些词​

词语在本系列中的含义
VPS云厂商提供的虚拟 Linux 机器
公网 IP整个互联网可能路由到的地址
Tailscale IP只在同一 tailnet 内可达的 100.x.x.x 地址
端口一台主机上某个网络服务的入口，例如 SSH 的 TCP 22
daemon后台长期运行的服务进程，例如 sshd、tailscaled、dockerd
systemdUbuntu 管理服务、启动状态和日志的系统
UFWUbuntu 的主机防火墙管理工具
镜像创建容器所用的只读模板
容器镜像运行后的隔离进程及其运行状态
Compose用 YAML 描述一组容器、网络和卷的 Docker 插件

当前安装或启用的工具​

以下组件在 Phase 1 至 Phase 3 中实际安装、启用或明确配置。先用生活类比理解职责，再记技术名字就容易得多。

负责“让我安全登录”的工具​

工具可以把它理解成实际解决的问题
OpenSSH Server一扇需要正确钥匙才能打开的管理门确认登录者持有已登记公钥对应的私钥，再提供远程命令行；私钥本身不会发给服务器
Tailscale只连接自己设备的私人道路让 WSL2 能通过私网地址找到 VPS，避免把管理入口直接暴露给整个互联网
UFW门口的访客名单默认拒绝陌生入站连接，只允许公网 Web 端口，以及从 Tailscale 网卡进入的 SSH

Tailscale 和 OpenSSH 不是同一个东西：Tailscale 负责把路铺到服务器，OpenSSH 负责到门口后验钥匙。

负责“运行服务”的工具​

工具可以把它理解成实际解决的问题
Docker Engine管理许多独立房间的物业系统把每项服务放进独立容器中运行，并管理镜像、网络和数据挂载
Docker Compose每个房间的布置与启动说明书用一个 YAML 文件记录服务使用什么镜像、数据放哪里、开放什么端口、重启后是否自动回来
Docker Buildx制作新房间模板的工具台当现成镜像不够用时构建自己的 Docker 镜像；平时运行 Caddy 和 Kuma 不需要操作它

当前三套说明书分别放在 /srv/caddy/compose.yaml、/srv/uptime-kuma/compose.yaml 与 /srv/rsshub/compose.yaml。它们互相独立，所以重启 RSSHub 不会顺手重启公网入口或监控。

负责“公网入口与监控”的工具​

工具可以把它理解成实际解决的问题
Caddy网站的公共前台统一接收公网 80/443 请求，自动处理 HTTPS 证书和 HTTP 跳转，再把请求交给正确服务
Uptime Kuma值班员和状态看板定期访问健康检查地址，记录服务是否在线；管理界面只给自己看
RSSHub把网站更新整理成订阅源的翻译站运行真实 RSS 路由，并用 ACCESS_KEY 阻止陌生人随意消耗这个私人实例

Caddy 和 RSSHub 都加入了名为 infra-edge 的 Docker 网络。它可以被理解成“前台通往网站服务的内部走廊”：Caddy 通过别名 rsshub-prod 找到 RSSHub，但 RSSHub 不需要把 1200 端口开放给主机或互联网。Kuma 不加入这条公网代理路径；它继续只通过 SSH 隧道管理。

我平时什么时候会碰到它们？​

  • 登录 VPS：确认 Tailscale 已连接，然后使用 ssh；背后由 Tailscale、UFW 和 OpenSSH 一起完成。
  • 启动、停止或查看服务：使用 docker compose；通常不直接操作 Docker 的底层文件。
  • 访问 Kuma：先建立 SSH 本地转发，再打开 http://127.0.0.1:3001；不要把 3001 改成公网端口。
  • 查看公开健康状态：访问 Caddy 提供的 HTTPS /healthz 地址。
  • 使用 RSSHub：消费者访问 HTTPS 域名并携带 ACCESS_KEY；密钥只从受保护的 VPS .env 交给受信任消费者，不写入公开笔记或监控 URL。
  • Buildx：只有需要自己构建镜像时才使用，日常运维通常不用碰。

记住这三条边界就够了​

  • 公网能进入的只有 TCP 80/443，并且先到 Caddy。
  • SSH 只走 Tailscale 私网；公网 SSH 保持阻断。
  • Kuma 只监听 VPS 自己的 127.0.0.1:3001，通过 SSH 隧道查看。
  • RSSHub 的 1200 不绑定主机地址，只能由 infra-edge 内的 Caddy 访问。

UFW 显示 active 也不能单独证明 Docker 端口安全，因为 Docker 有自己的端口转发规则。每次新增服务都要同时检查 Compose 端口、Docker 实际绑定和外部连接结果。具体命令见在现有服务旁增加新服务，部署时间线见构建日志。

推荐阅读顺序​

  1. 架构、安全边界与基础命令
  2. SSH 密钥登录与安全加固
  3. Tailscale 私网与 OpenSSH
  4. UFW 防火墙与防锁死流程
  5. Docker Engine 与 Compose
  6. 目录布局、验证与日常运维
  7. Tmux 实用指南
  8. 在现有服务旁增加新服务
  9. RSSHub 生产影子部署

四条最高优先级规则​

  • 每条命令先确认是在 本地 WSL2 还是 远程 VPS 执行。
  • 永远不要删除最后一条已验证的 SSH 访问路径。
  • 修改 SSH 或防火墙后，用一个全新的连接验证；旧会话存活不等于新连接可用。
  • 私钥、密码、认证令牌和恢复码不进入命令输出、笔记、Git 或聊天记录。

示例变量​

本系列用占位符代替真实机器信息：

VPS_USER=ubuntu
VPS_PUBLIC_IPV4=<public-ip>
TAILSCALE_IPV4=<100.x.x.x>
LOCAL_SSH_PUBLIC_KEY="$HOME/.ssh/id_ed25519.pub"

不要把密码、私钥或 Tailscale auth key 保存成这些变量。

当前完成边界​

Phase 1 至 Phase 3 完成后，当前得到一台：

  • 系统已更新、主机名和时区正确的 Ubuntu VPS；
  • 只能用公钥认证、禁止 root 直接登录的 OpenSSH 服务器；
  • 可以通过 Tailscale 私网建立 OpenSSH 会话的机器；
  • 公网仅开放未来 Web 入口 80/443，不再普遍开放 22；
  • Docker、Buildx 与 Compose 可用，Caddy、Uptime Kuma 和 RSSHub 分属独立 Compose 项目；
  • Caddy 是唯一公网容器入口，Kuma 管理界面保持 loopback-only；
  • RSSHub 使用官方固定摘要镜像、内存缓存和 ACCESS_KEY，并且没有主机端口；
  • 公网 HTTPS 健康检查、未认证拒绝、认证真实路由、监控和应用重启都已验证；
  • /srv 已保存服务配置与持久数据，但“有数据目录”不等于“有备份”；
  • 能用 Tmux 保持运维会话，并按独立 Compose 项目逐步增加服务。

feed consumer 的生产配置、持久数据、调度器和本地 RSSHub 均未改变。消费者切换、数据备份与恢复证明、调度迁移和本地回退退役决定属于 Phase 4。

官方资料​

探索关联

用在这里 (1)

相关讨论 (7)

引用了 (12)

被引用 (3)

打开关联网络