Nginx on 寻 Mi 处

同一个 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 也好，下载站也好，只要能定义"正常使用的频率"，就能用同样的方法保护自己。

凌晨两点收到 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，这几层的关系搞清楚之后，很多类似的问题都能举一反三。

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

前后端分离之后，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 更治本，因为它把攻击的成本降下来了。

安全这件事，工具只是兜底。真正要做的，是让被攻击的那个点变得不那么值钱。