nginx 不支持按单个 udp 会话总数限流，因其无连接状态；但可通过 preread_by_lua_block + 共享字典实现五元组级包数计数（如100包后丢弃），配合 proxy_timeout 控制会话窗口，并建议业务层加 token 提升可靠性。
Nginx 没有 proxy_requests 指令，也不支持按“单个 UDP 会话请求数”做硬性总数限制（比如“每个 UDP 连接最多发 100 个包就断开”）。这是由 UDP 协议本质和 Nginx stream 模块设计决定的。
你提到的场景——“限制单个 UDP 会话在断开前的请求总数”——听起来像 TCP 的连接级计数（如 max_requests），但 UDP 没有连接状态、没有显式建立/关闭过程，Nginx 无法天然识别“一个会话从哪开始、到哪结束”。
不过，你可以通过组合策略近似实现行为约束，核心思路是：利用五元组 + 时间窗口 + 预读逻辑 + 自定义拦截，把“会话生命周期”人工锚定下来。
以下是可行且生产可用的方案：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
H3：靠 preread_by_lua_block 拦截并标记首次包
Nginx stream 模块的 preread_by_lua_block 是唯一能在 UDP 数据到达时、转发前执行逻辑的地方。它能读取客户端 IP 和端口，并写入共享字典（shared dict）做轻量计数。
stream {
lua_shared_dict udp_session_counter 10m;
server {
listen 1994 udp;
preread_by_lua_block {
local ip = ngx.var.remote_addr
local port = ngx.var.remote_port
local key = ip .. ":" .. port
local dict = ngx.shared.udp_session_counter
local count, err = dict:get(key)
if not count then
-- 首次包：初始化为 1，设置 30 秒过期（模拟“会话活跃期”）
dict:set(key, 1, 30)
return
end
if count >= 100 then -- 达到总数上限
ngx.log(ngx.ERR, "UDP session ", key, " exceeded 100 packets")
return ngx.exit(444) -- 关闭连接（UDP 下即丢弃后续包）
end
dict:incr(key, 1)
}
proxy_pass 127.0.0.1:1995;
}
}
H3：用 proxy_timeout 控制会话“存活窗口”
虽然 UDP 无连接，但 Nginx 为每个五元组维护一个临时会话上下文（用于复用后端连接等）。proxy_timeout 决定了这个上下文空闲多久后被清理。
- 设为
proxy_timeout 5s;→ 若客户端 5 秒内没再发包，Nginx 就认为该“会话”已结束，共享字典中对应 key 会自然过期（配合上面dict:set(..., 30)的 TTL 更稳妥）。 - 这样，“100 包限制”只在连续活跃的短周期内生效，避免长期占用内存。
H3：注意真实限制边界与替代建议
- ❌ Nginx 无法区分“同一个应用进程发的多个 UDP 包”和“不同进程伪造相同五元组的包”。IP+端口可被复用或伪造，这不是强会话标识。
- ✅ 更可靠的替代是：在业务层加会话 ID（如首包带 token 或 session_id 字段），用 Lua 解析并计数，比依赖端口更可控。
- ✅ 如果目标是防滥用（如 DNS 查询洪泛），直接用
limit_req基于$binary_remote_addr限速更简单高效，无需模拟会话。
H3：为什么不能用 limit_req_zone 直接限制“每个会话”
因为 limit_req_zone 的 key 必须是变量（如 $binary_remote_addr），而它不支持动态构造带端口的复合 key 并自动绑定生命周期。你没法告诉 Nginx：“对 ip:port 这个组合，只在它首次出现后的 60 秒内累计到 100 就封禁”。
所以，真要总数控制，必须用 Lua 手动管理状态——这也是 OpenResty 生态下处理 UDP 会话级策略的标准做法。
不复杂但容易忽略：共享字典需预分配足够空间，且 dict:incr 是原子操作，多 worker 安全。
