服务器运维 on 寻 Mi 处

每天几千次爆破登录，我把 SSH 彻底加固了一遍

Tue, 18 Aug 2026 00:33:00 +0800

新买的 VPS，装完系统第一次登录，我习惯先看一眼日志。

`1`	`journalctl -u ssh --since "1 hour ago" \| grep -c "Failed password"`

三百多次。这才开机一个小时。

再看来源，全世界各地，用户名从 root 到 admin 到 oracle 到 test，全都是自动化脚本在扫。

这些尝试基本不可能成功，因为我的密码是随机生成的。但看着这些日志还是不舒服，而且它们会占带宽、占 CPU、把日志撑大。

所以每台新机器，我都会花半小时把 SSH 加固一遍。

先建一个普通用户

root 直接登录是最危险的。一旦密码泄露，攻击者拿到的是最高权限。

建一个普通用户：

1
2

adduser mingyue
usermod -aG sudo mingyue

Debian 和 Ubuntu 上 sudo 组有 sudo 权限。CentOS 上是 wheel 组。

然后测试这个用户能不能登录、能不能 sudo。这一步很重要，因为后面要禁用 root，万一普通用户有问题，就进不去了。

密钥登录

密码再复杂，也不如密钥。

原理是非对称加密。你本地有一对密钥，私钥自己留着，公钥放到服务器上。登录的时候，服务器用公钥验证你手里的私钥，验证通过就放行。整个过程私钥不会离开你的机器。

生成密钥：

`1`	`ssh-keygen -t ed25519 -C "mingyue@laptop"`

-t ed25519 是算法。ed25519 比 rsa 更短、更快、更安全。现在的 OpenSSH 都支持。

如果你的客户端特别老，不支持 ed25519，那就用 -t rsa -b 4096。

-C 是注释，一般写邮箱或者用途，方便识别。这个不影响功能。

生成过程中会问你要不要设密码。这个密码是保护私钥文件的，不是登录密码。

设了之后，每次用这个私钥都要输一遍。可以用 ssh-agent 缓存，输一次管一段时间。

我的建议是设一个。私钥文件如果泄露了，有这个密码还能挡一层。

把公钥放到服务器

最方便的是 ssh-copy-id：

`1`	`ssh-copy-id -i ~/.ssh/id_ed25519.pub mingyue@服务器IP`

它会让你输一次密码，然后把公钥追加到服务器的 ~/.ssh/authorized_keys 里。

如果没有这个命令（Windows 的某些环境），可以手动：

`1`	`cat ~/.ssh/id_ed25519.pub`

复制输出的内容，然后登录服务器：

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "粘贴的公钥内容" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

权限必须对。.ssh 是 700，authorized_keys 是 600。权限不对，SSH 会拒绝使用这个文件，而且报错信息很含糊，只说什么 “bad permissions”。

这个坑我踩过，当时找了好久。

测试

新开一个终端，不要关掉当前这个。

`1`	`ssh -i ~/.ssh/id_ed25519 mingyue@服务器IP`

如果不需要输密码就进去了，说明密钥配好了。

如果还要输密码，说明公钥没生效。检查 authorized_keys 的内容和权限，还有 /etc/ssh/sshd_config 里的 PubkeyAuthentication 是不是 yes。

禁用密码登录

确认密钥能用之后，再改配置。

`1`	`sudo nano /etc/ssh/sshd_config`

找到这几行，改成：

1
2
3

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

注意 KbdInteractiveAuthentication 是新版的写法。老版本叫 ChallengeResponseAuthentication，Debian 12 用的是新的。

只改 PasswordAuthentication 不够，因为有些 PAM 配置会让键盘交互式认证绕过这个开关。两个都关掉才彻底。

改完先检查语法：

`1`	`sudo sshd -t`

没有输出就是没问题。

然后重启：

`1`	`sudo systemctl restart ssh`

Debian 12 的服务名是 ssh，不是 sshd。CentOS 上是 sshd。

重启之前一定要保持当前会话开着。 万一配置错了，你还能从这个会话里改回来。

禁用 root 登录

`1`	`PermitRootLogin no`

这个也要小心。如果你还没确认普通用户能 sudo，禁用 root 之后可能就进不去了。

保险的做法是先确认：

1
2

ssh mingyue@服务器IP
sudo whoami

能输出 root 就说明 sudo 是好的。

然后再改 PermitRootLogin。

改端口

22 端口是扫描器的重点目标。改成一个高位端口，能过滤掉绝大部分自动化扫描。

`1`	`Port 2222`

选端口的时候，避开常用的服务端口。2222 是常用的 SSH 替代端口，扫描器也会扫，但频率比 22 低得多。用一些不常见的端口效果更好，比如 50222。

改完还要改防火墙：

1
2
3

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo ufw reload

如果你用的是云服务器，安全组也要改。

本地配置别名

每次都敲端口和用户名太麻烦。本地 ~/.ssh/config：

Host blog
    HostName blog.mibase.top
    User mingyue
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

之后 ssh blog 就行。

ServerAliveInterval 60 是每六十秒发一个心跳包，防止连接因为空闲被断开。ServerAliveCountMax 3 是连续三次没响应就断开。

这两个参数在网络不稳定的环境下很有用，能避免那种"看着连着但已经死了"的情况。

fail2ban

改端口和密钥登录已经能挡掉大部分了，但总有些执着的扫描器会继续尝试。fail2ban 能让它们付出代价。

`1`	`sudo apt install fail2ban`

配置不要改 jail.conf，改 jail.local：

1
2

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

在文件末尾加：

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
backend  = systemd
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s

backend = systemd 是因为 Debian 12 默认没有 /var/log/auth.log，日志都在 journald 里。用 systemd 后端让 fail2ban 通过 journalctl 读。

maxretry = 3 是三次失败就封。bantime = 1h 是封一小时。

启动：

`1`	`sudo systemctl enable --now fail2ban`

看状态：

`1`	`sudo fail2ban-client status sshd`

输出里能看到当前封了多少个 IP，以及被封的列表。

更进一步

上面这些做完，安全性已经不错了。如果还想再收紧，有几件事可以做。

限制登录用户：

`1`	`AllowUsers mingyue`

只有这个用户能登录，别的都被拒绝。

限制登录来源 IP：

1
2

Match Address 1.2.3.4/32
    PermitRootLogin yes

这个可以给特定 IP 开特例。我一般不用，因为我的 IP 是动态的。

关掉 X11 转发：

`1`	`X11Forwarding no`

除非你真的需要图形界面转发，否则关掉能减少攻击面。

限制认证尝试次数：

1
2

MaxAuthTries 3
LoginGraceTime 30

LoginGraceTime 是登录的超时时间，默认是 120 秒。改成 30 秒，减少连接占用的时间。

只监听特定地址：

如果你的机器有多个 IP，可以只在一个上面监听：

`1`	`ListenAddress 1.2.3.4`

改坏了怎么救

这一步最重要。

如果配置改错，SSH 连不上，你还有几条路。

保留的会话。这是最简单的。改之前开着的那个会话，只要没关，就还能用。从这个会话里把配置改回去。

VNC 控制台。云服务器都提供这个功能，在网页上直接连到机器的显示器。用它登录进去修复。

救援模式。大多数云厂商有"救援模式"，会把机器重启到一个临时的系统，你可以挂载原来的磁盘修复配置。

重新装系统。最坏的情况，如果数据有备份，重装也很快。

我的习惯是，改 SSH 之前一定做三件事。备份配置文件，开一个新会话测试，确认云控制台能进。

这三件事花不了几分钟，但能在出事的时候救命。

现在的状态

我这台机器改完之后，每天的失败登录从几千次降到几乎为零。

fail2ban 的日志里，每天封几十个 IP，都是那种扫到 2222 端口然后试几个密码的。

有一次我看了一眼封禁列表，来自俄罗斯、巴西、印度、越南，全世界都有。这就是公网的真实环境。

安全这件事，没有一劳永逸。但把这些基础做好，就已经比绝大多数服务器安全了。大部分攻击都是广撒网，只要你的门槛比别人高一点，它们就换目标了。

机器越来越多之后，我给每一台都挂上了探针

Sun, 02 Aug 2026 23:55:00 +0800

我一直没有正经的监控。

出问题的时候，是我自己发现网站打不开，然后上去看。或者更糟，是朋友告诉我"你博客挂了"。

有几次是证书过期，有一次是数据库满了导致写不进去，还有一次是 nginx 的 worker 全挂了。每一次都是被动发现，中间可能已经挂了好几个小时。

后来在 NodeSeek 上看到有人推荐 Uptime Kuma，说是自托管的监控面板，界面好看，配置简单。我花了一个晚上装起来，之后就没再被"你博客挂了"这种消息尴尬过。

装

Docker Compose，目录 /srv/uptime-kuma：

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    environment:
      TZ: Asia/Shanghai
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

`1`	`docker compose up -d`

端口只绑 127.0.0.1，外面通过 nginx 反代进来。

nginx 反代

Uptime Kuma 用 WebSocket 做实时更新，反代的时候要配 upgrade：

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

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

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

proxy_read_timeout 设长一点。WebSocket 是长连接，如果超时太短，连接会被反复断开重连，页面上的状态会一闪一闪。

进去之后

打开 https://status.mibase.top，会让你创建管理员账号。

建完就进到主界面。左边是监控列表，右边是状态页。

上手先加一个监控。点左上角的"添加新监控"。

监控类型有十几种，HTTP、TCP、Ping、DNS、关键词、推送、证书过期，等等。

HTTP 监控

最常用的是这个。

监控类型：HTTP(s)
友好名称：博客
URL：https://blog.mibase.top
心跳间隔：60 秒
重试次数：2
请求超时：30 秒

心跳间隔 是多久检查一次。六十秒是个平衡点，太频繁会增加负担，太慢会延迟发现。

重试次数 是连续失败多少次才判定为故障。设成 2 意味着单次失败不算，连着两次失败才告警。这个能过滤掉偶尔的网络抖动。

还有一个"接受的状态码"，默认是 200-299。如果你的站会返回 304，得把它加进去。

进阶一点，可以用关键词监控。比如检查页面里有没有某个特定的字符串：

1
2

监控类型：HTTP(s) - 关键词
关键词：明月小站

这样不只是检查服务器返回了 200，还检查内容是对的。有时候 nginx 返回了 200 但页面是空的，这种也能发现。

证书过期监控

这个是我觉得最实用的一个。

1
2

监控类型：HTTP(s) - 关键词
URL：https://blog.mibase.top

其实不用单独配，Uptime Kuma 会自动检测 HTTPS 站点的证书剩余天数，显示在监控详情里。

但它默认不会因为证书快过期而告警。要单独加一个"证书过期"类型的监控：

1
2
3

监控类型：证书过期
域名：blog.mibase.top
过期前通知天数：14

设成十四天，留够续期和排查的时间。

我配了这个之后，再也没遇到过证书过期。

TCP 端口监控

有些服务没有 HTTP 接口，比如数据库、Redis、SSH。

1
2
3

监控类型：TCP 端口
主机名：db.mibase.top
端口：3306

这个只检查端口能不能连上。连不上就告警。

我用它监控了 MariaDB 的 3306 和 SSH 的 2222。

Ping 监控

检查机器本身活不活。

1
2

监控类型：Ping
主机名：blog.mibase.top

这个用的是 ICMP。有些云厂商会禁 ICMP，那就用 TCP 端口替代。

Docker 容器监控

Uptime Kuma 有个 Docker 类型的监控，可以检查容器是否在运行。

但有个前提，Uptime Kuma 这个容器要能访问宿主机的 Docker socket：

1
2
3

    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro

:ro 是只读挂载。这个很重要，因为 docker.sock 相当于宿主机的 root 权限，只读能减少风险。

不过即便如此，能访问 docker.sock 的容器仍然是很危险的。我的做法是只在监控服务器上开这个，业务服务器上不装 Uptime Kuma。

推送监控

这个类型有点特别，方向是反的。

其他监控是 Uptime Kuma 主动去检查目标。推送监控是目标主动向 Uptime Kuma 报告"我还活着"。

新建一个推送监控，它会给你一个 URL：

`1`	`https://status.mibase.top/api/push/xxxxxxxx`

然后你在目标机器上加一个定时任务：

`1`	`curl -fsS -m 10 --retry 5 -o /dev/null https://status.mibase.top/api/push/xxxxxxxx`

如果 Uptime Kuma 在一段时间内没收到这个请求，就判定为故障。

这个特别适合备份任务。比如你的备份脚本每天跑一次，跑完就推一下。如果哪天没推，说明脚本没跑或者跑失败了。

我的备份脚本里就加了这个：

1
2

curl -fsS -m 10 --retry 5 -o /dev/null \
  "https://status.mibase.top/api/push/xxxxxxxx?status=up&msg=OK&ping="

通知

监控没有通知等于没监控。

Uptime Kuma 支持几十种通知方式，Telegram、邮件、Webhook、企业微信、钉钉，等等。

我用的是 Telegram，配置最简单。

先在 Telegram 里找 @BotFather，发 /newbot，按提示建一个 bot，拿到 token。

然后找 @userinfobot，发一条消息，它会告诉你你的 chat id。

在 Uptime Kuma 的设置里，通知，新建：

1
2
3

通知类型：Telegram
Bot Token：123456:ABC-DEF...
Chat ID：123456789

点"测试"，如果 Telegram 里收到消息就说明配好了。

告警的降噪

通知配好之后，最先冒出来的问题是太吵。

网络抖一下，收到一条。服务重启，收到一条。半夜三点被吵醒，一看是误报。

Uptime Kuma 提供了几个手段。

重试次数 是最基础的。连续失败 N 次才告警。

还有一个"心跳间隔"的倍数，叫"重试间隔"。默认是心跳间隔的倍数，可以让重试之间隔得久一点。

另外可以在通知里设"仅在状态变化时通知"。这样故障恢复的时候会发一条，不会一直重复。

我的配置是，心跳间隔六十秒，重试两次，重试间隔六十秒。也就是说，从故障发生到告警，大概需要三分钟。这个延迟可以接受，换来的是极少的误报。

状态页

Uptime Kuma 可以生成一个公开的状态页，给用户看。

在设置里新建状态页，选要显示的监控，设一个路径，比如 /status。

然后访问 https://status.mibase.top/status 就能看到。

这个页面挺好看的，绿色是正常，红色是故障，还能显示最近一次的心跳延迟。

我给自己的几个站做了个公开状态页，虽然没什么人看，但自己看着舒服。

数据备份

Uptime Kuma 的所有配置都存在 SQLite 里，位置是 /app/data/kuma.db。

备份就是拷这个文件：

1
2

docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/backup.db'"
docker cp uptime-kuma:/app/data/backup.db ./kuma-backup-$(date +%F).db

注意要先 .backup 再拷，不能直接拷正在使用的 db 文件。

恢复就是把文件放回去，然后重启容器。

几个小问题

Uptime Kuma 的资源占用不大，一个监控大概占几兆内存。我有二十多个监控，整个容器占了一百多兆。

它的数据库会一直增长，因为每次心跳都记一条。跑久了文件会变大。可以在设置里开启"保留心跳数据的天数"，默认是无限。

有一次我发现监控页面加载很慢，查下来是数据库太大了。开了保留九十天之后，文件从两百多兆降到了三十多兆。

还有一个，如果你的监控目标也在同一台机器上，那机器挂了的时候，监控也跟着挂了，什么都监控不到。

