架构部署 on 寻 Mi 处

受够了密码管理器的订阅费，我自己搭了一个

Wed, 11 Feb 2026 11:20:00 +0800

我用了三年某密码管理器的付费版。

涨价那次我忍了，从每年三十多美元涨到四十多。去年又涨，我看着账单发了会儿呆，然后打开了它的定价页。

家庭版六个人，一年六十美元。我家里真正会用密码管理器的只有我和我老婆两个人。

那天晚上我就在看有没有自建的方案。Vaultwarden 是第一个跳出来的，因为它的定位很明确，就是 Bitwarden 服务端的轻量实现，用 Rust 写的，官方服务端要好几 G 内存，它几十兆就能跑。

它和 Bitwarden 是什么关系

先说清楚，Vaultwarden 不是 Bitwarden 的官方项目，它是一个兼容实现。

它实现了 Bitwarden 的服务端 API，所以官方的所有客户端都能连，浏览器插件、桌面端、手机 App、命令行工具，全都行。你只要在登录界面把服务器地址改成自己的域名。

它的好处是轻。官方服务端是一整套微服务，跑起来要 SQL Server 加一堆容器，没有 4G 内存根本带不动。Vaultwarden 一个二进制文件加 SQLite 就能跑，1G 的机器绰绰有余。

代价是它不是官方维护的，某些新功能会滞后。比如 Bitwarden 前阵子推的 passkey 支持，Vaultwarden 过了一段时间才跟上。不过核心的密码管理功能一直很稳。

部署

我用的是 Docker Compose，目录放在 /srv/vaultwarden。

services:
  vaultwarden:
    image: vaultwarden/server:1.32.7
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.mibase.top"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      DATABASE_URL: "/data/db.sqlite3"
      ROCKET_PORT: "80"
      TZ: "Asia/Shanghai"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8088:80"

几个关键点。

DOMAIN 必须写对，而且必须是 https。它是用来生成邮件里的链接、WebAuthn 的 origin 这些东西的。写错了，注册邀请链接会指向错误的地址。

SIGNUPS_ALLOWED: "false" 是关掉公开注册。不关的话，任何人只要知道你的域名就能注册账号，虽然数据是隔离的，但白占你的资源，还有被滥用的风险。

关掉之后，加人要用邀请。INVITATIONS_ALLOWED: "true" 是开着邀请功能，你可以在管理后台生成邀请链接。

ADMIN_TOKEN 是管理后台的密码。这个值不要写死在 compose 文件里，用环境变量从 .env 文件读。生成方法：

`1`	`openssl rand -base64 48`

ports 只绑 127.0.0.1，不对外暴露。外面通过 nginx 反代进来，这样容器端口不会被直接扫到。

nginx 反代

