低功耗设备高并发流控应优先采用 $binary_remote_addr + limit_req_zone 轻量原生方案，因其内存占用低、CPU 占用

在低功耗设备（如树莓派、OpenWrt 路由器、ARM 边缘网关）上实现高并发流控，关键不是堆性能，而是压开销——$binary_remote_addr + limit_req_zone 正是为此设计的轻量原生方案。它不依赖外部组件，纯内存漏桶，单核百兆带宽下 CPU 占用常驻 1% 以内。

为什么 $binary_remote_addr 是低功耗场景的硬性选择

IPv4 地址被压缩为固定 4 字节、IPv6 为固定 16 字节二进制值，无字符串解析、无动态内存分配、无长度判断。相比 $remote_addr（平均占 32–40 字节/条），单 IP 状态元数据仅需约 12–16 字节，实测节省内存超 50%。这对 RAM 通常仅 512MB–2GB 的嵌入式设备，直接决定能否长期稳定运行。

• 哈希更紧凑：固定长度使哈希桶分布均匀，冲突率低，查找延迟稳定在纳秒级
• 无锁共享：所有 worker 进程复用同一块共享内存，避免原子操作和锁竞争带来的唤醒抖动
• CPU 友好：不触发字符串比较或 GC，减少 cache miss 和中断频率，利于低功耗待机维持

内存与速率配置必须“够用即止”

资源受限设备禁用“留余量”思维。zone 太大会浪费内存，太小则频繁淘汰导致限流失效；rate 太高会迫使 Nginx 毫秒级调度计时器，抬升 CPU 唤醒频次。

• 推荐配置：limit_req_zone $binary_remote_addr zone=lowpower:3m rate=5r/s;
• 3m 共享内存 ≈ 支持 4.8 万个活跃 IP，覆盖家庭 IoT、小型工控网等典型场景
• 5r/s 是平衡点：既能防基础探测和误触，又避免每秒上百次定时器 tick（rate＞20r/s 时唤醒压力显著上升）
• 慎用 burst：若加 burst=3，建议配 nodelay，否则排队会累积延迟并增加内存驻留时间

规避代理场景下的真实 IP 丢失问题

当设备前置了家用光猫、运营商 NAT 或简易 LB 时，$binary_remote_addr 默认取到的是上游内网地址（如 10.0.0.1），所有用户被捆进同一个计数器——等于完全失效。

• 必须启用 real_ip 模块，并只对可信内网段生效：
  set_real_ip_from 192.168.0.0/16;
  set_real_ip_from 10.0.0.0/8;
  real_ip_header X-Forwarded-For;
• 确保上游透传 X-Forwarded-For 且不可伪造（例如通过防火墙策略限制该头仅允许来自内网）
• 验证是否生效：临时加 log_format 观察 $remote_addr 是否已变为真实公网 IP（注意 $binary_remote_addr 本身不可打印，勿试图日志输出）

扩展建议：按路径分层，避免一刀切

单一 zone 承载全部流量，在低功耗设备上易成瓶颈。可结合 set + map 实现轻量分治：

• 对登录、提交等敏感接口单独设严控 zone：
  limit_req_zone $binary_remote_addr zone=auth:2m rate=3r/s;
• 静态资源或健康检查接口可放宽或跳过：
  set $limit_key "";
  limit_req zone=auth; # 空 key 不触发限流
• 用 map 提取子网前缀（如 /24），让同一局域网设备共享计数器，进一步压缩内存占用