所以我后来把 Uptime Kuma 放在了一台独立的机器上，监控其他所有机器。这样至少能保证监控本身是活的。

现在的状态

我现在的监控列表里有二十多项。

几个站点的 HTTP 可用性，几台 VPS 的 Ping，数据库和 SSH 的端口，几张证书的过期时间，还有备份任务的推送。

每天早上起来看一眼，全是绿的，心里就踏实。

这个工具最大的价值不是它能做什么高级的分析，而是它让我从"被动发现问题"变成了"主动知道状态"。这个转变看起来小，但对心态的影响很大。

把一百多 G 的网站数据搬到新服务器，中间没停过服务

Mon, 29 Sep 2025 02:00:00 +0800

那台老 VPS 跑了三年，配置早就跟不上了。1 核 2G，40G 硬盘，用到了 78%。新买的机器是 2 核 4G，80G 盘，价格还便宜一点。

换机器这件事，我拖了两个月才动手。不是因为难，是因为怕。上面跑着博客、两个小站、一个数据库、一堆容器，任何一个环节出错都是麻烦。

后来定了个策略，把整个过程拆成几段，每一段都可以单独验证，出问题能退回去。这才敢开始。

先盘点

动手之前先把老机器上有什么理清楚。

`1`	`du -sh /srv/* \| sort -h`

12G     /srv/docker
38G     /srv/www
  4G     /srv/backup
  2G     /srv/git

/srv/www 占了三十八个 G，主要是几个站点的图片和历史备份。/srv/docker 是镜像和卷。

再看系统层面：

1
2

crontab -l
systemctl list-unit-files --state=enabled

定时任务有五个，启用的服务有十一个。这些都要在新机器上重建。

`1`	`dpkg --get-selections > /tmp/packages.txt`

把装的软件包列表存下来，新机器上可以照着装。

新机器的准备

先把基础环境搭起来。

1
2
3

apt update && apt upgrade -y
apt install -y rsync nginx mariadb-server docker.io docker-compose-plugin \
  fail2ban ufw git curl htop tmux

然后是用户和权限。老机器上有个 deploy 用户，新机器也要建：

1
2

useradd -m -s /bin/bash deploy
usermod -aG sudo deploy

这一步要提前做，因为 rsync 同步的时候如果目标用户不存在，属主会变成数字，后面还得用 chown 改。

rsync 的参数

全量这一轮，我用的命令是这样：

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' \
  --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

一个个说。

-a 是 archive，等于 -rlptgoD，递归、保留权限、保留时间、保留属主属组、保留设备文件。这一项基本是必加的。

-v 显示进度，-z 压缩传输。压缩对于文本类文件有效，对已经压缩过的图片视频没效果，反而浪费 CPU。我这次因为大部分是图片，-z 其实没帮上什么忙，但也没坏处。

-H 保留硬链接。这个很重要，如果你用 rsnapshot 或者类似工具做备份，硬链接丢了体积会翻好几倍。

-A 保留 ACL，-X 保留扩展属性。如果你的文件有 SELinux 标签或者设置了 ACL，必须加这两个。

--numeric-ids 让 rsync 用数字 ID 而不是用户名来匹配属主。跨机器同步的时候，如果两边的用户名不一样，不加这个会按名字找，找不到就跳过。加了之后，即使 uid 不同也能保留。

--delete 删除目标端多出来的文件。这个参数要小心，它会让目标端和源端完全一致。这一轮我加了，因为新机器上什么都没有。但如果目标端有东西你不想要它删，就得去掉。

--exclude 排除日志和缓存。日志没必要同步，新机器会自己产生。

-e "ssh -p 2222" 是因为我把 SSH 端口改成了 2222。默认的话不用写。

先来一轮全量

第一次同步要把三十多个 G 传过去，按我那台机器的带宽，大概跑了四十分钟。

time rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

跑的时候建议用 tmux 或者 screen 挂着，万一 SSH 断了，rsync 会中断。虽然可以用 --partial 续传，但重跑一次也不费事。

实际上我建议加上 --partial 和 --progress：

1
2

rsync -avzHAX --numeric-ids --delete --partial --progress \
  ...

--partial 保留中断的临时文件，下次同步可以续。--progress 显示每个文件的进度和总进度。

再补一轮增量

全量跑完之后，老机器上的数据还在变，数据库在写，日志在滚。所以要再跑一次增量。

这一轮会快很多，因为 rsync 的算法只传变化的部分。

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' --exclude='.cache' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

这一轮跑了六分钟。

数据库怎么办

直接 rsync 数据库的数据文件是不行的，因为文件在写入的过程中，你复制出来的可能是不一致的。

有两种做法。

一种是在迁移窗口里停掉数据库，然后 rsync 一次。这样最安全，但会有停机。

另一种是用 mariadb-dump 导出，然后在新机器上导入。这个不需要停库，但导入的时间取决于数据量。

我的库不大，不到两个 G，选了导出导入这条。

1
2

mariadb-dump --all-databases --single-transaction --routines --triggers \
  -u root -p > /tmp/all-db.sql

然后在老机器上直接通过 ssh 管道到新机器：

`1`	`cat /tmp/all-db.sql \| ssh -p 2222 deploy@new-host "mariadb -u root -p"`

或者先传文件再导入，看你的网络情况。

--single-transaction 保证导出的是一致性快照。前提是表都是 InnoDB，如果有 MyISAM 就得锁表。

权限和属主

同步完之后，检查一下属主对不对。

`1`	`ssh deploy@new-host "ls -ln /srv/www"`

-n 是显示数字 ID 而不是名字。如果显示的是 1000 1000 而不是 deploy deploy，说明 uid 对不上。

这种情况用 --numeric-ids 之后会发生，因为新机器上的 deploy 用户可能是 1001。

解决办法有两个。一是把新机器上的 deploy 改成和老机器一样的 uid，二是同步完之后统一 chown。

我选了统一 chown，因为改 uid 可能影响其他已经存在的文件。

`1`	`ssh deploy@new-host "sudo chown -R deploy:deploy /srv/www /srv/git"`

nginx 要读的文件，组设成 www-data：

`1`	`ssh deploy@new-host "sudo chgrp -R www-data /srv/www && sudo chmod -R g+rX /srv/www"`

chmod g+rX 里的大写 X 有特殊含义，它只给目录和已经有执行位的文件加执行权限。用小写 x 会给所有文件都加上执行位，那就不对了。

服务配置

把老机器上的配置文件同步过来，然后逐项改。

`1`	`rsync -avz -e "ssh -p 2222" /etc/nginx/ deploy@new-host:/tmp/nginx-config/`

先放到临时目录，人工看一遍再放到 /etc/nginx。直接覆盖有风险，因为两台机器的环境可能不一样。

重点检查这几处。

server_name 里的域名。这个不用改，因为 DNS 还没切。

proxy_pass 里的地址。如果老机器上是 127.0.0.1:8080，新机器上也是，那就没问题。但如果涉及容器名或者别的机器，要核对。

SSL 证书的路径。证书文件也要同步过去。

数据库的连接配置。新机器的密码可能不一样。

切换

前面几步做完，新机器上应该已经能通过 IP 访问了。先用 hosts 文件绑定测试：

1
2

# 本地 /etc/hosts
1.2.3.4  blog.mibase.top

浏览器访问，确认页面正常、样式正常、数据库有数据、图片能加载。

确认没问题之后，进入切换窗口。

先停掉老机器上的写入。把 nginx 停掉，让所有请求失败，这样就不会有新数据产生。

`1`	`ssh old-host "sudo systemctl stop nginx"`

然后最后一次增量同步，这次加上数据库：

rsync -avzHAX --numeric-ids --delete \
  --exclude='*.log' \
  -e "ssh -p 2222" \
  /srv/ deploy@new-host:/srv/

再导出一次数据库，导入新机器。

然后改 DNS。把 A 记录指向新 IP。

DNS 生效需要时间，取决于 TTL。我提前一天把 TTL 从 3600 改成了 300，这样切换的时候五分钟就能生效。

DNS 切换的过程中，有一部分用户还在访问老机器，有一部分到了新机器。这段时间老机器的 nginx 是停的，所以那部分用户会看到错误页。这是不可避免的，只能尽量缩短窗口。

回滚的预案

切换之前，我把老机器的 nginx 配置备份了，也记下了怎么恢复。

如果新机器有问题，回滚就是把 DNS 改回去，然后启动老机器的 nginx。

`1`	`ssh old-host "sudo systemctl start nginx"`

因为老机器的数据只是停止更新了几个小时，没有删除，所以回滚是无损的。

这个预案让我在切换的时候心里有底。知道能退回去，才敢往前走。

切换之后

DNS 生效之后，观察了两天。

`1`	`tail -f /var/log/nginx/access.log`

看有没有异常的状态码。看数据库的连接数。看磁盘的使用情况。

有几个小问题。

一个是时区。新机器默认是 UTC，日志时间对不上。改成 Asia/Shanghai：

`1`	`sudo timedatectl set-timezone Asia/Shanghai`

一个是 Docker 的存储路径。新机器默认在 /var/lib/docker，我改到了 /srv/docker，因为 /srv 那块盘更大。

sudo systemctl stop docker
sudo mkdir -p /srv/docker
sudo rsync -aHAX /var/lib/docker/ /srv/docker/
sudo tee /etc/docker/daemon.json <<'EOF'
{
  "data-root": "/srv/docker"
}
EOF
sudo systemctl start docker

还有一个是防火墙。老机器上用的是 iptables 的直接规则，新机器我换成了 ufw，规则要重写一遍。

老机器的处理

确认新机器稳定之后，老机器不要立刻退。

我保留了两周。这两周里如果发现有什么东西忘了迁，还能上去找。

两周之后，把老机器上的数据打包下载到本地，然后才退掉。

`1`	`ssh old-host "sudo tar -czf - /srv" > old-srv-backup.tar.gz`

这个备份我留了三个月，确认没用了才删。

一点总结

整个迁移从准备到完成，花了大概一周，其中真正的切换窗口只有半小时。

花时间最多的是准备阶段。盘点、装环境、同步数据、验证配置，这些都是一步一步来的，每一步做完都能停下来检查。

我觉得迁移这件事，最重要的不是技术，是心态。不要想着一次搞定，把它拆成能验证的小步骤，每一步都有回滚的方案。

还有一点，永远不要在周五下午做这种事。

同一个 Hugo 站点，Nginx 配好之后快了一倍

Wed, 11 Jun 2025 21:20:00 +0800

我一开始对 Nginx 托管静态站的理解是，把 root 指过去，try_files 写上，就完事了。

确实能跑。但用 Lighthouse 一测，分数不高。用 curl -w 看各阶段耗时，发现时间都花在传输上，服务器处理只占几毫秒。

也就是说，瓶颈不在 Nginx 的逻辑，在它吐数据的方式。

这篇文章记录一下我把这些都调过一遍之后的结果，首屏从一点六秒降到八百毫秒。

先量一下基线

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download} bytes\n" https://blog.mibase.top/

这个命令把各个阶段拆开。TTFB 是首字节时间，Total 是总时间。两者的差就是传输时间。

我改之前，TTFB 是 0.18 秒，Total 是 1.2 秒。传输花了一秒多，说明 html 本身太大。

看一下首页的大小：

`1`	`curl -s -o /dev/null -w "%{size_download}\n" https://blog.mibase.top/`

一百二十 KB。对于纯文本的 html 来说，太大了。Stack 主题的首页会列出十几篇文章，每篇带摘要，加上内联的 css，确实容易膨胀。

先把 gzip 打开

gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    text/javascript
    application/javascript
    application/json
    application/xml
    application/rss+xml
    image/svg+xml;

gzip_comp_level 6 是个折中。1 最快但压缩率低，9 最慢但只多压几个百分点。6 是常用的平衡点，压缩一百二十 KB 的 html 大概花 3 毫秒，压到三十 KB。

gzip_min_length 1024 是小于一 KB 的不压。因为压缩本身有开销，小文件压了反而更大。

gzip_vary on 会在响应里加 Vary: Accept-Encoding，告诉缓存层不同编码的响应要分开存。不加这个，中间有缓存的话可能把 gzip 的内容发给不支持 gzip 的客户端。

gzip_proxied any 是让经过代理的请求也压缩。默认只对没有 Via 头的请求压。用了 Cloudflare 之后，请求都带 Via，不加这个就不压了。

gzip_types 里默认不包含 text/html，因为 Nginx 认为 html 一定要压，它是内置的。但别的类型要显式列出来。

brotli 比 gzip 更好

如果 Nginx 编译的时候带了 brotli 模块，可以再上一层。

Debian 和 Ubuntu 的官方包默认不带，得用第三方源：

1
2

sudo apt install -y libbrotli1
# 用 ondrej 的 nginx 源，或者自己编译

装完之后：

brotli on;
brotli_comp_level 6;
brotli_min_length 1024;
brotli_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml;

brotli 对文本的压缩率比 gzip 高百分之十五到二十。同样一百二十 KB 的 html，gzip 压到三十 KB，brotli 能压到二十五 KB。

但 brotli 压缩更慢，级别 11 的时候能慢十倍。级别 6 是个合理的点。

还有个细节，brotli 需要 https 才能被浏览器支持。http 下浏览器不接受 br 编码。

缓存头怎么设

静态博客的资源分成两类，一类是带指纹的，一类是不带的。

Hugo 处理过的 css、js 带指纹，比如 main.a1b2c3d4.css。这类可以设一年：

location ~* \.(css|js|woff2?|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

图片我用的是 Page Bundle 里的原图，文件名不带指纹。这类设短一点，一周：

location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|ico)$ {
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
    access_log off;
}

html 最短：

location ~* \.html$ {
    expires 10m;
    add_header Cache-Control "public, max-age=600, must-revalidate";
}

must-revalidate 让浏览器在缓存过期后必须回源确认，不能拿旧的凑合。

access_log off 是给静态资源的。这些请求量最大，写日志的开销不小，而且它们的日志没什么分析价值。

http2 和 http3

http2 已经是很成熟的东西了，Nginx 从 1.9.5 开始支持。

server {
    listen 443 ssl;
    http2 on;
    ...
}

注意 Nginx 1.25.1 之后语法变了。以前是 listen 443 ssl http2;，现在是单独一行 http2 on;。用老语法会报一个 deprecation 警告。

http2 的好处是多路复用。同一个连接上可以并发多个请求，不用像 http1.1 那样开六个连接。对于首页要加载几十个资源的场景，提升很明显。

http3 基于 QUIC，Nginx 从 1.25 开始有实验性支持，需要单独编译。我试过一次，配置有点麻烦，而且国内很多网络对 UDP 443 不友好。暂时没用。

try_files 的写法

1
2
3

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

这个写法支持无扩展名的 URL。比如 /p/hello-world/ 会先找目录，找不到再找 /p/hello-world.html。

Hugo 的默认输出是目录加 index.html，所以 $uri/ 那一步就能命中。但如果你改过 uglyURLs，就得靠 $uri.html。

=404 是最后兜底，找不到就返回 404。如果不写这个，Nginx 会返回一个内部的 404 页面，有时候行为不一致。

还有一个优化，把 index 指令写明确：

`1`	`index index.html;`

默认就是 index.html，但写出来能省一次查找。

文件描述符

这个在另一篇里详细说过，这里提一句。静态站请求量大，每个请求都要打开文件，fd 不够会报 Too many open files。

worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
}

worker_rlimit_nofile 是 nginx 自己能打开的文件数上限，要配合 systemd 的 LimitNOFILE 一起调。

sendfile 和 tcp 参数