server {
    listen 443 ssl;
    http2 on;
    server_name vault.mibase.top;

    ssl_certificate     /etc/letsencrypt/live/vault.mibase.top/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.mibase.top/privkey.pem;

    client_max_body_size 128M;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

client_max_body_size 128M 是给附件上传用的。Bitwarden 支持存文件附件，默认的上传限制是一兆，不改的话传大一点的附件会失败。

Upgrade 和 Connection 那两个头是给 WebSocket 用的。Bitwarden 的客户端会用 WebSocket 做实时同步，不配这个，同步会有延迟。

证书

`1`	`sudo certbot --nginx -d vault.mibase.top`

certbot 会自动改 nginx 配置，加上证书路径和 http 到 https 的跳转。

续期是自动的，systemd timer 会每天检查。可以手动测一下：

`1`	`sudo certbot renew --dry-run`

这个一定要测。我见过有人配完就没管，一年后证书过期，所有客户端都连不上。

首次使用

浏览器打开 https://vault.mibase.top，会看到 Bitwarden 的登录页。点"创建账户"，注册第一个账号。

注册完之后，立刻去管理后台把注册关掉。虽然前面已经在环境变量里关了，但保险起见再看一眼：

`1`	`https://vault.mibase.top/admin`

输入 ADMIN_TOKEN 进去，找到 SIGNUPS_ALLOWED，确认是 false。

管理后台里还能看到用户列表、邀请、诊断信息。有个"发送测试邮件"的按钮，配了 SMTP 之后可以用来验证。

邮件

不配 SMTP 也能用，但有些功能会受限。比如忘记主密码的重置邮件、新设备登录的验证邮件、邀请链接的邮件发送。

我的配置：

      SMTP_HOST: "smtp.example.com"
      SMTP_FROM: "vault@mibase.top"
      SMTP_FROM_NAME: "Vaultwarden"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "vault@mibase.top"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"

我用的是某个邮件服务商的免费额度，一个月五百封，够用了。

有个细节，SMTP_SECURITY 的值是 starttls 或者 force_tls，不是 tls。写错了它不会报错，只是发不出去，日志里也看不太出来。

客户端怎么连

浏览器插件和手机 App 的登录界面，都有一个设置服务器的入口。

浏览器插件里，在登录框下面有个齿轮图标，点进去能填"自托管环境"的服务器 URL。

手机 App 上，登录页左上角有个齿轮，点进去填。

填 https://vault.mibase.top，不要带 /admin 或者别的路径。

填完之后回登录页，用刚才注册的账号登录。如果之前用过官方服务，本地已经有数据，会提示你选择"登录到另一个服务器"还是"迁移"。选迁移的话，本地数据会同步到新服务器。

数据在哪儿

/srv/vaultwarden/data/
├── db.sqlite3
├── db.sqlite3-wal
├── db.sqlite3-shm
├── attachments/
├── sends/
├── rsa_key.pem
├── rsa_key.pub.pem
└── icon_cache/

db.sqlite3 是主数据库，所有的密码条目、用户信息都在里面。

rsa_key.pem 是服务端的私钥，用来签名 JWT。这个文件丢了，所有用户都得重新登录。所以备份的时候一定要带上。

attachments 是附件，sends 是临时分享的文件。

备份

因为用的是 SQLite，直接拷贝文件是不安全的，可能有正在写的事务。

正确的做法是用 SQLite 的备份命令：

`1`	`docker exec vaultwarden sqlite3 /data/db.sqlite3 ".backup '/data/backup.sqlite3'"`

这个命令会在数据库层面做一次一致性备份，不会因为并发写入出错。

然后打包：

tar -czf /backup/vaultwarden-$(date +%F).tar.gz \
  -C /srv/vaultwarden/data \
  --exclude='icon_cache' \
  db.sqlite3 backup.sqlite3 attachments sends rsa_key.pem

icon_cache 是网站图标缓存，没必要备份，重新访问的时候会自动下载。

我写了个脚本，每天凌晨跑一次，保留三十天，同步到对象存储。具体写法在另一篇备份的文章里。

恢复

这个流程一定要演练过。

docker compose down
rm -rf data/*
tar -xzf /backup/vaultwarden-2026-02-10.tar.gz -C data/
mv data/backup.sqlite3 data/db.sqlite3
docker compose up -d

注意要先 down 再恢复文件，不然容器还在跑，恢复的文件会被覆盖。

我第一次演练的时候就是忘了停容器，恢复完发现数据还是旧的，还以为是备份有问题。

安全上要注意的

这个服务存的是你最敏感的东西，安全得多花点心思。

ADMIN_TOKEN 要够长，至少四十八个字符的随机串。这个 token 泄露了，别人能改你的配置。

不要开公开注册。即使开了，也要配验证码和邮件验证，否则会被当成免费的密码库来用。

HTTPS 是必须的，不是可选项。客户端的很多功能（WebAuthn、剪贴板 API）在 http 下根本不能用。

考虑加一层 Cloudflare Access，只允许自己的邮箱访问。不过这会影响到手机 App 的连接，因为 App 不方便走浏览器登录。我自己没加，因为 Vaultwarden 本身有登录验证，风险可控。

用下来的感受

到现在用了四个月，手机、电脑、浏览器插件都连着，同步很稳。

速度比官方服务快，因为服务器就在国内，延迟只有几十毫秒。官方服务在国内访问有时候要绕很久。

有一个小遗憾，它没有官方的"紧急访问"功能（就是你挂了之后让别人拿到你的密码库）。社区有替代方案，但要额外配。

还有一个，自托管意味着你得自己保证它一直活着。如果服务器挂了，你又刚好需要查一个密码，那就尴尬了。所以我把重要的几个密码（邮箱、银行、主密码）另外抄了一份在纸上，放在家里。

值不值

一年省六十美元，折合人民币四百多。花的时间大概是一个周末。

如果只看钱，不太值。但这四个月里，我对自己的密码到底存在哪儿、怎么加密的、备份在什么地方，有了完全的掌控。这种确定感是订阅服务给不了的。

当然也有代价。服务器挂了是我的责任，数据丢了我的责任，被人攻破了也是我的责任。用别人的服务，这些责任是别人担的。

这个取舍每个人不一样。我的选择是，愿意为掌控感承担这份责任。

再也不用 scp 传文件了，push 一下博客就上线

Thu, 12 Dec 2024 04:58:00 +0800

以前写博客的流程是这样的。

本地写完，hugo 构建，然后用 FileZilla 把 public 目录拖到服务器上。拖的时候还不能直接覆盖，得先删掉旧的，再传新的，不然会残留一堆已经删掉的文章。

有几次传了一半网断了，网站变成了半新半旧的状态，首页能打开，点进去文章 404。还有一次拖错了目录，把 public 传到了上一级，整站挂了半小时。

后来我改用 rsync，好一些，但还是要手动敲命令。再后来加了 --delete，又差点把服务器上别的目录删了。

这种手动流程，出问题是迟早的。

换个思路

其实我要的事情很简单。本地 git push 之后，服务器上自动更新网站。

Git 本身就能做这件事。服务器上建一个裸仓库，配置一个 post-receive 钩子，每次收到 push 就执行一段脚本。脚本里做的事情就是把代码检出到工作目录，然后构建。

这个方案的好处是不依赖任何外部服务。不用 GitHub Actions，不用 Jenkins，不用装一堆东西。一台有 git 的机器就能跑。

服务器上建裸仓库

登录服务器：

`1`	`ssh blog`

建目录：

1
2

sudo mkdir -p /srv/git/blog.git
sudo chown -R git:git /srv/git

这里我专门建了个 git 用户，不用 root，也不用我自己的账号。原因后面说。

初始化裸仓库：

`1`	`sudo -u git git init --bare /srv/git/blog.git`

--bare 的意思是只有 git 数据，没有工作区。你不能在这个目录里直接看到文件，它是纯粹用来接收 push 的。

建一个工作目录

网站的实际文件要放在另一个地方，比如 /srv/www/blog：

1
2

sudo mkdir -p /srv/www/blog
sudo chown -R git:git /srv/www/blog

注意属主是 git，因为钩子是以 git 用户的身份跑的。如果属主是 root，钩子里的写操作会失败。

写钩子

钩子的位置是固定的：

`1`	`sudo -u git nano /srv/git/blog.git/hooks/post-receive`

内容：

#!/bin/bash
set -euo pipefail

WORK=/srv/www/blog
GIT_DIR=/srv/git/blog.git

while read oldrev newrev refname; do
  if [ "$refname" = "refs/heads/main" ]; then
    echo "==> 部署 main 分支到 $WORK"
    git --work-tree="$WORK" --git-dir="$GIT_DIR" checkout -f main
    cd "$WORK"
    hugo --minify --gc
    echo "==> 部署完成"
  fi
done

给执行权限：

`1`	`sudo chmod +x /srv/git/blog.git/hooks/post-receive`

while read oldrev newrev refname 这一段是标准写法。push 的时候 git 会把每个被更新的引用通过标准输入传给你，格式是三列。只处理 main 分支，别的分支推上来不触发部署。

checkout -f 里的 -f 很重要。它会强制覆盖工作区里的文件，不管有没有本地修改。不加这个，第二次部署就会因为文件冲突失败。

hugo --minify --gc 是构建。--minify 压缩 html、css、js，--gc 清理掉不再引用的缓存资源。这两个参数在 Hugo 0.115 之后都还在用。

本地配置远程

`1`	`git remote add deploy ssh://git@blog.mibase.top/srv/git/blog.git`

或者用 scp 风格的写法：

`1`	`git remote add deploy git@blog.mibase.top:/srv/git/blog.git`

两种都行，前者更明确一点。

然后：

`1`	`git push deploy main`

第一次推的时候，终端里应该能看到钩子输出的那几行。

权限这块是最大的坑

我一开始用的是自己的账号，没建 git 用户。结果钩子跑起来各种 Permission denied。

原因是 SSH 登录的用户和钩子执行脚本的用户必须是同一个，而且这个用户要对工作目录有写权限，对 nginx 的目录也要有读权限。

后来我理清了：

git 用户拥有裸仓库和工作目录。nginx 以 www-data 身份跑，需要有读权限。所以我把工作目录的组设成 www-data，权限给到 750：

1
2
3

sudo chown -R git:www-data /srv/www/blog
sudo chmod -R 750 /srv/www/blog
sudo usermod -aG www-data git

这样 git 用户能写，www-data 能读，别人进不来。

还有一个 SELinux 的问题。如果你用的是 CentOS 或者 RHEL，默认的 SELinux 策略会阻止 nginx 读 /srv 下面的文件。得打标签：

1
2

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/www/blog(/.*)?"
sudo restorecon -Rv /srv/www/blog

Debian 和 Ubuntu 没这个烦恼。

只给 git 用户最小权限

用 git 用户有个额外的好处，就是可以限制它能做的事。

编辑 /etc/passwd，把这个用户的 shell 从 /bin/bash 改成 /usr/bin/git-shell：

`1`	`git:x:998:998::/srv/git:/usr/bin/git-shell`

git-shell 是一个受限的 shell，只允许 git 相关的命令，别的命令一律拒绝。这样就算有人拿到了这个账号的私钥，也登不进交互式的 shell，只能在 git 协议里操作。

这个设置很值得做。我之前的机器被人扫过 SSH 密码，虽然没成功，但那之后我就把能限制的地方都限制了。

nginx 那边

配置里 root 指到工作目录的 public：

server {
    listen 443 ssl http2;
    server_name blog.mibase.top;

    root /srv/www/blog/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Hugo 构建完之后，静态文件在 public 子目录里，所以 root 要指到那一层。

增量构建的问题

如果博客文章多了，每次全量构建会比较慢。Hugo 支持增量：

`1`	`hugo --minify --gc --buildDrafts=false`

不过增量构建有它自己的问题，改了模板或者配置之后，有时候不会重新生成所有页面，导致部分页面还是旧的。我的经验是，日常发文用增量，改主题或者配置的时候手动跑一次全量。

Hugo 0.123 之后引入了一个 --renderToMemory 的选项，构建更快，但对大站内存要求高。我这种几十篇文章的站感觉不出差别。

多个站点的做法

后来我又加了一个笔记站，用的是同一套方案。

裸仓库和钩子都是独立的，互不干扰。唯一要改的是钩子里的路径和构建命令。

我把钩子的公共部分抽成了一个脚本，放在 /srv/git/deploy.sh，两个钩子都去调它，传不同的参数：

#!/bin/bash
set -euo pipefail
WORK=$1
BRANCH=${2:-main}

while read oldrev newrev refname; do
  if [ "$refname" = "refs/heads/$BRANCH" ]; then
    git --work-tree="$WORK" --git-dir="$GIT_DIR" checkout -f "$BRANCH"
    cd "$WORK"
    hugo --minify --gc
  fi
done

GIT_DIR 是 git 在执行钩子时自动设的环境变量，不用自己传。

出问题怎么回滚

这个方案有个小遗憾，它没有版本回退的功能。工作目录里永远是 main 分支的最新内容。

要回滚的话，有两个办法。

一个是在本地 revert 一个 commit，再 push 一次。这个最干净，历史是线性的。

另一个是直接在服务器上操作：

cd /srv/www/blog
git log --oneline -5
git checkout <COMMIT_ID> -- .
hugo --minify --gc

但这样工作目录会和裸仓库脱节，下次 push 的时候 checkout -f 会把你的手动修改全冲掉。所以我一般用第一种。

什么时候该换个方案

这套方案适合个人博客，不适合团队协作。

如果有多个人一起维护，你可能会想要在 push 之后跑测试、跑 lint、生成预览链接。这些用 GitHub Actions 或者 Gitea 的 CI 会方便很多。

还有一种是构建时间很长的站。我见过有人 Hugo 站有几千篇文章，全量构建要三分钟。这种情况下每次 push 都要等三分钟，体验不好，得考虑缓存或者增量。

我现在的站只有几十篇，构建三秒，用这套方案正合适。

现在的感受

最大的变化是心理上的。

以前想写点东西，会先想到"还得传文件"，这个念头本身就会让人拖延。现在打开编辑器就写，写完 push，完事。中间那一步消失了，写东西的阻力小了很多。

这种小工具的收益，往往不在技术本身，而在它把你从一件烦人的事情里解放出来。省下的那几分钟不重要，重要的是你不再因为烦而逃避。

家里那台小主机没有公网 IP，我用 Cloudflare Tunnel 把它挂上了网

Thu, 29 Feb 2024 19:44:00 +0800

搬进新租的房子之后，第一件让我难受的事就是宽带没有公网 IP。

装机师傅上门那天我特意问了，他说现在都这样，上面统一做的 NAT，想开端口得另外找客服申请，而且就算申请下来也是动态的，重启光猫就换一个。我试着在路由器上拨号看了一下，WAN 口拿到的是 100.64.x.x，运营商级 NAT 的内网地址，彻底没戏。

问题是我家里有台常年开着的小主机，跑着几个自己写的小服务。一个是用来看照片的相册，一个是给家里人用的备忘录，还有一个是给小孩做的手工课视频站。以前在旧房子那边有公网 IP，路由器上做个端口映射，出门在外随时能打开。现在全断了。

试过的几种方案

先说被排除的。

花生壳那类内网穿透我最早试过，免费版带宽小得可怜，而且域名是一长串随机字符，发给家里人他们根本记不住。付费版按年收费，我看了一眼价格，不如直接买台有公网 IP 的 VPS。

frp 我用了差不多一年。自己在香港买了台 1 核 1G 的小机器当跳板，家里跑 frpc，外面跑 frps。能用，但有几个麻烦。跳板机的带宽是个硬瓶颈，我买的那台是 30M 峰值，实际晚上跑起来经常掉到 5M 以下，看个视频就卡。而且这台机器我得自己维护，系统更新、证书续期、被扫了还得上去看看，一年下来也是一笔精力。

后来在 V2EX 上看到有人提 Cloudflare Tunnel，我一开始以为是那种要企业套餐的付费功能，点进去看了才知道，免费版也能用，而且不限流量。这个就值得试了。

它到底是怎么工作的

原理说起来很简单。

cloudflared 这个程序装在你的内网机器上，它主动往外连 Cloudflare 的边缘节点，建立一条长连接。这条连接是出站的，所以你不需要有公网 IP，也不需要动路由器上的任何设置。外面的人访问你的域名，请求先到 Cloudflare，Cloudflare 顺着这条已经建好的隧道把请求送进来，你的机器响应之后再原路返回。

因为隧道是 cloudflared 主动发起的，中间不存在任何入站端口，家里的防火墙和运营商的封禁都不受影响。

还有个好处是，你不需要在路由器上开任何端口。以前做端口映射的时候，我总担心哪天路由器固件有漏洞被人扫到，现在这条路直接堵死了。

装起来

我的小主机是 Debian 12，直接加官方源装最省事。

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

装完 cloudflared --version 能出版本号就行。

接下来登录。这一步会给你一个很长的链接，你得复制到浏览器里打开：

`1`	`cloudflared tunnel login`

浏览器里会让你选一个域名授权。我的域名在 Cloudflare 上托管，选它，然后它会自动在你的 DNS 里加一条 cert.pem 用的授权。授权文件落在 ~/.cloudflared/cert.pem。

注意这个 cert 是按域名授权的，一个域名一个文件。如果你有多个域名都要用，得分别登录一次。

创建隧道和配置

`1`	`cloudflared tunnel create homelab`

它会生成一个 UUID，并且在 ~/.cloudflared/ 下面放一个同名的 json 文件，里面是隧道的凭据。这个文件是密钥，别传 GitHub 上去。

然后写配置文件，位置在 ~/.cloudflared/config.yml：

tunnel: homelab
credentials-file: /home/mingyue/.cloudflared/8f3c1a2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  - hostname: photo.mibase.top
    service: http://127.0.0.1:8081
  - hostname: note.mibase.top
    service: http://127.0.0.1:8082
  - hostname: craft.mibase.top
    service: http://127.0.0.1:8083
  - service: http_status:404

ingress 是从上往下匹配的，最后那条兜底必须写，不然配置检查会报错。

还有一个细节，如果你内网的服务绑的是 0.0.0.0，用 127.0.0.1 也没问题。但如果服务只监听 IPv6，就得写成 http://[::1]:8081。

把 DNS 指过去

1
2
3

cloudflared tunnel route dns homelab photo.mibase.top
cloudflared tunnel route dns homelab note.mibase.top
cloudflared tunnel route dns homelab craft.mibase.top

它会自动在 Cloudflare 里加 CNAME，指向 <UUID>.cfargotunnel.com，并且是橙云状态，也就是走代理。

这三条加完，DNS 那块就不用手动动了。

跑成服务

前台跑着测试没问题之后，换成 systemd 托管：

1
2

sudo cloudflared service install
sudo systemctl enable --now cloudflared

然后看状态：

1
2

sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f

日志里能看到四条连接建起来的信息。Cloudflare 默认会建四条，冗余用的，一条断了另外几条顶上，切换的时候用户基本无感。

访问控制和登录验证

隧道跑通之后，第一个冒出来的念头是：这玩意儿是不是谁都能访问。

是的，默认就是公开的。所以我立刻去配了 Cloudflare Access。

在 Zero Trust 后台里，Access 下面的 Applications，新建一个 Self-hosted 应用。域名填 note.mibase.top，然后建一条策略，Action 选 Allow，Include 里选 Emails，把我自己和家里人的邮箱填进去。

配完之后再访问，会先跳到一个 Cloudflare 的登录页，输入邮箱收验证码，通过了才放行。免费版给五十个用户，够用了。

给小孩看的视频站我没加验证，那个本来就是想分享给亲戚的，加了反而麻烦。

顺手做的一件事

既然流量都过 Cloudflare 了，缓存规则也可以顺手配上。视频站的封面图我设了一年的 Edge TTL，这样重复访问基本不消耗回源带宽。

这个和博客那边是同一套思路，静态的东西缓存长一点，动态的别缓存。

和 frp 比到底差在哪

用了一个多月，我的感受是这样的。

带宽上 Cloudflare 明显强。它是全球任播，国内访问会落到就近的节点，实际测下来晚上也能跑满我家的上行。frp 那台跳板机受限于单机带宽，这点没法比。

省心程度上也是 Cloudflare 好。跳板机不用自己维护，证书它帮你签，系统补丁不用管，被打也不用管。这一点对我这种懒得折腾的人来说很重要。

但也不是没代价。

延迟会比直连高一些，毕竟多绕了一层。我在家用局域网访问，走的是本地地址，没影响；在外面访问大概多二十毫秒，日常用感觉不出来，但如果你要跑远程桌面，那点延迟是能感觉到的。

另外就是把一部分控制权交出去了。域名、证书、访问日志都在 Cloudflare 那边。真要哪天它改政策或者涨价，迁移的成本不算低。所以我一直保留着 frp 的配置没删，算是个备份方案。

还有一点，免费版对 WebSocket 的支持是有的，但长连接有时候会被掐。我那个相册里的实时同步功能就偶尔断，后来改成轮询才稳定下来。

遇到的两个坑

一个是 cloudflared 的内存占用。这东西跑久了会慢慢涨，我有一次看它吃了 400 多兆。后来加了个定时重启，每天凌晨重启一次，问题就没了。官方 issue 里也有人反馈过，看起来还没彻底修。

另一个是回源协议。我的服务是 http，如果 service 写成 https://127.0.0.1:8081，会报 TLS 握手失败。改成 http:// 就好。这个错我当时找了半天，因为日志里只写了个 502，没提 TLS。

现在的情况

三个服务稳定跑了一个多月，家里人也习惯了直接输域名访问，不再问我"那个链接是多少"。

回头看，这件事最舒服的地方不是技术多新，而是它把一件需要长期维护的事情变成了不用管的事情。以前跑 frp，我每个月至少要看一眼那台跳板机，现在这块彻底从我待办里消失了。

给 Cloudflare 配上缓存规则之后，博客的图片终于不用每次回源了

Mon, 05 Feb 2024 02:45:00 +0800

域名托管到 Cloudflare 有一段时间了，页面打开速度一直说不上好。白天在公司摸鱼的时候打开自己的博客，首屏的图片总是一块一块地往下蹦，像是网速被谁掐了一半。

打开 F12 看 Network，问题挺明显的。那些几十 KB 的封面图，每一张的响应时间都在三百毫秒往上，而且不管我刷新多少次，它都是这个速度。点开 Response Headers 一看，CF-Cache-Status 是 MISS，有时候干脆是 DYNAMIC。意思很清楚，Cloudflare 根本没帮我存，每次都是它跑回我的 VPS 拿一遍，再转手给我。

我这才认真去看了它的缓存逻辑。

默认只缓存一小撮东西

Cloudflare 的免费套餐对缓存是做了限制的。它只对一部分后缀名有默认缓存行为，比如 css、js、图片、字体这些。听起来好像我需要的都在里面，但实际上还有一个坑，就是缓存时长很短，而且第一次请求之后 Edge 节点上存不存、存多久，还要看源站给的 Cache-Control。

我的 Nginx 那时候配置得很随便，静态资源只写了 expires 7d，别的什么都没管。Cloudflare 拿到这个头，就按七天存。听着还行，可我博客的图换了之后，七天之内访客看到的还是旧图，这个体验很别扭。

后来我把思路理清楚了。图片、字体、css、js 这些东西带上内容指纹，改一次文件名就变一次，这种资源可以放心地缓存很久，甚至一年。HTML 不行，HTML 一改就得让用户立刻看到新的。

换成 Cache Rules

网上很多老教程还在教你用 Page Rules。这个功能 Cloudflare 从 2023 年就开始推着大家迁走了，免费套餐能建的条数也少，表达式写法也老旧。现在应该用的是 Rules 里的 Cache Rules，逻辑更清楚，条件可以写得很细。

我进控制台，左边找到 Rules，点 Cache Rules，Create rule。

名字随便起，我写的是 static-assets。下面 When incoming requests match 那里，选 Custom filter expression，然后填：

`1`	`(http.request.uri.path.extension in {"jpg" "jpeg" "png" "gif" "webp" "svg" "ico" "css" "js" "woff" "woff2" "ttf"})`

这个写法比老教程里那种一串 contains 拼起来要干净得多，它是直接判断路径后缀。

Then 那部分做这些设置：

1
2
3

Cache eligibility: Eligible for cache
Edge TTL: Ignore cache-control header and use this TTL -> 1 month
Browser TTL: Override origin -> 1 month

Edge TTL 是 Cloudflare 自己节点上存多久，Browser TTL 是告诉访客的浏览器存多久。两个都拉长，命中率才上得去。免费套餐的 Edge TTL 最长就是一个月，够用了。

这里有个细节值得说一下。如果你选的是 Use cache-control header if present，那 Cloudflare 就会听源站的，你 Nginx 里写 7 天它就是 7 天。想让 Cloudflare 说了算，就得选 ignore 那一项。我第一次没注意，改完发现一点变化都没有，白折腾了半小时。

HTML 也可以缓存，但要小心

纯静态博客有个好处，HTML 也是构建出来的静态文件，没有数据库查询，缓存起来毫无压力。我另外加了一条规则，只针对 HTML：

`1`	`(http.request.uri.path.extension eq "")`

然后 Edge TTL 设成 2 小时，Browser TTL 设成 30 分钟。

为什么留这么短。因为我一改文章就得让人看到新的。两小时对我来说是个能接受的窗口，写完文章去 Cloudflare 那边手动 Purge 一下就行。如果哪天忘了 Purge，最多两小时也会自己过期，不至于一直挂着旧内容。

Browser TTL 我压得更短，是因为浏览器缓存最难清。用户本地存着的 HTML，你在服务器上怎么改他都不知道，只能等他缓存过期。30 分钟是个折中。

源站那边也得配合

只改 Cloudflare 不管源站，效果会打折扣。我在 Nginx 里把静态资源的响应头重写了一遍：

location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

immutable 这个值挺有用。它告诉浏览器，这个文件在有效期内绝对不会变，用户按 F5 刷新的时候不用再发一次条件请求。少了这个 304 往返，刷新页面的感觉会明显快一截。

前提是你的文件名得带指纹。Hugo 生成的 css 和 js 默认是带 hash 的，图片是我自己命名的，没带。所以我给图片加了个小约定，文件名后面缀上内容的前八位哈希，改图就改名，这样缓存一年也不会出问题。

验证到底有没有生效

改完之后别急着高兴，得实际去看。

最直接的办法是 curl：

`1`	`curl -sI https://blog.mibase.top/images/cover.jpg \| grep -i cf-cache`

第一次大概率是 MISS，这是正常的，节点上还没有。再跑一次，应该就变成 HIT 了。如果跑了好几次还是 MISS，那就回去看看规则的条件是不是没匹配上，或者 Cache eligibility 是不是还停在 Bypass cache。

还有一个 DYNAMIC，这个值的意思是 Cloudflare 认为这个请求不该走缓存。通常出现在 HTML 上，或者规则没命中。

我还注意到有个 REVALIDATED，那是源站返回了 304，Cloudflare 拿旧的继续用。这个状态其实也挺好，至少没重新传一遍完整内容。

命中率从四成到九成

Cloudflare 控制台的 Caching 下面有个 Analytics，能看到缓存命中率。我改之前是 41% 左右，改完第二天稳定在 92% 上下。

这个数字带来的变化是很实在的。以前国内访问我的博客，图片要绕到我的 VPS 上拿，VPS 在洛杉矶，一个来回就是两百多毫秒。现在大部分请求落在 Cloudflare 离用户最近的节点上，二三十毫秒就回来了。

还有一个连带的好处，源站的带宽掉得很明显。Cloudflare 后台显示回源流量少了七成多，我那台按流量计费的机器，账单也跟着降了。

几个踩过的坑

规则是有优先级的，同一个请求命中多条规则时，只有最上面那条生效。我一开始把 HTML 的规则放在最前面，结果图片规则被它盖住了，因为 HTML 那条的条件写得太宽。顺序一定要捋一遍。

Purge Everything 别乱点。它会把你所有节点上的缓存全部清掉，清完之后的一段时间里，所有请求都会压到源站上。我手滑点过一次，那一分钟 VPS 的负载直接飙到 8。后来我都是按 URL 精确 Purge。

还有 Vary 头。如果你的源站返回了 Vary: Cookie 之类的东西，Cloudflare 基本就不会缓存这个响应了，因为同一个 URL 对应太多变体。静态博客一般没这个问题，但如果你在 Nginx 里加过什么奇怪的配置，值得检查一下。

写在最后

这件事的性价比确实高。不用升级套餐，不用换服务器，只是把规则写对，速度就上了一个台阶。

我现在给静态站做优化的顺序基本固定了。先看资源有没有带指纹，再看缓存头怎么写，最后才去考虑 Cloudflare 那层。前面两步做扎实，CDN 才帮得上忙。顺序反过来的话，你在 CDN 后台点半天，源站一个 no-cache 就把你打回原形。