在 nginx 中平滑重载更新 limit_req 限流规则配置，核心做法是修改配置文件后执行 nginx -s reload。该命令会触发主进程（master）重新加载配置并启动新的工作进程（worker），旧的工作进程在处理完当前请求后优雅退出，从而实现零停机更新。需要注意的是，limit_req_zone 定义的共享内存区域（shared memory zone）在重载时会被清空，这意味着重载瞬间所有客户端的限流计数将重置为初始状态。
如何定义限流内存区域与速率限制
要实现限流，必须在 http 块中使用 limit_req_zone 指令定义一个命名区域，并在 server 或 location 块中使用 limit_req 指令引用该区域。定义区域时需指定键（如 $binary_remote_addr）、内存大小和平均速率。例如，设置每秒允许 5 个请求，内存区域大小为 10MB。这种配置方式确保了限流逻辑基于服务器端的内存统计，而非客户端行为。
worker_processes auto;
events {
worker_connections 1024;
}
http {
# 定义限流区域：key为IP，大小10m，速率5r/s
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=5r/s;
server {
listen 80;
server_name example.com;
location /api/ {
# 引用限流区域，允许突发处理
limit_req zone=ip_limit burst=10 nodelay;
proxy_pass http://backend;
}
}
}
上述配置中，zone=ip_limit:10m 创建了名为 ip_limit 的共享内存区，用于存储各 IP 的请求计数。rate=5r/s 设定了平均速率。burst=10 允许在超过平均速率时，将额外请求放入队列缓冲，最多容纳 10 个。nodelay 表示一旦有缓冲空间，立即处理这些突发请求，而不是延迟它们。如果不加 nodelay，超出速率的请求将被延迟处理直到缓冲耗尽。实际运行时，Nginx 会根据 $binary_remote_addr 的值对每个客户端 IP 进行独立计数。当某个 IP 的请求频率超过 5r/s 且缓冲满时，Nginx 将返回 503 Service Temporarily Unavailable 错误。
重载配置时的内存区域行为与影响
执行 nginx -s reload 时，Nginx 主进程会验证新配置文件的语法，若无误则生成新的工作进程。此时，之前由旧工作进程维护的 limit_req_zone 共享内存数据会被释放并重新初始化。这意味着所有已建立的连接中的限流计数器归零。对于正在被限流的客户端，它们在重载后的第一个请求将不再受之前的累积计数影响，而是从新的计数周期开始。这种“软重置”可能导致短暂的限流失效窗口，如果业务对连续性要求极高，需考虑此风险。
# 模拟重载过程 # 1. 检查配置语法 nginx -t # 2. 发送信号给主进程进行平滑重载 nginx -s reload # 3. 观察日志确认新进程启动 # master process is shutting down. # new worker processes are starting...
在实际操作中，建议先使用 nginx -t 测试配置文件的正确性，避免语法错误导致重载失败。重载命令 nginx -s reload 向主进程发送 HUP 信号。主进程收到信号后，不会立即停止，而是先启动新进程，待新进程完全接管监听端口后，再通知旧进程关闭。这个过程中，Nginx 的共享内存区域（包括 limit_req_zone 和 limit_conn_zone）会在主进程切换时重建。因此，任何依赖历史请求计数的限流策略都会在重载后失效。如果需要更精细的控制，比如在不重置计数的情况下更新速率，目前 Nginx 原生不支持热更新内存数据，只能通过外部工具或自定义模块实现，但标准做法仍是接受重载带来的计数重置。
如何验证限流规则是否生效及返回状态码
验证 limit_req 是否生效，最直接的方法是构造高频请求并观察响应状态码。当请求速率超过设定的 rate 且 burst 缓冲耗尽时，Nginx 默认返回 HTTP 503 状态码。可以通过 curl 命令快速测试。例如，使用循环发送请求，监控返回的状态。此外，可以在 error_log 中查看是否有 limiting requests 的记录，这有助于排查限流问题。确保 proxy_intercept_errors 设置为 on，以便 Nginx 能拦截后端返回的错误并重写为配置的限流错误页，但这不影响限流本身的判断逻辑。
# 测试脚本：快速发送请求以触发限流
for i in {1..20}; do
curl -s -o /dev/null -w "%{http_code}\n" http://example.com/api/test
done
# 预期输出：前几个请求返回 200，随后可能返回 503
# 具体取决于 burst 和 nodelay 的设置
在上述测试中，如果设置了 burst=10 nodelay，前 5 个请求（对应 1 秒内的速率）会立即返回 200，接下来的 10 个请求也会立即返回 200（因为缓冲允许），之后的请求才会返回 503。如果不设置 nodelay，超出的请求会被延迟处理，可能导致客户端超时。通过调整 burst 和 nodelay，可以平衡用户体验和服务器保护。例如，对于 API 接口，通常希望严格限流，可设置较小的 burst 或不设 nodelay；对于静态资源，可适当放宽。最终，通过观察返回的 HTTP 状态码和错误日志，可以确认限流规则是否正确应用以及是否按预期工作。