1
2
3

sendfile on;
tcp_nopush on;
tcp_nodelay on;

sendfile 让 Nginx 用内核的零拷贝直接把文件送到 socket，不用先读到用户态再写出去。静态文件服务必开。

tcp_nopush 是等数据攒够一个包再发，减少小包数量。它和 sendfile 配合使用效果最好。

tcp_nodelay 是不等待，立刻发。它和 tcp_nopush 看起来矛盾，实际上 Nginx 会根据情况自动选择。对于 keepalive 的连接用 nopush，对于要立刻响应的用 nodelay。

keepalive 的调整

1
2

keepalive_timeout 30s;
keepalive_requests 1000;

默认 keepalive_timeout 是 75 秒，太长了，会占着连接不放。30 秒对静态站够用。

keepalive_requests 是单个连接最多处理多少请求。默认 1000，对于首页要加载几十个资源的场景，一次连接就够了。

一个容易忽略的点：open_file_cache

这个功能会缓存打开的文件句柄，减少 open() 系统调用。

open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

max=10000 是最多缓存一万个文件描述符。inactive=30s 是三十秒没被访问就释放。

open_file_cache_min_uses 2 是至少被访问两次才缓存。只访问一次的文件，缓存了也是浪费。

这个对静态站的效果挺明显，尤其是文章页多的时候。我用 strace 看过，开了之后 openat 调用少了很多。

不过要小心，如果你的文件经常变（比如部署的时候覆盖），缓存可能导致短时间读到旧文件。open_file_cache_valid 60s 是六十秒校验一次，影响不大。

部署时的原子替换

Hugo 构建的时候会先写到一个临时目录，然后整体替换 public。但如果在替换的过程中有请求进来，可能读到一半新一半旧的内容。

我的做法是构建到新目录，然后用符号链接切换：

1
2

hugo --minify --gc -d /srv/www/blog/releases/$(date +%s)
ln -sfn /srv/www/blog/releases/$(date +%s) /srv/www/blog/current

Nginx 的 root 指向 /srv/www/blog/current。

符号链接的切换是原子的，Nginx 打开文件的时候会跟随链接，所以不会有中间状态。

这个做法还有个好处，回滚就是把链接指回上一个目录，一秒搞定。

改完之后的效果

`1`	`curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download}\n" https://blog.mibase.top/`

TTFB 0.09 秒，Total 0.28 秒，Size 28 KB。

从一点二秒到零点二八秒。Lighthouse 移动端从 62 分到 96 分。

哪些改动最有用

如果只能做三件事，我会选这三件。

开 gzip，或者 brotli。这个改动最小，收益最大，html 从一百二十 KB 降到三十 KB。

给静态资源设长缓存。第二次访问的时候，浏览器直接用本地的，一个请求都不发。

用 http2。首页要加载几十个资源，多路复用省掉的连接开销很可观。

剩下的 sendfile、open_file_cache 这些，是锦上添花。做不做差别不大，但既然配置一次就能长期生效，顺手做了也没什么坏处。

最后

静态博客的性能优化，本质上是在做两件事。让传输的数据更少，让重复的请求更少。

Nginx 提供了足够多的手段，但大部分默认值不是为静态站调的。花一个小时把这些配置过一遍，之后每一次访问都会受益。

带宽一夜之间跑了 40G，原来是有人在爬我的站

Sun, 27 Apr 2025 03:28:00 +0800

四月的某天，云厂商发来一条流量预警，说我这个月的出网流量已经用了 80%。

我看了一眼统计，那天从凌晨到早上八点，跑了四十多个 G。平时一整天也就两三个 G。

第一反应是被人盗链了。查了一下 nginx 的 access log，确实有几个 IP 在疯狂请求图片。

但仔细一看，不对。它们请求的不只是图片，还有每一篇文章的 html，每个都带着不同的 UA，请求间隔很均匀，大概两百毫秒一次。这不是盗链，是有人在整站爬。

先看清楚规模

`1`	`awk '{print $1}' /var/log/nginx/access.log \| sort \| uniq -c \| sort -rn \| head -20`

前五名每个都有一万多次请求。再看它们的 UA：

`1`	`grep '1.2.3.4' /var/log/nginx/access.log \| awk -F'"' '{print $6}' \| sort \| uniq -c`

全是同一个 UA，一个很老的 Chrome 标识，而且请求头里没有 Accept-Language，没有 Referer。正常浏览器不会这样。

这就是典型的爬虫，可能是某个做镜像站的在收集内容，也可能是训练数据。

能做的事有几种

最直接的是封 IP。但爬虫往往有一批 IP，封一个换一个。

另一个办法是在 Cloudflare 那边开 Bot Fight Mode。免费版有这个功能，能挡掉一部分低级爬虫。但它有时候会误伤正常的搜索引擎，而且对模拟得很像的爬虫没效果。

再一个就是在 nginx 层面做限流。这个是治本的，不管对方换多少 IP，只要单个 IP 的请求频率超过阈值，就限速或者拒绝。

我选了限流，Bot Fight Mode 也顺手开着，两个一起用。

limit_req_zone 是怎么回事

nginx 的限流模块叫 ngx_http_limit_req_module，核心是漏桶算法。

先说漏桶是什么意思。

想象一个桶，桶底有个洞，水以固定的速度往外漏。你往桶里倒水，如果倒得比漏得快，水就会积起来。桶满了之后，再倒就溢出去了。

对应到 nginx，请求就是水，桶的容量是 burst，漏水速度是 rate。请求速率超过 rate 之后，会先在桶里排队，桶满了就拒绝，返回 503 或者你指定的状态码。

这个算法有个特点，它允许短时间的突发。比如你设了 rate=10r/s，burst=20，那么一个瞬间来 25 个请求，前 10 个立刻处理，后面 15 个排队，第 26 个开始拒绝。

这个特性对正常用户很友好，因为人浏览网页本来就是一阵一阵的。

配置

先在 http 块里定义 zone：

`1`	`limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;`

$binary_remote_addr 是客户端 IP 的二进制形式，比 $remote_addr 省空间。zone=perip:10m 是给这个 zone 起个名字，分配 10M 内存。

10M 大概能存十六万个 IP 的状态。对于个人站绰绰有余。

rate=5r/s 是每秒五个请求。这个值要看你的站。我的站页面不多，一个正常用户浏览的时候，一秒最多也就两三个请求（html 加 css 加 js 加几张图）。设成 5 是个合理的上限。

注意 rate 的单位。写 5r/s 是每秒五个，写 5r/m 是每分钟五个。这两个差别很大，别写错。

然后在 server 或者 location 里用：

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

    location / {
        limit_req zone=perip burst=10 nodelay;
        limit_req_status 429;

        try_files $uri $uri/ =404;
    }
}

burst=10 是桶的容量，允许十个请求排队。

nodelay 这个参数很关键。不加它，排队的请求会按 rate 慢慢放行，用户会感觉页面加载被拖慢了。加了之后，桶里的请求立刻处理，只是超过桶容量的才拒绝。

limit_req_status 429 是自定义拒绝时的状态码。默认是 503，但 503 表示服务不可用，429 表示请求过多，语义上 429 更准确。有些爬虫看到 503 会重试，看到 429 会退避。

limit_conn_zone 管并发

limit_req 管的是速率，limit_conn 管的是同时打开的连接数。

这两个要一起用。因为有的爬虫很聪明，它把请求间隔拉长到刚好不被限速，但同时开几十个连接。

limit_conn_zone $binary_remote_addr zone=conn_perip:10m;

server {
    limit_conn conn_perip 20;
    limit_conn_status 429;
}

单个 IP 最多二十个并发连接。正常浏览器对一个站同时开六个连接就够了（HTTP/1.1 的限制），HTTP/2 会多一点，但也不会到二十。

白名单

搜索引擎的爬虫不能限。

geo $limit {
    default 1;
    66.249.64.0/19 0;
    40.77.167.0/24 0;
    157.55.39.0/24 0;
    207.46.13.0/24 0;
    127.0.0.1/32 0;
}

map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=perip:10m rate=5r/s;

geo 模块按 IP 段匹配，匹配到的设成 0。map 把 0 转成空字符串，空字符串在 limit_req_zone 里表示不参与限流。

这个写法比在 location 里写一堆 if 要干净得多，而且性能更好，因为 geo 和 map 都是编译成哈希表查找。

白名单的 IP 段要定期核对。Google 和 Bing 都公布了官方列表，而且会变。我一般是每个月看一次。

给不同路径设不同阈值

静态资源可以放宽，因为一个页面会带很多张图。动态接口要收紧。

limit_req_zone $limit_key zone=static:10m rate=30r/s;
limit_req_zone $limit_key zone=dynamic:10m rate=3r/s;

location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
    limit_req zone=static burst=50 nodelay;
    expires 1y;
}

location /api/ {
    limit_req zone=dynamic burst=5 nodelay;
    limit_req_status 429;
}

这样正常浏览页面不会因为图片多被误伤，而接口那边被刷的时候能立刻挡住。

观察限流的效果

nginx 的日志里默认不记录限流信息。想统计，得在 log_format 里加变量。

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" '
                'req_limit=$limit_req_status conn_limit=$limit_conn_status';

然后统计：

`1`	`awk '$NF ~ /req_limit=REJECTED/ {print $1}' /var/log/nginx/access.log \| sort \| uniq -c \| sort -rn \| head`

能看到哪些 IP 被拒得最多。

配完当天，日志里被拒的请求有两万多次，来自三十多个 IP。流量从四十 G 降到了正常水平。

几个容易踩的坑

limit_req_zone 只能写在 http 块里，写在 server 里会报错。这个我一开始搞错了，nginx -t 直接不通过。

burst 设太大等于没限流。因为桶的容量就是允许的突发量，设成一千，对方一次来一千个请求也能过。我的经验是，正常页面需要的资源数加一点余量，二三十就够了。

nodelay 不加的话，虽然请求不会被拒，但会被延迟处理，用户会觉得网站变慢。这个体验比直接返回 429 更糟。

用了 Cloudflare 的话，一定要先配 real_ip，否则 $binary_remote_addr 拿到的是 Cloudflare 的节点 IP，限流会误伤所有用户。这个坑我在 fail2ban 那篇里也提过，是同一个问题。

还有，limit_req 是有状态的，它的计数器存在共享内存里。如果你有多台 nginx 做负载均衡，每台的计数是独立的，实际允许的速率是单台的倍数。这种情况得在更上层做限流，或者用 Redis 存共享计数。

最后的手段

限流只能减缓，挡不住真正执着的爬虫。

我在限流之后又加了一层，针对那些明显是爬虫的请求，直接返回 403：

map $http_user_agent $bad_bot {
    default 0;
    ""      1;
    "~*python-requests" 1;
    "~*scrapy"          1;
    "~*curl/7"          1;
    "~*Go-http-client"  1;
}

server {
    if ($bad_bot) {
        return 403;
    }
}

这个写法比较粗暴，会误伤一些用 curl 的正常用户。但我的站是给人看的，不是给脚本用的，我觉得可以接受。

if 在 nginx 里是不推荐用的，因为它在 location 里的行为有陷阱。但放在 server 级别做这种简单的判断，是官方文档里明确说可以用的场景。

现在的状态

这套配置跑了几个月，流量稳定在每天两个 G 左右，没有再出现异常。

偶尔还是会有爬虫来，但它们被限速之后，爬完整个站要很久，大多数爬到一半就放弃了。

回头看，这件事的本质是，我的站没有任何成本地暴露在公网上，谁都能来拿。限流是在给它加一个成本，让无差别抓取变得不划算。

这个思路可以用在很多地方。API 也好，下载站也好，只要能定义"正常使用的频率"，就能用同样的方法保护自己。

1G 内存的小机器跑 MariaDB，我把能省的都省了

Thu, 03 Apr 2025 04:28:00 +0800

手里有台很便宜的 VPS，1 核 1G，一年一百多块。上面跑着一个小论坛，用户不多，但数据库不能少。

装完 MariaDB 之后，我 free -h 看了一眼，可用内存只剩三百多兆。系统自己占了点，MariaDB 占了将近五百兆。

当时没太在意，觉得还能跑。结果第三天凌晨，机器挂了。

先看是怎么死的

`1`	`journalctl -k --since "yesterday" \| grep -i 'out of memory'`

`1`	`Out of memory: Killed process 812 (mariadbd) total-vm:1024000kB, anon-rss:520000kB`

OOM killer 干的。MariaDB 吃到 520M，加上系统的，超过物理内存，内核直接把它杀了。

有意思的是，杀完之后 systemd 又把它拉起来，然后继续涨，第二天再杀一次。这就是为什么我早上起来发现论坛打不开，但服务状态显示 running。

内存都花在哪儿了

MariaDB 的内存占用分几块，得先搞清楚再动手。

`1`	`SHOW ENGINE INNODB STATUS\G`

输出里的 BUFFER POOL AND MEMORY 那一段，能看到 buffer pool 的实际大小。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'innodb_log_buffer_size';
SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
SHOW VARIABLES LIKE 'sort_buffer_size';
SHOW VARIABLES LIKE 'join_buffer_size';
SHOW VARIABLES LIKE 'read_buffer_size';
SHOW VARIABLES LIKE 'read_rnd_buffer_size';

我查出来的默认值是这样的：

innodb_buffer_pool_size    134217728    (128M)
innodb_log_buffer_size     16777216     (16M)
max_connections            151
tmp_table_size             16777216     (16M)
max_heap_table_size        16777216     (16M)
sort_buffer_size           2097152      (2M)
join_buffer_size           262144       (256K)
read_buffer_size           131072       (128K)
read_rnd_buffer_size       262144       (256K)

看着每一项都不大，但问题是，sort_buffer_size、join_buffer_size 这些是每个连接独占的。151 个连接乘上 2M 的 sort buffer，理论上就是 300M。虽然实际不会所有连接都用到满，但这个乘数关系很吓人。

改配置

MariaDB 的配置我放在 /etc/mysql/mariadb.conf.d/99-small.cnf，这样不会被升级覆盖。

[mysqld]
# 内存相关的核心参数
innodb_buffer_pool_size = 64M
innodb_log_buffer_size = 8M
innodb_buffer_pool_instances = 1

# 连接数
max_connections = 30
max_user_connections = 25
thread_cache_size = 4
table_open_cache = 64
table_definition_cache = 256

# 每个连接的缓冲区，越小越好
sort_buffer_size = 256K
join_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 256K
tmp_table_size = 16M
max_heap_table_size = 16M

# 日志和刷盘
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 32M

# 关掉用不到的功能
performance_schema = OFF
innodb_stats_on_metadata = OFF

一条条说。

innodb_buffer_pool_size 是最大的一块。它是 InnoDB 的缓存池，索引和数据页都放里面。默认 128M 对 1G 的机器太大了，我改成 64M。这个值的经验法则是物理内存的百分之五十到七十，但在小内存机器上，得先保证系统和其他服务能活。

innodb_buffer_pool_instances 默认会按 buffer pool 大小自动分，分成多个实例能减少锁竞争。但在 64M 这个量级，分成多个反而浪费，因为每个实例有自己的最小页数。设成 1 就行。

max_connections 从 151 降到 30。这个小论坛日常在线不到十个人，三十个连接足够。这个改动省下的不是连接本身，而是每个连接的缓冲区乘数。

thread_cache_size 是缓存的线程数。连接断开之后线程不立刻销毁，留着给下一个连接用。设成 4 意味着常驻四个空闲线程，占的内存不多，但能减少频繁创建销毁的开销。

performance_schema 这个功能是用来做性能分析的，很强大，但默认开着会占不少内存，大概几十兆。小站用不上，关掉。

innodb_flush_log_at_trx_commit = 2 这个要谨慎。它控制事务提交时怎么刷日志。

设成 1 是最安全的，每次提交都刷盘，保证不丢数据。设成 2 是每秒刷一次，性能好很多，但极端情况下可能丢一秒的数据。设成 0 是交给操作系统，最不安全。

小论坛丢一秒的数据可以接受，我选了 2。如果你的业务涉及钱，别改这个。

innodb_flush_method = O_DIRECT 让 InnoDB 绕过操作系统的页缓存，直接写磁盘。这样同一份数据不会在内存里存两遍。小内存机器上这个能省下可观的空间。

重启之后看效果

1
2

sudo systemctl restart mariadb
free -h

改完 MariaDB 占了 180M 左右，比之前的 520M 小了一大截。

再看一下实际的 buffer pool：

1
2
3

SELECT
  POOL_SIZE * 16 / 1024 / 1024 AS buffer_pool_mb
FROM information_schema.INNODB_BUFFER_POOL_STATS;

确认是 64M。

一个更细的观察方法

free -h 只能看到整体，想看每个进程实际用了多少：

`1`	`ps -eo pid,comm,rss,vsz --sort=-rss \| head -10`

rss 是实际占用的物理内存，vsz 是虚拟内存。看 rss 才有意义，vsz 包含了大量没有真正分配的地址空间。

还可以看 MariaDB 自己的内存统计：

1
2

SHOW STATUS LIKE 'Innodb_buffer_pool_bytes_data';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';

pages_free 如果一直是 0，说明 buffer pool 不够用，可以适当调大。如果有一半以上是空闲的，说明给多了。

我观察了一周，pages_free 稳定在 40% 左右，说明 64M 是合适的。

swap 要不要开

这个问题争论很多。

我的看法是，小内存机器一定要开一点。不是因为 swap 能提升性能，而是因为它能在内存尖峰的时候给你一个缓冲，避免进程被直接杀掉。

我配了 1G 的 swap：

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

然后调一下 swap 的使用倾向：

`1`	`sudo sysctl vm.swappiness=10`

默认是 60，意思是内存还有富余的时候就开始往 swap 里挪。设成 10 让它尽量先用物理内存，真的不够了才用 swap。

这个值我写在 /etc/sysctl.d/99-swap.conf 里，重启也生效。

不过要提醒一句，如果你的 VPS 用的是机械盘或者网络存储，swap 的性能会很差，用到 swap 的时候整个系统会卡住。这种情况得权衡。

慢查询日志

内存调小了，可能会有些查询变慢，因为 buffer pool 小了，缓存命中率下降。

开个慢查询日志观察：

1
2
3

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

跑一周，看看有没有超过两秒的查询。有的话，先优化 SQL，加索引，比加内存便宜。

我那台机器上确实发现了两条，一条是论坛的帖子列表，没走索引，全表扫描。加了复合索引之后，从三秒降到几十毫秒。

这个收益比调参数大得多。

还有一个坑：临时表

tmp_table_size 和 max_heap_table_size 这两个值要设成一样。

原因是有个隐藏的行为。内存临时表的大小受这两个值里较小的那个限制。如果不一样，实际生效的是小的那个，你改大的那个没用。

我一开始只改了 tmp_table_size，改成 64M，结果发现没效果，因为 max_heap_table_size 还是 16M。

另外，临时表超过这个大小之后，会转成磁盘临时表。磁盘临时表慢很多，但至少不会把内存撑爆。所以这两个值别设太大，16M 到 32M 就够了。

长期观察

调完到现在跑了三个多月，没再被 OOM 杀过。

free -h

现在的样子：

1
2
3

               total        used        free      shared  buff/cache   available
Mem:           979Mi       412Mi       102Mi       8.0Mi       464Mi       512Mi
Swap:          1.0Gi        12Mi       1.0Gi

MariaDB 稳定在 180M 左右，swap 只用了 12M，基本没动。

available 有 512M，说明还有余量。这个指标比 free 更有参考价值，因为它把可回收的缓存也算进去了。

一点心得

小内存机器上跑数据库，核心思路是"知道自己需要多少，然后只给这么多"。

默认配置是为通用场景设计的，它假设你有足够的内存。在 1G 的机器上，这些默认值就是灾难。

调参的顺序应该是，先降 max_connections，因为它带来的乘数效应最大；再降 innodb_buffer_pool_size，这是单项最大的一块；最后调各种 per-connection 的缓冲区。

调完之后别急着走，观察几天，看 buffer pool 的命中率和 free 页面数，再微调。

还有一点，如果你的库真的很小，比如就几兆数据，那其实可以考虑 SQLite。省掉整个数据库进程，内存占用直接降到几兆。我这个论坛是因为要用全文检索和并发写，才留着 MariaDB。

数据库备份这件事，我从手动导出做到全自动

Thu, 20 Mar 2025 03:45:00 +0800

我一直觉得备份是件很枯燥的事。

直到有一次，我在服务器上执行了一条 DELETE FROM comments WHERE id > 100，本来想删测试数据，结果忘了自己不在测试库。

那条语句跑完，生产库少了两千多条评论。

我坐在那儿愣了大概十秒钟，然后想起来，昨天晚上的备份还在。

从那次之后，我对备份的态度完全变了。

备份到底要解决什么问题

先说清楚，备份不是"把数据复制一份"这么简单。

它要能应对几种不同的场景。

误删数据，需要恢复到删除前的某个时间点。

磁盘损坏，需要换台机器把服务重新拉起来。

程序 bug 写坏了数据，需要回滚到某个版本。

被勒索软件加密，需要有离线副本。

这几种场景对备份的要求不一样。误删需要时间点密集，磁盘损坏需要副本在别的机器上，勒索需要副本不可写。

所以一个靠谱的方案，至少要有三个特征。定期自动跑，副本存在别的地方，而且真的能恢复。

最后一条最容易被忽略。很多人备份跑了半年，真要恢复的时候才发现文件是空的。

最基础的 mysqldump

小站用这个就够了。

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  -u root -p \
  myapp > /backup/myapp-$(date +%F).sql

几个参数都值得说一下。

--single-transaction 是关键。它在 InnoDB 上开一个一致性快照，导出过程中不会锁表，业务可以继续写。导出来的数据是开始那一刻的状态，不会出现前后不一致。

注意这个参数只对 InnoDB 有效。如果你的表还有 MyISAM，那就得用 --lock-tables，会锁表，业务会卡。

--quick 让 mysqldump 一行一行往客户端发，而不是全部读进内存。大表不加这个，很容易把内存撑爆。

--routines --triggers --events 这三个，默认是不导出的。不加上，恢复之后存储过程、触发器、定时任务全都没了。我第一次恢复的时候就踩了这个坑，恢复完发现定时清理任务不跑了。

--default-character-set=utf8mb4 防止中文乱码。如果源库是 utf8mb4，导出的时候不指定，有时候会被转成 latin1。

加压缩和加密

纯 sql 文件很大，压缩一下能小到十分之一：

`1`	`mysqldump ... \| gzip > /backup/myapp-$(date +%F).sql.gz`

如果数据里有敏感信息，还得加密：

`1`	`mysqldump ... \| gzip \| openssl enc -aes-256-cbc -pbkdf2 -salt -pass file:/etc/backup.key > /backup/myapp-$(date +%F).sql.gz.enc`

-pbkdf2 是让 openssl 用更安全的密钥派生方式，不加的话会有警告。

-pass file: 从文件读密码，比写在命令行里安全，因为命令行参数在 ps 里能看到。

/etc/backup.key 权限设成 600，只有 root 能读。

恢复的时候：

`1`	`openssl enc -d -aes-256-cbc -pbkdf2 -pass file:/etc/backup.key -in backup.sql.gz.enc \| gunzip \| mysql -u root -p myapp`

写成脚本

手动跑总会忘，得自动化。

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/backup/mysql
KEEP_DAYS=14
DATE=$(date +%F_%H%M)
DB=myapp

mkdir -p "$BACKUP_DIR"

mysqldump \
  --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 \
  -u root -p"$(cat /etc/mysql/backup.pass)" \
  "$DB" | gzip > "$BACKUP_DIR/${DB}-${DATE}.sql.gz"

# 校验文件不是空的
SIZE=$(stat -c %s "$BACKUP_DIR/${DB}-${DATE}.sql.gz")
if [ "$SIZE" -lt 1024 ]; then
  echo "备份文件异常小：$SIZE 字节" >&2
  exit 1
fi

# 清理过期
find "$BACKUP_DIR" -name "${DB}-*.sql.gz" -mtime +$KEEP_DAYS -delete

echo "备份完成：${DB}-${DATE}.sql.gz ($SIZE 字节)"

set -euo pipefail 这三件套一定要加。-e 让任何命令失败就退出，-u 让未定义变量报错，-o pipefail 让管道里任何一个环节失败都能被捕获。

没有 pipefail 的时候，mysqldump | gzip 如果 mysqldump 失败了，整个管道还是返回成功，因为 gzip 成功了。这是很隐蔽的坑，我吃过一次，备份文件是空的，脚本还报成功。

那个 SIZE 校验也是必须的。空文件、截断的文件，靠退出码是发现不了的。

用 cron 跑

sudo tee /etc/cron.d/mysql-backup <<'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 3 * * * root /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1
EOF

每天凌晨三点半跑。这个时间业务量最低。

cron.d 的格式比 crontab -e 多一个用户字段，就是 root 那个位置。写错了会不执行，而且没有任何提示。

增量备份

全量备份对数据量小的站够用，但如果库有几个 G，每天全量就不太现实了。

增量有两种做法。

一种是 binlog。MySQL 的 binlog 记录了所有数据变更，配上定期全量，可以把数据恢复到任意时间点。

先确认 binlog 开着：

`1`	`SHOW VARIABLES LIKE 'log_bin';`

如果是 ON，那 binlog 文件在 datadir 下面，名字形如 mysql-bin.000001。

备份 binlog：

1
2

mysqlbinlog --read-from-remote-server --host=127.0.0.1 --user=repl --password=xxx \
  --raw --stop-never mysql-bin.000001

这个会持续拉取新的 binlog。实际用的时候一般配合 --result-file 和定期切换。

另一种是 --incremental 配合 xtrabackup。Percona 的工具，支持热备和增量，适合大库。不过它需要单独装，配置也复杂一些。

我这个小站没到那个量级，用的还是每天全量。库里不到一百兆，压缩完十几兆，存三十天也就四百多兆。

存到别的地方

本地备份只能防误删，防不了磁盘坏或者机器没了。

所以至少要有两份，一份在本机，一份在别处。

我用的是 rclone 同步到对象存储：

`1`	`rclone sync /backup/mysql remote:mybackup/mysql --max-age 24h`

--max-age 24h 只同步一天内的新文件，不用每次全传。

对象存储那边开了版本控制，就算本地文件被勒索软件加密了，云上的历史版本还在。

还有一个细节，云上的凭据要单独放，不要和备份放在同一台机器上。不然机器被攻破，凭据一起泄露，备份也保不住。

真正的考验是恢复

这一步我建议每个人都做一次。

找个测试环境，把备份文件恢复进去，看看数据对不对。

`1`	`gunzip -c myapp-2025-03-19.sql.gz \| mysql -u root -p testdb`

然后：

1
2

SELECT COUNT(*) FROM comments;
SELECT MAX(created_at) FROM comments;

数字对得上，时间对得上，才算备份有效。

我第一次做这个演练的时候，发现恢复出来的库少了三张表。原因是那三张表是 MyISAM，--single-transaction 对它们无效，mysqldump 直接跳过了。后来改成全部 InnoDB 才好。

这种问题，只有真的恢复一次才能发现。

恢复的流程也要写下来

出事的时候人是慌的，容易漏步骤。

我把恢复流程写成了一个文档，放在 /srv/docs/restore.md，内容包括：

先停掉应用，防止有新的写入。

备份当前的数据库（哪怕是坏的，先留一份）。

创建新的库，导入备份。

检查表数量、行数、最新的记录时间。

确认无误之后，改应用的连接配置，启动。

最后记录这次事故的时间线和原因。

有这个文档，真出事的时候照着做就行，不用临场想。

现在的情况

这套东西跑了快一年，中间用上了两次。一次是我自己误删，一次是磁盘满了导致写入失败。

两次都在半小时内恢复，业务中断时间不到一小时。

备份这件事，平时感觉不到它的价值。它唯一的价值就在出事的那一刻，而那一刻你没有任何补救的机会，只能靠之前准备好的东西。

所以我现在对它的态度是，不追求多先进，但一定要简单、可靠、验证过。

凌晨两点收到 502 告警，最后查出来是文件描述符不够用

Sun, 23 Feb 2025 17:56:00 +0800

手机在枕头边上震了两下。我摸起来看了一眼，是监控发的，blog.mibase.top 返回 502。

当时是凌晨两点十分。我第一反应是想装死，第二天早上再说。但那台机器上还挂着别的东西，万一是一起挂了，拖到早上就麻烦。

爬起来开电脑，连上去看。

现象

`1`	`systemctl status nginx`

状态是 active (running)，但错误日志里一直在刷：

1
2

2025/02/23 02:08:41 [alert] 8123#8123: *55123 open() "/var/log/nginx/access.log" failed (24: Too many open files)
2025/02/23 02:08:41 [crit] 8123#8123: *55124 open() "/srv/www/blog/public/index.html" failed (24: Too many open files)

Too many open files，这个报错我见过，但一直以为离自己很远。

什么是文件描述符

Linux 里一切皆文件。不只是磁盘上的文件，网络连接、管道、设备、socket，在内核眼里都是一个文件，用一个整数来标识，叫文件描述符，简称 fd。

每个进程能同时打开多少个 fd，是有上限的。这个上限来自三个地方，一层压一层。

最外面那层是内核的全局上限，/proc/sys/fs/file-max，一般很大，几十万，通常不会撞到。

往里一层是用户级限制，ulimit -n，这个是每个登录会话的限制。

最里面是进程自己的限制，从父进程继承，可以用 prlimit 查看。

nginx 作为服务跑，它继承的是 systemd 给它的限制，而不是我 SSH 登录之后的 ulimit。这一点很关键，后面会说。

先看当前值

# 当前会话
ulimit -n

# nginx 主进程的实际限制
sudo cat /proc/$(pgrep -o nginx)/limits | grep 'open files'

# 系统全局
cat /proc/sys/fs/file-max

# 系统当前用了多少
cat /proc/sys/fs/file-nr

我那次查出来，nginx 的限制是 1024。

1024 这个数字是老系统的默认值，现在看着确实小。nginx 每个连接要占两个 fd，一个给客户端，一个给上游。1024 意味着理论上最多五百个并发连接，实际还要留一些给日志文件、监听 socket，能用的更少。

我那个站平时并发不高，但那天晚上有人在爬，连接数上去了，直接撞到天花板。

改系统级限制

/etc/security/limits.conf 是老办法：

1
2

*    soft nofile 65535
*    hard nofile 65535

这个文件只对通过 PAM 登录的会话生效，也就是 SSH 登录、su 这些。对 systemd 服务不一定管用，因为 systemd 启动服务的时候不走 PAM 的 limits 那一套。

所以还得改 systemd 的配置。

/etc/systemd/system.conf 或者针对单个服务写 override：

sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo tee /etc/systemd/system/nginx.service.d/limits.conf <<'EOF'
[Service]
LimitNOFILE=65535
EOF

然后：

1
2

sudo systemctl daemon-reload
sudo systemctl restart nginx

验证：

`1`	`sudo cat /proc/$(pgrep -o nginx)/limits \| grep 'open files'`

应该显示 65535。

还有一层：systemd 自己的默认值

Debian 12 和 Ubuntu 22.04 之后，systemd 有个 DefaultLimitNOFILE 的默认值，是 1024:524288。意思是软限制 1024，硬限制 524288。

也就是说，如果你不显式设置，服务拿到的软限制还是 1024，硬限制虽然是 524288，但进程不会自己去把它调高。

这就是为什么很多人改了 limits.conf 之后发现没效果。服务是通过 systemd 起的，不走 PAM。

/etc/systemd/system.conf 里可以全局改：

1
2

[Manager]
DefaultLimitNOFILE=65535

改完 daemon-reload，然后重启所有服务才生效。我一般不改全局，只给需要的服务单独写 override，影响面小一点。

nginx 自己的配置也要改

系统限制放开了，nginx 的配置里还有一个上限。

1
2
3

events {
    worker_connections 1024;
}

这个值决定了单个 worker 能同时处理多少个连接。

worker 的数量是 worker_processes，一般设成 CPU 核数或者 auto。总的并发能力大致是 worker_processes × worker_connections。

我把这两个都调了：

worker_processes auto;

events {
    worker_connections 8192;
    multi_accept on;
    use epoll;
}

multi_accept on 让一个 worker 一次接受多个新连接，高并发下能减少系统调用。

use epoll 在 Linux 上是默认值，写出来只是为了明确。BSD 系才需要 kqueue。

注意，worker_connections 不能超过 LimitNOFILE。如果系统限制是 1024，你写 8192 也没用，nginx 启动的时候会警告，实际还是被卡在 1024。

一个容易忽略的点：日志文件

nginx 每个 worker 都要打开 access.log 和 error.log。如果开了很多虚拟主机，每个都有自己的日志文件，这个数字会累积。

我那次有七个站点，每个两套日志，加上主配置的，一共十五个文件。乘以 worker 数，就是几十个 fd。虽然不多，但在接近上限的时候，这就是压死骆驼的最后一根稻草。

解决办法是减少日志文件数量，或者用 access_log off 关掉不需要的。我把几个不重要的站的 access log 关了，只留 error log。

排查当时到底谁在占

改配置之前，我想先确认一下是不是真的连接数暴涨。

ss -s

输出里有个 TCP: 1234 (estab 890, closed 210, orphaned 0, timewait 130)。890 个 established，对于那个站来说确实异常。

再看是谁：

`1`	`ss -tn state established '( sport = :443 )' \| awk '{print $5}' \| cut -d: -f1 \| sort \| uniq -c \| sort -rn \| head`

有一个 IP 占了三百多个连接。看 User-Agent，是一个很老的爬虫标识，明显是伪造的。

临时封掉：

`1`	`sudo iptables -I INPUT -s <IP> -j DROP`

连接数立刻下来了。但这只是止血，根本问题还在。

后来做的几件事

最直接的是给 nginx 加连接数限制：

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    limit_conn addr 20;
    limit_conn_status 429;
}

单个 IP 最多二十个并发连接，超了直接 429。这个比事后封 IP 有效得多。

另一个是 keepalive 的超时。默认 keepalive_timeout 75s，意味着一个空闲连接要占着 fd 七十五秒。我改成 20 秒：

1
2

keepalive_timeout 20s;
keepalive_requests 100;

keepalive_requests 是单个连接最多处理多少个请求，到了就关。默认是 1000，对于被爬的情况，调小能让连接更快轮换出去。

最后是把 LimitNOFILE 写进了所有需要高并发的服务，不只是 nginx。MariaDB、Redis 这些也都有各自的连接数上限，同样受这个限制。

怎么验证改对了

改完之后，我用 ab 压了一下：

`1`	`ab -n 5000 -c 200 https://blog.mibase.top/`

-c 200 是两百个并发。跑的时候盯着 fd 数量：

`1`	`watch -n 1 'ls /proc/$(pgrep -o nginx)/fd \| wc -l'`

这个数字应该随着并发上去，压测结束后回落到一个稳定的值，不报错就说明改对了。

如果还是报 Too many open files，那就是某一层的限制没改到位，按 ulimit → systemd override → nginx 配置这个顺序再检查一遍。

一点延伸

这个限制不只在 nginx 上有。

MySQL 的 open_files_limit、Redis 的 maxclients、Java 应用的 socket 数量，最后都会落到这个 fd 上限上。

还有一个容易被忽略的，就是 Docker 容器。容器里的进程继承的是宿主机的限制，但如果你在 compose 里没设，拿到的可能是 Docker daemon 的默认值。可以在 compose 里显式指定：

services:
  app:
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

这个写法比在容器里改 /etc/security/limits.conf 靠谱，因为容器里那个文件经常不生效。

现在

那天晚上折腾到快四点。改完配置，压测通过，才回去睡。

现在这台机器的 LimitNOFILE 是 65535，nginx 的 worker_connections 是 8192。跑了几个月，没再出过这个问题。

回头看，这个故障本身不复杂，但它的排查过程逼着我把 Linux 的资源限制体系理了一遍。fd 上限、ulimit、PAM、systemd、cgroup，这几层的关系搞清楚之后，很多类似的问题都能举一反三。

运维这件事，最怕的不是不懂，是以为自己懂。

根分区用到 92% 那天，我把 LVM 扩容的流程走了一遍

Sun, 12 Jan 2025 07:26:00 +0800

上个月收到监控告警，说根分区使用率 92%。

登录上去 df -h 一看，四十个 G 的盘只剩三个多 G。du -sh /* 挨个看，/var/lib/docker 占了大头，还有一堆构建缓存。

清了一轮，回到 60%。但我知道这只是暂时的，服务还在长，早晚得扩。

还好当初装系统的时候选了 LVM。要是普通分区，扩容就得停机、进救援模式、用 fdisk 调分区，风险大得多。

先理清楚 LVM 的三层

很多人被 LVM 绕晕，是因为它的名字太多。其实就三层。

物理层是 PV，Physical Volume，一块硬盘或者一个分区，初始化之后交给 LVM 管。

中间层是 VG，Volume Group，一个池子，把多个 PV 合成一个大的存储空间。

上层是 LV，Logical Volume，从池子里划出来的一块，格式化之后挂载使用。

扩容的时候，顺序是从下往上。先让 PV 变大，VG 才会跟着变大，然后才能扩 LV，最后扩文件系统。

搞反了就白做。

看现在的状态

lsblk

输出大概是这样：

NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda             254:0    0   40G  0 disk
├─vda1          254:1    0    1M  0 part
├─vda2          254:2    0  512M  0 part /boot/efi
└─vda3          254:3    0 39.5G  0 part
  ├─vg0-root    253:0    0   20G  0 lvm  /
  ├─vg0-swap    253:1    0    2G  0 lvm  [SWAP]
  └─vg0-data    253:2    0 17.5G  0 lvm  /data

这块盘 40G，vda3 是 LVM 的物理分区，占了 39.5G。里面划了三个 LV。

问题是我这块盘本来就只有 40G，没有剩余空间。所以要扩，得先给虚拟机加盘。

加盘

在云控制台或者虚拟化平台里，把磁盘从 40G 调到 80G。这一步在云厂商那边点一下就行，不用停机。

加完之后，虚拟机里 lsblk 还是显示 40G，因为内核还没重新读分区表。

1
2

lsblk
# vda 显示 80G，但 vda3 还是 39.5G

这就是关键的一步。vda 本身变大了，但 vda3 这个分区没变。

扩分区

有两种情况。

如果你用的是 GPT 分区表，而且分区后面没有别的分区，用 growpart 最省事：

`1`	`sudo growpart /dev/vda 3`

growpart 是 cloud-utils-growpart 包里的工具，大部分云镜像都预装了。

如果没装，apt install cloud-utils-growpart 或者 yum install cloud-utils-growpart。

跑完再看：

lsblk

vda3 应该变成 79.5G 了。

如果是 MBR 分区表，growpart 也能处理，但有个限制，主分区最多四个，而且扩展分区后面的空间不好扩。这种情况下得用 fdisk 删了重建分区，fdisk 的 d 删分区只删分区表项，不动数据，只要起始扇区没变就是安全的。不过操作的时候手要稳。

让 PV 认识新的大小

分区变大了，但 LVM 还不知道。因为 PV 里记录了自己的大小。

`1`	`sudo pvresize /dev/vda3`

这个命令会让 PV 重新读取分区的大小，然后更新自己的元数据。

验证：

`1`	`sudo pvs`

输出里的 PSize 应该变成 79.5G，PFree 是新增的空间。

如果 PFree 没变，说明 pvresize 没生效，回头检查分区是不是真的扩了。

扩 LV

`1`	`sudo lvs`

看当前的 LV 大小。

扩的时候有两种写法。

按绝对值扩到某个大小：

`1`	`sudo lvextend -L 40G /dev/vg0/root`

注意 -L 是最终大小，不是增量。如果你写 -L 40G 而当前已经是 40G，它什么都不会做。

按增量扩：

`1`	`sudo lvextend -L +20G /dev/vg0/root`

这个更直观，加二十个 G。

或者干脆把池子里的空间全用掉：

`1`	`sudo lvextend -l +100%FREE /dev/vg0/root`

注意这里是小写的 -l，后面跟百分比。大写的 -L 后面跟具体数值。这个大小写很容易看错。

扩文件系统

这一步最容易被忘。LV 变大了，但上面的文件系统还是原来的大小，df -h 看不出变化。

ext4 用：

`1`	`sudo resize2fs /dev/vg0/root`

不用给大小，它会自动扩到 LV 的边界。

xfs 用：

`1`	`sudo xfs_growfs /`

注意 xfs 的 xfs_growfs 参数是挂载点，不是设备名。写 /dev/vg0/root 会报错。

这是两个文件系统最明显的区别。ext4 可以缩，xfs 只能扩。所以如果你的盘用 xfs，规划的时候要留点余量，缩不回去。

在线扩容

好消息是，上面这些操作除了 growpart 之外，全都可以在线做，不用卸载不用停机。

ext4 从内核 3.6 开始支持在线扩容，resize2fs 会自动检测并走在线模式。xfs 一直是在线的。

我用的是 ext4，整个流程在跑着服务的机器上做完，中间没有中断。nginx 和数据库都没感觉。

不过还是建议在业务低峰做。虽然理论上是安全的，但万一 growpart 把分区表写坏了，那就是大事故。

一次完整的操作

把上面的命令串起来，加上 df 前后的对比：

# 扩容前
df -h /

# 分区扩容
sudo growpart /dev/vda 3

# PV 重新读取
sudo pvresize /dev/vda3

# LV 扩容
sudo lvextend -l +100%FREE /dev/vg0/root

# 文件系统扩容
sudo resize2fs /dev/vg0/root

# 验证
df -h /

我实际跑的时候，每一步之间都 lsblk 或 pvs 确认一下。多敲几条命令，比出问题再回头找强。

几个坑

growpart 之后忘了 pvresize，这是最常见的。pvs 里 PFree 是 0，你就会以为是分区没扩成功，其实只是 LVM 不知道。

lvextend 用了 -L 但写的是增量值，比如 -L 20G 而当前已经是 20G，它什么都不做，也不报错。

xfs 用 resize2fs 会直接报错说不支持，别慌，换 xfs_growfs。

还有一个，如果你的 /boot 在 LVM 上，扩它是可以的，但 grub 那边可能需要重新生成配置。我这个机器的 /boot 是独立分区，没在 LVM 里，所以没遇到。

缩容的注意事项

扩容易，缩难。

ext4 缩容要三步。先 umount，然后 e2fsck -f 检查，再 resize2fs <设备> <目标大小>，最后 lvreduce。

顺序不能反。先缩文件系统再缩 LV。如果先缩 LV，文件系统就损坏了，数据基本找不回来。

xfs 根本不支持缩容。要用 xfs 又想缩，只能备份、重建、恢复。

所以我的建议是，宁可一开始规划得保守一点，也不要给自己留缩容的活。

磁盘规划的一点经验

装系统的时候我习惯这么分：

/boot 给 512M，独立分区，不在 LVM 里。这是为了让 grub 和系统救援都能正常工作。

swap 给内存的一到两倍，但不超过 4G。现在很多云厂商建议不给 swap，我的看法是留一点，防止突发的内存尖峰直接把进程打死。

/ 给剩下的全部。不用单独分 /var 和 /home，因为 LVM 的好处就是可以动态调，一开始分太细反而失去了灵活性。

这样分下来，如果哪天 /var/lib/docker 涨得太快，我直接扩根分区就行，不用去动别的。

现在的状态

扩到 80G 之后，根分区用了 38%，/data 那边还有空间。跑了一个多月，稳定。

顺手做了两件事。一是给 docker 加了 data-root 的迁移，把镜像目录挪到了 /data 下面，这样系统盘的压力小很多。二是加了个监控，磁盘到 85% 就推消息，不用等到 92% 才被叫醒。

LVM 这个东西，平时感觉不到它的存在，真正需要的时候才发现它的好。当初装系统多勾了一个选项，省了今天一晚上的事。

journalctl 用熟了之后，排查问题快了一大截

Wed, 01 Jan 2025 13:22:00 +0800

刚开始用 systemd 那会儿，我对 journalctl 的理解就停在 journalctl -xe 这一个命令上。

出问题了就敲一下，刷出一大屏东西，然后肉眼从头翻。翻到中间发现前面还有线索，又得往上滚。滚着滚着忘了自己要找什么。

后来有一台机器的 nginx 每天早上六点准时挂一次，重启就好，第二天照旧。我靠翻日志翻了三天没找到原因，最后是同事提醒我，用 --since 把时间窗缩到五分钟。

那次之后我才认真学了这套工具。

它到底存在哪儿

先搞清楚一件事，journald 的日志默认是存在内存里的。

准确说是存在 /run/log/journal/，这是 tmpfs，重启就没了。所以很多人第一次用的时候会觉得，日志怎么只有今天的。

想让它持久化，改一下配置：

1
2
3

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

目录一建好，journald 下次启动就会自动把日志写进 /var/log/journal/，同时把 /run 里的搬过去。

这一步很重要。我见过太多人排查"昨天晚上的故障"，结果发现日志已经被重启清掉了。

时间过滤是最有用的一个

--since 和 --until 支持很自然的写法：

journalctl --since "2025-01-01 13:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until "today 06:00"
journalctl --since "-30min"

我常用的组合是这样：

`1`	`journalctl --since "today 05:50" --until "today 06:10" -u nginx`

意思是看今天早上六点前后二十分钟里 nginx 的日志。那次定时挂掉的问题，就是这么定位的。日志里有一段明显的 worker process exited on signal 9，再往前看，是 OOM killer 干的。

这个时间窗的思路比翻全部日志有用得多，尤其是日志量大的机器。

按服务看

-u 后面跟 unit 名：

`1`	`journalctl -u nginx -u php8.2-fpm`

可以跟多个，它会把两个服务的日志按时间交错排在一起。排查"nginx 502 到底是不是 php-fpm 挂了"这种问题，这个写法特别顺手。

看某个服务的全部历史：

`1`	`journalctl -u mariadb --no-pager \| less`

--no-pager 是让它别调用 less，直接输出，方便管道到 grep。

按优先级过滤

-p 参数，数字越小越严重：

0  emerg
1  alert
2  crit
3  err
4  warning
5  notice
6  info
7  debug

`1`	`journalctl -p err -b`

这个是看本次启动以来的所有错误及以上级别。-b 是 --boot 的缩写，只显示当前这次开机之后的。

-p 的行为有个细节，它是"该级别及以上"，也就是 -p err 会显示 err、crit、alert、emerg。所以只看 err 的话，得写 -p err..err。

按启动次数

-b 后面可以跟数字：

journalctl -b        # 本次启动
journalctl -b -1     # 上次启动
journalctl -b -2     # 上上次
journalctl --list-boots   # 列出所有启动记录

--list-boots 的输出长这样：

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 3f2a...                          Mon 2024-12-30 08:12:33 CST Sun 2024-12-31 22:01:09 CST
 -1 8b1c...                          Tue 2024-12-31 22:15:44 CST Wed 2025-01-01 09:33:12 CST
  0 a9d4...                          Wed 2025-01-01 09:40:02 CST Wed 2025-01-01 13:20:55 CST

这个表在排查"上次重启之前发生了什么"的时候特别好用。比如机器莫名其妙重启了，journalctl -b -1 -p err 就能看到重启前的最后几条错误。

前提是日志持久化了。没持久化的话，-b -1 是空的。

按进程和 PID

1
2

journalctl _PID=1234
journalctl _COMM=nginx

下划线开头的这些是 journald 的字段名。常用的几个：

_PID 进程号，_UID 用户 ID，_GID 组 ID，_COMM 命令名，_EXE 可执行文件路径，_SYSTEMD_UNIT 所属的服务。

_COMM 和 -u 的区别是，-u 是按 systemd 单元过滤，_COMM 是按进程名过滤。一个服务可能有多个进程，也可能有不属于任何单元的进程。

输出格式

默认的输出带颜色和缩写，人看方便，但贴到别处就乱了。

-o 参数可以换格式：

1
2
3

journalctl -o json-pretty -u nginx -n 1
journalctl -o short-iso -u nginx
journalctl -o cat -u nginx

json-pretty 能看到所有字段，调试的时候很有用。比如想看一条日志的所有元数据：

`1`	`journalctl -o json-pretty -n 1 \| jq .`

会输出 _HOSTNAME、_TRANSPORT、SYSLOG_IDENTIFIER、PRIORITY 一大堆字段。了解这些字段名，你才能写出精确的过滤条件。

short-iso 把时间戳改成 ISO 8601 格式，带时区。给别人发日志的时候用这个，不会因为时区不同产生误解。

cat 只输出消息内容，没有时间戳和主机名。适合管道给别的工具处理。

实时跟踪

1
2
3

journalctl -f
journalctl -f -u nginx
journalctl -f -p warning

-f 就是 follow，类似 tail -f。调试的时候开一个窗口挂着，另一边操作，看日志实时滚出来。

-f 加 -p warning 这个组合我经常用，它能过滤掉大量无关的 info 级别噪音，只留下值得看一眼的东西。

磁盘占用和清理

`1`	`journalctl --disk-usage`

我第一次跑的时候看到 1.8G，吓一跳。

默认的上限是文件系统的百分之十，但有最小值 4G 的兜底。也就是说，如果你的盘小于 40G，日志最多能占到 4G。这在 20G 的小机器上是灾难。

改 /etc/systemd/journald.conf：

[Journal]
Storage=persistent
SystemMaxUse=200M
SystemMaxFileSize=50M
SystemKeepFree=1G
MaxRetentionSec=1month

SystemMaxUse 是总量上限，SystemMaxFileSize 是单个文件上限，SystemKeepFree 是至少给文件系统留多少空间，MaxRetentionSec 是时间上限。

改完重启：

`1`	`sudo systemctl restart systemd-journald`

立刻清理到上限：

1
2

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=30d

这两个是手动触发的，不用等自动轮转。

权限这件事

普通用户默认只能看自己的日志。

`1`	`journalctl`

会输出 No journal files were found 或者只显示很少的内容。

要看得全，要么 sudo，要么把自己的用户加进 systemd-journal 组：

`1`	`sudo usermod -aG systemd-journal $USER`

加完要重新登录才生效。这个组是在安装 systemd 的时候建的，默认存在。

一个真实的排查过程

说说那次早上六点定时挂的问题，完整走一遍。

先确认现象：

`1`	`journalctl -u nginx --since "today 05:55" --until "today 06:05"`

看到 nginx 在 06:00:12 报了 worker process exited on signal 9，然后是 no live upstreams。

signal 9 是 SIGKILL，普通信号杀不掉它，只有 OOM killer 或者有人手动 kill -9。

看内核日志：

`1`	`journalctl -k --since "today 05:55" --until "today 06:05"`

-k 是 --dmesg 的简写，只看内核消息。果然：

`1`	`Out of memory: Killed process 12345 (nginx) total-vm:...`

那就清楚了，是内存不够。问题是为什么每天早上六点。

再查那个时间点有什么在跑：

`1`	`journalctl --since "today 05:58" --until "today 06:02" \| grep -i cron`

找到了，/etc/cron.d/backup 在 06:00 跑备份，tar 加 gzip 压缩的时候把内存吃满了。

解决办法是给备份脚本加 nice 和 ionice，再把 nginx 的 worker_processes 调小一点。改完第二天早上六点，一切正常。

整个过程大概十分钟。如果只会 journalctl -xe 从头翻，估计得翻半天。

几个小技巧

日志里有敏感信息的时候，--no-hostname 可以去掉主机名。

journalctl -n 50 是只看最后五十行，比 tail -n 50 快，因为它是从索引里直接取的。

journalctl --verify 可以检查日志文件的完整性。文件系统出过问题之后跑一下，能发现有没有损坏的段。

还有一个 journalctl -u nginx -o json | jq -r 'select(.PRIORITY=="3") | .MESSAGE'，用 jq 处理 json 格式，可以写出很复杂的过滤逻辑。日志量大的时候比 grep 好用。

现在

我现在的习惯是，遇到任何服务异常，第一步永远是：

`1`	`journalctl -u <服务名> --since "-30min" -p warning --no-pager`

这条命令基本能覆盖八成的场景。剩下的两成，才需要去翻更早的日志或者换过滤条件。

工具本身不复杂，关键是要知道它在哪儿、按什么维度组织。把时间、单元、优先级这三个维度用熟了，排查效率的提升是立竿见影的。

前后端分离之后，CORS 报错缠了我整整一个下午

Mon, 09 Dec 2024 04:26:00 +0800

朋友让我帮忙看一个后台管理页面，说他本地跑得好好的，部署到服务器上之后，登录接口一直报错。

控制台里的红字是这样的：

Access to XMLHttpRequest at 'https://api.example.com/auth/login'
from origin 'https://admin.example.com' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

典型的 CORS。我当时心想，加个头的事，十分钟搞定。

结果从下午两点弄到六点。

先说清楚 CORS 是什么

跨域资源共享，是浏览器的一套安全机制。

浏览器有个同源策略。两个 URL，协议、域名、端口三者完全一样才算同源。https://a.com 和 https://api.a.com 不同源，https://a.com 和 http://a.com 也不同源，端口不同更不用说。

不同源之间的请求，浏览器默认会拦。但这个拦分两种。

简单请求，浏览器直接发出去，服务器返回了，浏览器检查响应头里有没有 Access-Control-Allow-Origin，没有就把结果丢掉，报错。注意，请求是真的发出去了，服务器也真的处理了，只是浏览器不把结果给页面。

非简单请求，浏览器会先发一个 OPTIONS 请求，叫预检。服务器要在这个预检的响应里明确告诉浏览器，允许哪些方法、哪些头。预检通过了，浏览器才发真正的请求。

什么算非简单请求。方法不是 GET、HEAD、POST 的；Content-Type 不是 application/x-www-form-urlencoded、multipart/form-data、text/plain 的；带了自定义请求头的。这三条占一条就算。

我的登录接口用的是 POST 加 Content-Type: application/json，所以是非简单请求，会触发预检。

先看看预检返回了什么

用 curl 模拟一下：

curl -i -X OPTIONS https://api.example.com/auth/login \
  -H "Origin: https://admin.example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

HTTP/2 405
server: nginx/1.24.0
content-type: text/html
allow: POST

405 Method Not Allowed。也就是说，Nginx 把 OPTIONS 请求转给了后端，后端不认识 OPTIONS 这个方法，直接拒绝了。

问题找到了。后端框架没有处理预检请求。

让后端来处理

如果后端是 Spring Boot，加一个全局配置：

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://admin.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

allowCredentials(true) 是为了让浏览器带上 cookie。这个后面会讲到，它有个限制。

如果是 Express：

const cors = require('cors');
app.use(cors({
  origin: 'https://admin.example.com',
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  maxAge: 3600
}));

这个是正路。但有个前提，后端得能改。我这个朋友的后端是外包做的，源码不在手上，只能从 Nginx 那边想办法。

在 Nginx 里拦下来

Nginx 的做法是，遇到 OPTIONS 请求，直接返回，不往后端转。

location /auth/ {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://admin.example.com' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
        add_header 'Access-Control-Max-Age' 3600 always;
        add_header 'Content-Length' 0;
        return 204;
    }

    add_header 'Access-Control-Allow-Origin' 'https://admin.example.com' always;
    add_header 'Access-Control-Allow-Credentials' 'true' always;

    proxy_pass http://backend;
}

几个细节。

return 204 是 No Content，预检请求不需要返回内容，204 是标准做法。有些教程写 200，也能过，但 204 更准确。

always 这个参数很重要。不加它，add_header 只在响应码是 200、201、204、206、301、302、303、304、307、308 的时候才生效。如果后端返回 400 或者 500，头就没了，浏览器那边会报 CORS 错误，把真正的问题盖住。

Content-Length 0 是为了让某些严格的客户端不等待响应体。

if 在 location 里用是有风险的，官方文档里叫 “if is evil”。但这个场景是安全的，因为它只是判断一个变量然后 return，不涉及 proxy_pass 的重新求值。这是官方文档里明确认可的一种用法。

为什么不能写星号

很多人图省事，直接写：

`1`	`add_header 'Access-Control-Allow-Origin' '*';`

这个在不需要 cookie 的场景下是可以的。但只要你的前端带上了 credentials: 'include'，或者 withCredentials = true，浏览器就会拒绝。

因为规范里写得很清楚，Access-Control-Allow-Origin 是 * 的时候，Access-Control-Allow-Credentials 不能是 true。

原因不难理解。如果允许任意源加凭证，那任何网站都能带着用户的 cookie 请求你的接口，这就是 CSRF。

所以我用了具体的域名，而不是星号。

多个域名怎么办

如果前端有好几个域名，比如正式环境和测试环境，就得动态判断。

map $http_origin $cors_origin {
    default "";
    "~^https://admin\.example\.com$"      $http_origin;
    "~^https://staging\.example\.com$"    $http_origin;
    "~^http://localhost:5173$"            $http_origin;
}

server {
    location /api/ {
        add_header 'Access-Control-Allow-Origin' $cors_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Vary' 'Origin' always;
        ...
    }
}

map 里的正则要转义点号，不然 example.com 会匹配到 exampleXcom。

add_header Vary Origin 这一行别漏。它告诉缓存层，同一个 URL 对不同 Origin 的响应可能不一样。没有它，CDN 或者浏览器可能把 A 域名的响应缓存下来给 B 域名用，导致时好时坏。

一个特别隐蔽的问题

配完之后，登录接口通了，但另一个接口还是报错。

1
2

The 'Access-Control-Allow-Origin' header contains multiple values
'https://admin.example.com, https://admin.example.com', but only one is allowed.

头出现了两次。

原因是，Nginx 加了，后端也加了。两边的值一样，但浏览器只接受一个。

排查方法：

`1`	`curl -sI https://api.example.com/some/endpoint -H "Origin: https://admin.example.com" \| grep -i access-control`

能看到重复的行。

解决办法是二选一。要么让后端别加，要么在 Nginx 里用 proxy_hide_header 把后端的那个藏起来：

1
2

proxy_hide_header 'Access-Control-Allow-Origin';
add_header 'Access-Control-Allow-Origin' $cors_origin always;

这个坑我踩了很久，因为报错信息里说的是 “multiple values”，但它不会告诉你这两个值是从哪儿来的。

如果前后端不同域，cookie 的 SameSite 属性会挡住。

从 Chrome 80 开始，SameSite 默认是 Lax，意思是跨站请求不带 cookie。前后端不同域，就是跨站。

解决办法是把 cookie 设成 SameSite=None; Secure。

None 必须配 Secure，也就是说必须走 https。http 环境下浏览器会直接拒绝这个 cookie。

如果是后端设的 cookie，得改后端的配置。如果是 Nginx 设的，可以这样：

`1`	`proxy_cookie_flags ~ secure samesite=none;`

这个指令从 Nginx 1.19.3 开始有。

预检缓存

每次跨域请求之前都要发一个 OPTIONS，这个开销不小。

Access-Control-Max-Age 就是用来缓存的，单位是秒。

`1`	`add_header 'Access-Control-Max-Age' 3600 always;`

一小时之内，同一个 URL 的预检结果会被浏览器缓存，不再重复发。

这个值不能设太大。Chrome 的上限是两小时，Firefox 是二十四小时。设成 86400 在 Chrome 里也只生效两小时。

我设的 3600，一小时。对于接口地址比较稳定的场景够用了。

怎么快速验证

我后来形成了一个固定的验证流程。

先看预检：

curl -i -X OPTIONS https://api.example.com/auth/login \
  -H "Origin: https://admin.example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

返回里应该能看到 Access-Control-Allow-Origin，状态码 204。

再看实际请求：

curl -i -X POST https://api.example.com/auth/login \
  -H "Origin: https://admin.example.com" \
  -H "Content-Type: application/json" \
  -d '{"user":"test","pass":"test"}'

也要有 Access-Control-Allow-Origin。

最后在浏览器里看 Network 面板。预检请求的 Status 应该是 204，Response Headers 里有那几个头。实际请求也一样。

如果 curl 能过但浏览器不过，那多半是 cookie 或者 Vary 的问题。

还有几种替代方案

如果前后端都是自己控制的，最干净的做法是把它们放在同一个域名下。

前端在 https://example.com，后端在 https://example.com/api，Nginx 按路径分流。这样就完全没有跨域问题。

我的博客就是这个结构，静态文件在根路径，接口在 /api/ 下面，同一个域名，省心。

还有一种是用开发代理。Vite 的 server.proxy、webpack 的 devServer.proxy，本地开发的时候把 /api 代理到后端，浏览器看到的是同源请求。这个只解决开发环境，生产环境还是得配 CORS。

现在回头看

这件事花了一下午，其中真正解决问题的配置只有十几行。时间都花在排查上了。

如果一开始就知道去看预检请求的返回，可能半小时就搞定了。但当时我一直在看实际请求，没意识到问题出在 OPTIONS 那一步。

这也是 CORS 最烦人的地方，它的报错信息永远指向结果，不指向原因。你得自己一层层往回找。

现在我的习惯是，遇到 CORS，第一件事永远是 curl 一遍 OPTIONS。这一步做完，问题基本就定位了。

博客被人刷了一晚上，我用 fail2ban 把这事收了个尾

Fri, 30 Aug 2024 23:33:00 +0800

那天早上起来，博客打不开了。

浏览器转圈，转了很久之后给了一个 502。我一边刷牙一边用手机连上去看，uptime 显示 load average 是 34。

我那台机器是 1 核 2G，正常负载在 0.1 左右。34 这个数字意味着有东西在疯狂占 CPU。

先看是什么在打

`1`	`ss -tn state established '( sport = :443 )' \| awk '{print $5}' \| cut -d: -f1 \| sort \| uniq -c \| sort -rn \| head`

输出里有一批 IP，每个都有几百个连接。再看 nginx 的访问日志：

`1`	`awk '{print $1}' /var/log/nginx/access.log \| sort \| uniq -c \| sort -rn \| head -20`

排名第一的 IP 在十分钟里请求了三万多次。

`1`	`grep '1.2.3.4' /var/log/nginx/access.log \| tail -5`

请求的路径全是 /search?q=<随机字符串>，User-Agent 是一个老掉牙的浏览器标识。典型的 CC 攻击，拿一个搜索页反复刷，因为这个页面每次都查数据库，最耗资源。

临时的止血

先把那个 IP 拉黑，让机器能喘口气：

`1`	`iptables -I INPUT -s 1.2.3.4 -j DROP`

立刻见效，负载从 34 掉到 2。但十分钟后，另一个 IP 开始用同样的方式打。

这就说明手动拉黑没用，攻击方手里有一批 IP，封一个换一个。

那就上 fail2ban

fail2ban 的思路很简单。它盯着日志文件，按你写的规则匹配失败记录，同一个 IP 在时间窗口里超过阈值就调用防火墙把它封一段时间。

装：

1
2

apt update
apt install fail2ban -y

Debian 12 装完默认就是启用的，但里面除了 sshd 那个 jail，别的都没开。

配置不要改 /etc/fail2ban/jail.conf，那个文件在升级的时候会被覆盖。新建一个 jail.local：

`1`	`cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local`

先把 SSH 那边接上

虽然这次的攻击是打 HTTP，但 SSH 那边的爆破一直没停过。顺手一起处理。

jail.local 里找 [sshd] 段，或者干脆在文件末尾新加：

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s

backend = systemd 这个设置值得说一下。Debian 12 默认没有 /var/log/auth.log 了，认证日志都进了 journald。用 systemd 这个 backend，fail2ban 会通过 journalctl 去读，不用依赖文件存在。

我第一次配的时候没改这个，fail2ban 起不来，日志里写着 Have not found any log file for sshd jail。找了半天才明白。

再配 nginx 的 jail

这个要自己写，因为每个站的日志格式和攻击特征都不一样。

先看日志格式。我的 nginx 用的是默认的 combined，长这样：

`1`	`1.2.3.4 - - [30/Aug/2024:03:12:44 +0800] "GET /search?q=xxx HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."`

fail2ban 的 failregex 用正则去匹配这一行，<HOST> 是个占位符，会自动替换成 IP 的匹配模式。

针对这次攻击，我写了个 filter，放在 /etc/fail2ban/filter.d/nginx-cc.conf：

[Definition]

failregex = ^<HOST> -.*"(GET|POST|HEAD) /search\?.* HTTP/1\.[01]" 200

ignoreregex =

意思是，请求 /search 且返回 200 的，算一次。

然后在 jail.local 里加：

[nginx-cc]
enabled  = true
port     = http,https
filter   = nginx-cc
logpath  = /var/log/nginx/access.log
maxretry = 30
findtime = 1m
bantime  = 2h

maxretry = 30 和 findtime = 1m 意味着，一分钟内请求同一个路径超过三十次就封。正常用户不可能这么干，但搜索引擎的爬虫有可能。所以我还得加个白名单。

别把自己的爬虫封了

Google 和 Bing 的爬虫会被误伤。虽然它们一般不会一分钟请求三十次，但保险起见，还是加个 ignoreip。

先确认爬虫的真实 IP。注意不能信 User-Agent，得用反向解析：

`1`	`dig +short -x 66.249.66.1`

返回 crawl-66-249-66-1.googlebot.com. 就说明是真的。伪造的 UA 反解出来不会是这个域名。

把这个网段加进白名单：

1
2

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 66.249.64.0/19 40.77.167.0/24

前者是 Googlebot，后者是 Bingbot。这两个网段官方都有公布，定期看一眼有没有变。

让 Cloudflare 的真实 IP 传进来

这一步很重要，我差点漏了。

我的博客前面挂了 Cloudflare，所以 nginx 的访问日志里，$remote_addr 全是 Cloudflare 的节点 IP。如果不处理，fail2ban 会去封 Cloudflare 的节点，一封就是一大片用户打不开。

要在 nginx 里先把真实 IP 还原：

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 104.16.0.0/13;
# ... 其余网段省略
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

Cloudflare 官方有个 IP 列表页面，也可以直接拉：

`1`	`curl -s https://www.cloudflare.com/ips-v4`

把这些网段全部写进 set_real_ip_from。配好之后 nginx -t && nginx -s reload，再看日志，$remote_addr 就是真实访客的 IP 了。

这一步做完，fail2ban 封的才是攻击者，不是 Cloudflare。

防火墙后端用哪个

fail2ban 支持好几种后端，iptables、nftables、firewalld。Debian 12 默认是 nftables，但 fail2ban 的默认配置可能还在用 iptables。

看当前用的是哪个：

`1`	`fail2ban-client -d \| grep -i banaction`

如果是 iptables-multiport，而系统里其实是 nftables，封禁规则会写进 iptables 的兼容层，虽然也能生效，但 nft list ruleset 里看到的格式很乱，排查的时候不方便。

改一下：

1
2
3

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

然后重启 fail2ban。

验证和观察

1
2

systemctl restart fail2ban
systemctl status fail2ban

看 jail 有没有都起来：

`1`	`fail2ban-client status`

应该能看到 sshd 和 nginx-cc 两个。

看某个 jail 的详情：

`1`	`fail2ban-client status nginx-cc`

输出里有当前封了多少个、总共封过多少个、以及封禁列表。

我配完第二天看了一下，nginx-cc 封了 200 多个 IP，sshd 封了 60 多个。负载回到了 0.2。

几个后续调整

bantime 我一开始设的 1 小时，后来改成递增。fail2ban 支持这个：

1
2
3

bantime.increment = true
bantime.factor   = 2
bantime.maxtime  = 4w

意思是第一次封 1 小时，再犯封 2 小时，再犯 4 小时，一直翻倍到四周。这个机制对那种反复来的 IP 很有效。

bantime.increment 需要 fail2ban 的数据库支持，默认是开着的，位置在 /var/lib/fail2ban/fail2ban.sqlite3。别把它删了，删了计数就归零。

还有个 findtime 的坑。它和 bantime 是独立的，findtime 只决定统计窗口，不影响封多久。我一开始以为 findtime 设长了封得久，结果不是。

也别忘了限流

fail2ban 是事后处理，等它反应过来，攻击流量已经打进来几十秒了。

所以我又在 nginx 里加了一层限流：

limit_req_zone $binary_remote_addr zone=search:10m rate=10r/m;

location /search {
    limit_req zone=search burst=5 nodelay;
    limit_req_status 429;
}

这个是事前的，请求超过频率直接返回 429，连 PHP 都不进。两层配合起来，效果比单独用任何一个都好。

写在最后

这次攻击持续了大概两天，之后就没再来了。可能是对方觉得我这个站不值得，也可能是成本太高。

回过头看，最该反思的是那个搜索页。它是动态查询，没有缓存，一个请求就要连一次数据库。这种页面天生就是被刷的目标。

后来我给搜索结果加了一层 Redis 缓存，同样的查询五分钟内直接返回缓存。这个改动比 fail2ban 更治本，因为它把攻击的成本降下来了。

安全这件事，工具只是兜底。真正要做的，是让被攻击的那个点变得不那么值钱。

两个容器明明在同一个宿主机上，就是互相连不上

Mon, 29 Jul 2024 02:54:00 +0800

有段时间我在搭一个小的内部工具，前端是一个 PHP 的容器，后端是一个 Redis 容器。两个都在同一台机器上，端口也都正常开着。

但 PHP 那边一连 Redis 就报错，Connection refused，或者更奇怪一点，php_network_getaddresses: getaddrinfo failed。

我当时的第一反应是，两个容器不是都在 172.17.0.x 这个网段吗，怎么可能连不上。

这个想法本身就是错的。花了小半个晚上才想明白问题出在哪，记一下。

先看清楚默认的 bridge 网络

我当时的启动命令大概是这样的：

1
2

docker run -d --name redis redis:7
docker run -d --name web -p 8080:80 php:8.2-apache

两条命令都没指定 --network，所以它们都跑在默认的 bridge 网络上。

docker network inspect bridge 看一眼：

`1`	`docker network inspect bridge --format '{{json .Containers}}' \| jq`

两个容器确实都在里面，IP 分别是 172.17.0.2 和 172.17.0.3。

那我先进 web 容器里试一下：

1
2

docker exec -it web bash
ping 172.17.0.3

通。说明二层是通的，两个容器确实能互相访问。

`1`	`ping redis`

ping: bad address 'redis'

到这里问题就很清楚了。IP 能通，名字解析不了。

默认 bridge 没有内置 DNS

这是 Docker 里一个非常容易踩的点。

在默认的 bridge 网络上，Docker 是不提供自动服务发现的。容器之间只能通过 IP 通信，不能通过容器名。你想让 redis 这个名字能解析，得自己用 --link，而这个参数早就被标记成废弃了，官方文档里明确说不建议用。

那为什么我印象里"容器名可以互相访问"呢。

因为自定义网络可以。

只要你自己建一个 bridge 网络，Docker 就会给它启用一个内置的 DNS 服务器，所有接入这个网络的容器都会自动注册自己的名字。之后容器之间直接 ping 服务名 就能通。

这就是关键区别。默认 bridge 是个历史包袱，为了兼容早期的行为，它没开这个功能。

改成自定义网络

1
2
3

docker network create appnet
docker run -d --name redis --network appnet redis:7
docker run -d --name web --network appnet -p 8080:80 php:8.2-apache

再进 web 容器：

`1`	`docker exec -it web bash -c "getent hosts redis"`

这次输出 172.18.0.2 redis，解析成功了。

不过这里还有个细节。ping 在 php:8.2-apache 这个镜像里可能没装，getent hosts 更通用一些。curl、nc 这些也未必有，排查的时候先确认工具在不在。

内置 DNS 是怎么回事

Docker 在每个自定义网络的容器里塞了一个 127.0.0.11 的 DNS 服务器。你可以看一下容器里的 /etc/resolv.conf：

`1`	`docker exec web cat /etc/resolv.conf`

输出大概是：

1
2

nameserver 127.0.0.11
options ndots:0

这个 127.0.0.11 是 Docker 的 embedded DNS。它拦截容器内的所有 DNS 查询，先查自己维护的一张表，也就是同一网络里其他容器的名字。查不到再转发给宿主机的 DNS 或者你在 daemon.json 里配的上游。

ndots:0 这个选项也有讲究。它决定了域名里有多少个点才被当成绝对域名。设成 0 意味着任何带点的名字都先当绝对域名查，不做 search domain 的拼接。这个值能减少很多无谓的查询延迟。

那我当初为什么连 IP 也失败过

前面说 IP 能 ping 通，但那是后来验证的。我最初遇到的报错是 Connection refused，这个和 DNS 没关系，是另一个问题。

Redis 的镜像默认只监听 127.0.0.1。这是从 Redis 3.2 开始的默认行为，官方镜像也继承了这个配置。也就是说，就算你从外面连得上这个容器的 IP，Redis 本身也只接受本机回环的连接。

解决办法是启动的时候覆盖掉：

`1`	`docker run -d --name redis --network appnet redis:7 redis-server --bind 0.0.0.0`

或者用配置文件：

1
2
3

docker run -d --name redis --network appnet \
  -v ./redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7 redis-server /usr/local/etc/redis/redis.conf

配置文件里写 bind 0.0.0.0，再配一个 requirepass，因为一旦绑到 0.0.0.0，同网络里任何容器都能连，得有个密码。

这里顺便说一句，bind 0.0.0.0 不等于把 Redis 暴露到公网。只要你没做端口映射，外面还是进不来，只有同一 Docker 网络里的容器能访问。这个边界很容易搞混。

名字里的下划线和连字符

还有一次，我在 Compose 里把服务名写成了 my_redis，然后在应用配置里写 my_redis，死活解析不了。

查了半天，是 Docker 的 DNS 对下划线的处理有点特殊。容器名里带下划线的时候，有些客户端库在做解析的时候会失败，因为下划线在主机名规范里本来就不是合法字符。

把服务名改成 my-redis，问题立刻消失。

所以我的建议是，容器名和服务名只用小写字母、数字和连字符。别用下划线，也别用大写。这个约定能省掉很多莫名其妙的解析失败。

Compose 里的网络行为

Compose 比裸 docker run 好一些，它会自动为每个项目建一个网络，项目内的服务默认都接进去，名字自动能解析。

但有几个地方还是会踩。

一个是跨项目。项目 A 的容器想连项目 B 的容器，默认是连不上的，因为它们在两个不同的网络里。得建一个外部网络，两边都声明 external: true 接进去。

另一个是 container_name 和 services 键的区别。如果你设了 container_name: redis，那这个容器在网络里的别名就是 redis。如果你没设，Compose 生成的容器名是 项目名-redis-1，但它在网络里的别名同时包含 redis 和 项目名-redis-1。所以在同一个 Compose 项目里，写服务名总是能通的。

这个行为在扩容的时候会变。docker compose up --scale web=3 之后，三个 web 容器会共享 web 这个别名，DNS 返回的是一组 IP，客户端连到哪个不确定。这时候做负载均衡是它自带的，不需要额外配置。

一个特别隐蔽的坑：网络别名冲突

我有一次把两个不同的项目都接到了同一个外部网络里，然后两边都有一个叫 db 的服务。

结果就是 DNS 返回两个 IP，客户端随机连，有时候连到 A 的数据库，有时候连到 B 的。数据错乱了一整天才发现。

解决办法是给服务加显式的网络别名：

services:
  db:
    networks:
      shared:
        aliases:
          - projectA-db

然后应用里就写 projectA-db。这样不会撞。

或者干脆别共用网络，用不同的网络隔离。这个我后来更倾向，隔离得越清楚，出问题的概率越小。

排查顺序

踩过这几次之后，我形成了一个固定的检查顺序。

先看容器在不在同一个网络：

1
2

docker inspect web --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'
docker inspect redis --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'

两个输出里得有至少一个共同的网络名。

再看容器里的 DNS 配置：

`1`	`docker exec web cat /etc/resolv.conf`

得看到 127.0.0.11。

再试解析：

`1`	`docker exec web getent hosts redis`

能解析出 IP 说明名字这块没问题了。

最后测连通性：

`1`	`docker exec web nc -zv redis 6379`

到这一步还不行，那就是服务本身没监听对地址，或者有防火墙规则。

这套顺序跑一遍，基本五分钟内能定位。

现在的习惯

我现在新起一个服务，一律先建自定义网络，绝不往默认 bridge 里塞东西。

Compose 的话，我习惯显式写一个 networks 段，哪怕只是默认的那个。写出来心里有数，不用去猜它自动生成了什么名字。

还有个小习惯，我在容器里排查的时候，如果发现 ping、curl、nc 都没有，会临时起一个 nicolaka/netshoot 容器接到同一个网络上：

`1`	`docker run -it --rm --network appnet nicolaka/netshoot`

这个镜像里工具很全，dig、tcpdump、curl、nc 什么都有。比自己往业务镜像里装工具干净得多。

这类网络问题，说穿了就是"默认配置不是你以为的那个"。默认 bridge 没有 DNS，Redis 默认只听回环，容器名别带下划线，这三件事记住了，能省掉一大半的排查时间。

20G 的硬盘被 Docker 吃干净了，我把清理这件事理顺了

Wed, 22 May 2024 10:46:00 +0800

那天早上是被监控机器人的 Telegram 消息震醒的。

[WARN] rootfs usage 92%，我那台 20G 硬盘的小机器。前一天晚上看还是 78%，一夜之间涨了十几个点。

登上去 df -h 一看，/ 确实快满了。但奇怪的是，du -sh /var/lib/docker 只有 9 个多 G，和我印象里的数字差不多。真正占地方的东西藏在哪儿了。

这次排查让我把 Docker 的磁盘占用彻底搞清楚了一遍，记下来。

先搞清楚它到底占了多少

`1`	`docker system df -v`

这个命令比 docker system df 详细得多，它会把镜像、容器、本地卷、构建缓存四类分开列，每一类还列出具体的条目和大小。

我第一次跑出来的结果是这样的：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          42        9         18.6GB    13.2GB (71%)
Containers      11        8         210MB     180MB (85%)
Local Volumes   17        6         3.1GB     1.4GB (45%)
Build Cache     88        0         2.4GB     2.4GB

十八个 G 的镜像，只有九个是活跃的。这就是问题所在。

我这两年在同一台机器上试过太多东西，什么 GitLab、Drone、MinIO、各种数据库版本，装完觉得不好用就 docker compose down 了，容器没了，镜像还躺在那儿。每个都几百兆，攒起来就是十几个 G。

镜像怎么清

最直接的是清掉那些没有标签的悬空镜像：

`1`	`docker image prune`

它只会删掉 <none>:<none> 那种，也就是构建过程中产生的中间层，或者被新版本顶掉标签的旧镜像。这个操作是安全的，因为没有任何容器在用它们。

如果想连"有标签但没有容器使用"的一起删：

`1`	`docker image prune -a`

这个就要小心了。它会问你确认，确认之后把所有没被容器引用的镜像全删掉。我当时脑子一热跑了这个，结果把我准备好的 mariadb:10.11 也删了。虽然能重新拉，但那台机器的网络拉大镜像很慢，花了十几分钟。

后来我的做法是先看清单再决定：

`1`	`docker image ls --filter "dangling=false" --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}\t{{.CreatedSince}}"`

按创建时间排序，心里有个数，再挑着删。

单个删：

`1`	`docker image rm <IMAGE_ID>`

如果提示被容器引用，先看是哪个容器：

`1`	`docker ps -a --filter ancestor=<IMAGE_ID>`

容器和它的可写层

docker ps -a 里那些 Exited 状态的容器，很多人以为删了容器就干净了，其实容器本身的可写层也占空间。

`1`	`docker container prune`

这个只删已停止的容器。有几点要提醒。

容器删了，它的可写层就没了。如果你在容器里手动改过什么文件、装过什么包，没写进镜像也没挂载出来，那部分就彻底丢了。我之前有个容器，为了图省事直接在里面 apt install 了个工具，后来 prune 一跑，第二天发现功能没了，又得重来一遍。

所以正确做法是，要么写进 Dockerfile，要么挂载出来，别指望容器的可写层能长期保存东西。

数据卷是最需要小心的一类

`1`	`docker volume prune`

这个命令删的是"没有被任何容器引用"的卷。听起来很安全，实际上有个陷阱。

我那次跑完之后，发现一个早就停掉的测试容器的数据卷被删了。虽然那个容器本来也没用了，但里面存着我早期的一些实验数据。删掉之后想找回来是不可能了。

所以我的建议是，跑之前先列出来看看：

`1`	`docker volume ls --filter "dangling=true"`

确认这些名字你都不认识、也不想要，再执行 prune。

更稳的做法是一个一个删：

`1`	`docker volume rm <VOLUME_NAME>`

麻烦，但至少你知道自己删了什么。

还有一种情况要注意。如果卷的名字是 Compose 自动生成的（形如 项目名_卷名），你 docker compose down 的时候不加 -v，卷是会保留的。加了 -v 就会连卷一起删。这个 -v 我在文档里看到过好几次，但真正记住是在一次误操作之后。

构建缓存：最容易被忽略的大头

这个是我这次排查才发现的大户。

`1`	`docker builder prune`

它会删掉 BuildKit 的缓存。现在的 Docker 默认用 BuildKit，每次 docker build 都会把中间层缓存下来，下次构建能复用。这个机制很好，但缓存不会自己过期，越攒越多。

我那次看到 2.4G，基本上都是几个月前折腾某个项目留下的。

想连所有缓存一起清：

`1`	`docker builder prune -a`

-a 是 all，包括那些还在被引用的缓存。清完之后下次构建会慢一些，但空间能立刻回来。

还有个带时间过滤的用法，我觉得挺实用：

`1`	`docker builder prune --filter "until=168h"`

只删七天以前的。这样常用的缓存还能留着，老的自然淘汰。

一键清理，以及为什么我不推荐

网上到处都写着这条：

`1`	`docker system prune -a --volumes`

它会把停止的容器、没用的网络、所有没被引用的镜像、所有没被引用的卷、所有构建缓存，一次性全清掉。

确实爽，我那次跑完从 92% 降到了 51%。

但我不推荐把它当成日常操作。原因有三个。

它不问你就删卷。数据卷里可能有你还没意识到重要的东西。

它把镜像全清了。下次起服务要重新拉，如果网络不好，等于给自己挖坑。

它不区分环境。你在开发机上跑和在跑着线上服务的机器上跑，风险完全不一样。我有一次在生产机上顺手跑了，把一个还没启动但准备切换的旧版本镜像删了，回滚的时候抓瞎。

我现在的固定动作

经过这次，我给自己定了一套流程，每个月做一次。

先看占用：

`1`	`docker system df -v`

然后按风险从低到高依次清：

1
2
3

docker container prune -f
docker image prune -f
docker builder prune -f --filter "until=336h"

这三条都是只删"明确没用"的东西，相对安全。卷我单独处理，先 docker volume ls --filter dangling=true 看清单，确认了再手动删。

再加上一条，给日志设上限。这个比清理更治本。Docker 默认的 json-file 驱动不限制大小，一个话多的服务能写到几个 G。我在每个 compose 文件里都加了：

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

这样单个容器最多占 30M 日志，怎么跑都撑不爆。

顺手发现的一个问题

清理的时候我注意到 /var/log 下面也有几个 G。是 journald 的日志，默认能占到磁盘的 10%。

`1`	`journalctl --disk-usage`

看到是 1.8G。我改了 /etc/systemd/journald.conf：

`1`	`SystemMaxUse=200M`

然后 systemctl restart systemd-journald，空间立刻回来了。

这个问题和 Docker 没关系，但它们是同一类问题，都是"某个东西默认不限制自己，跑久了就把盘吃满"。清理只是补救，设上限才是根治。

现在的状态

清完之后稳定在 55% 左右，跑了两个月没再告警。

我也顺手在监控里加了一条，磁盘超过 80% 就推消息。这次是被 92% 才叫醒的，有点晚。早点知道，处理起来从容得多。

回头看，这件事本身没什么技术含量，真正花时间的是搞清楚哪些能删、哪些不能。Docker 把很多东西藏起来了，system df -v 这个命令就是那把钥匙。知道东西在哪儿，才谈得上管理。

用了两年 Docker Compose，我把这些套路固定下来了

Tue, 26 Mar 2024 06:32:00 +0800

刚开始用 Docker 那阵子，我特别喜欢在命令行里敲 docker run。参数一行能拉出去两百多个字符，-v、-p、-e 混在一起，看着挺有成就感。

直到有一次我为了调一个环境变量，把容器删了重建，结果忘了当初挂载的路径是哪个。数据卷还在，但容器起不来了，日志里全是找不到配置文件的报错。我在 docker inspect 的输出里翻了十几分钟，才从一个早已忘记的临时目录里把东西找回来。

那次之后我就老老实实用 Compose 了。现在服务器上所有的服务，都是一个个 compose.yaml 管着。

为什么是 Compose 而不是别的

有人会说，你都上 Docker 了，干嘛不上 Kubernetes。

我的答案很朴素，我就一台 2 核 4G 的机器，跑着七八个容器。K8s 的控制面自己就要吃掉一两个 G，剩下的空间还不够我塞服务。而且我一个人维护，出问题的时候需要的是能快速看懂的东西，不是一整套抽象。

Compose 的好处是，所有配置都在一个文件里，看得见摸得着。改完 docker compose up -d，它自己算差异，只重建变化的部分。要回滚就把文件换回去再 up 一次。

还有个被低估的点，就是文件本身就是文档。半年后我忘了某个服务是怎么配的，打开文件一看全明白了。

目录怎么摆

我现在的习惯是，所有服务放在 /srv 下面，一个服务一个目录：

/srv
├── blog
│   ├── compose.yaml
│   └── data
├── db
│   ├── compose.yaml
│   ├── conf
│   └── data
├── proxy
│   ├── compose.yaml
│   ├── conf.d
│   └── certs
└── monitor
    ├── compose.yaml
    └── data

数据统一放在服务目录下的 data 子目录，然后挂载进去。这样备份的时候，把 /srv 整个打包就够了，不用去 /var/lib/docker 里翻那些名字是哈希的目录。

这一点很关键。Docker 的具名卷虽然方便，但它在文件系统里藏在 /var/lib/docker/volumes/ 下面，备份脚本写起来很难看。用 bind mount 直接映射到自己的目录，什么都清楚。

一个完整的例子

拿博客举例。我的博客是 Hugo 生成的静态文件，用一个 nginx 容器托管：

services:
  blog:
    image: nginx:1.25-alpine
    container_name: blog
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./public:/usr/share/nginx/html:ro
      - ./conf.d:/etc/nginx/conf.d:ro
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1/"]
      interval: 30s
      timeout: 5s
      retries: 3
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

几个地方值得说。

ports 我只绑了 127.0.0.1，不写 0.0.0.0。意思是这个端口只能从本机访问，外面进不来。真正对外的入口交给 nginx 反向代理，这样容器端口就不会直接暴露在公网上。这一点在我被扫过几次之后变得特别重要。

restart: unless-stopped 而不是 always。区别在于，我手动 docker compose stop 之后，unless-stopped 的容器重启机器也不会自己起来，always 会。调试的时候这个区别能省不少事。

logging 那段一定要加。Docker 默认的 json-file 日志没有大小限制，一个话多的服务跑上几个月，能把磁盘写满。我第一次被磁盘告警吵醒就是因为这个，日志文件堆到了 20 多个 G。

healthcheck 是给后面的 depends_on 用的，下面会讲。

数据库和依赖顺序

数据库的 compose 我一般这么写：

services:
  mariadb:
    image: mariadb:11.2
    container_name: mariadb
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root
      MARIADB_DATABASE: app
      MARIADB_USER: app
      MARIADB_PASSWORD_FILE: /run/secrets/db_app
      TZ: Asia/Shanghai
    volumes:
      - ./data:/var/lib/mysql
      - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro
    ports:
      - "127.0.0.1:3306:3306"
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

secrets:
  db_root:
    file: ./secrets/db_root.txt
  db_app:
    file: ./secrets/db_app.txt

密码用 secrets 而不是直接写 environment。这样 docker inspect 出来的环境变量里看不到明文，compose.yaml 也可以放心提交到私有仓库。文件权限设成 600 就行。

start_period 这个参数新手容易忽略。它是给容器一个"还在启动中，别急着判定失败"的宽限期。MariaDB 第一次初始化数据目录要花几十秒，不设这个，健康检查会一直失败，把容器标记成 unhealthy。

healthcheck.sh 是 MariaDB 官方镜像自带的脚本，比自己拼 mysqladmin ping 可靠，因为它会真的等到 InnoDB 初始化完。

应用那边要等数据库好了再起，就这么写：

  app:
    image: myapp:latest
    depends_on:
      mariadb:
        condition: service_healthy

注意是 service_healthy，不是默认的 service_started。默认那个只保证容器进程起来了，不保证里面服务能连。我第一次用默认值的时候，应用每次重启都要重试好几次才连上数据库，日志里一堆 connection refused。

网络怎么连

Compose 默认会给项目建一个 bridge 网络，同一个文件里的服务互相用服务名就能访问。这个挺好用，但跨文件就不行了。

我有两个选择。要么把相关服务塞进同一个 compose 文件，要么建一个外部网络让它们共享。

我选了后者，因为数据库和博客的更新节奏不一样，混在一个文件里，改博客的配置会把数据库也带着重建一次，太危险。

建网络：

`1`	`docker network create --driver bridge shared`

然后每个文件里都声明：

1
2
3

networks:
  shared:
    external: true

服务上再加一句：

1
2

    networks:
      - shared

这样博客容器里直接 ping mariadb 就能通。

不过这里有个坑，container_name 和自定义网络里的服务名是两套东西。用 container_name 的时候，容器在网络里的别名是那个名字，不是 services 下的键。我一开始没注意，配置里写服务名连不上，改成 container_name 才对上。

我的建议是干脆别用 container_name，让 Compose 自己按 项目名-服务名-序号 生成。虽然名字长一点，但不会和别的项目冲突，扩容的时候也不会撞名。

反代那一层

nginx 做反向代理的容器，配置文件单独放：

server {
    listen 80;
    server_name blog.mibase.top;

    location / {
        proxy_pass http://blog:80;
        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_pass 里写的是容器名，因为它在同一个 shared 网络里，Docker 的内置 DNS 会解析。

X-Forwarded-For 这几行别省。省了之后，nginx 的访问日志里全是反代容器的内网 IP，你想看真实访客来源就看不到了。Cloudflare 那边传过来的真实 IP 也会在这一层层里丢掉。

更新镜像的流程

我不用 watchtower 那种自动更新的东西。自动更新很爽，但它会在你睡觉的时候把一个能跑的服务换成一个跑不起来的版本。

我的流程是手动但固定：

cd /srv/db
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=50

拉完先看 ps，确认状态是 running 并且 healthy，再看日志有没有报错。有问题就 docker compose down 然后换回上一个 tag。

所以镜像 tag 我尽量不用 latest，写具体版本号。mariadb:11.2 比 mariadb:latest 可控太多了。

备份怎么配合

因为数据都在 /srv/*/data 下面，备份脚本写起来很直接：

#!/bin/bash
set -euo pipefail
ts=$(date +%F)
tar -czf /backup/srv-$ts.tar.gz -C / srv --exclude='*/cache/*'

不过数据库不能这么直接打包，热备份出来的文件可能是不一致的。数据库我单独用 mariadb-dump 导出：

`1`	`docker compose exec -T mariadb mariadb-dump --all-databases --single-transaction > /backup/db-$ts.sql`

--single-transaction 保证导出的是一个一致的时间点，不会因为导出过程中有人写入而错乱。

写在最后

Compose 这个工具本身不复杂，难的是把使用习惯固定下来。

我现在新加一个服务，基本就是复制一个已有的目录，改改镜像名和端口，十分钟能跑起来。出问题的时候也知道去哪儿看，日志在哪、数据在哪、配置在哪，都是固定的位置。

这套东西没什么高深的技术，但它让我在面对一台跑了两年、装着七八个服务的机器时，心里是有底的。这大概就是运维这件事最实际的价值。