基于nginx构建的集群流量分发与审计系统，依托upstream实现带健康检查的负载均衡，通过结构化日志（含$request_id、$upstream_addr等）支撑审计溯源，结合openresty的lua扩展实现实时风控与脱敏，并对接elk完成分析告警与合规归档。
构建基于 Nginx 的集群流量分发与审计系统，核心是利用 Nginx 的反向代理、负载均衡能力完成流量分发，再通过日志增强、模块扩展和外部系统联动实现可追溯、可分析的审计能力。它不依赖商业网关，但需要在配置严谨性、日志结构化和数据流转环节下功夫。
用 upstream 实现稳定流量分发
Nginx 自带的 upstream 模块是流量分发的基础。需避免轮询（round-robin）单点失效风险，优先采用带健康检查的策略：
- 配置
health_check（需启用ngx_http_upstream_health_check_module，或使用 OpenResty 内置模块），每 3 秒探测后端 HTTP 状态码 - 使用
least_conn或ip_hash（会话保持场景）替代默认轮询，减少连接倾斜 - 为每个 server 设置
max_fails=2 fail_timeout=30s，防止短暂异常导致节点被长期剔除 - 若后端支持 gRPC，可用
grpc_pass替代proxy_pass，保持协议一致性
结构化日志用于审计溯源
默认 access_log 仅记录基础字段，审计需补充请求上下文。关键做法是重定义 log_format：
- 加入
$request_id（需在 server 块中用random_index或lua-resty-random生成唯一 ID）作为全链路追踪标识 - 添加
$upstream_addr和$upstream_status，明确记录实际转发目标及响应状态 - 通过
map指令提取敏感行为，例如：map $request_uri $is_admin_path { ~^/admin/ 1; default 0; }
再将$is_admin_path写入日志，便于后续筛选高危路径访问 - 日志输出建议转至 syslog 或 stdout（配合容器环境），由 Fluentd / Filebeat 统一采集，避免本地磁盘写入瓶颈
用 Lua 扩展实时审计能力
纯配置难以满足动态审计逻辑（如风控规则、黑白名单、响应体扫描），OpenResty 是成熟选择：
- 在
access_by_lua_block中调用 Redis 查询 IP 实时黑名单，命中则直接ngx.exit(403) - 用
body_filter_by_lua_block对响应体做轻量级检测（如含 “password” 字段则打标并记入审计日志） - 结合
log_by_lua_block将关键字段（如 user_id 从 header 提取、响应耗时、客户端 ASN）补全到日志行，避免后期解析开销 - 注意 Lua 代码需做异常捕获，防止因脚本错误导致整个请求失败
对接审计平台形成闭环
日志只是原始数据，需接入分析系统才能发挥审计价值：
- 将结构化日志推送至 Elasticsearch + Kibana，建立索引模板时对
request_id、upstream_addr、is_admin_path等字段设为 keyword 类型，支持精确过滤 - 用 Logstash 或自研服务消费日志流，识别高频失败请求、异常 UA、非工作时间登录等模式，触发企业微信/钉钉告警
- 对含 PII（如身份证号、手机号）的请求，可在 Lua 层做正则脱敏后再写日志，满足合规要求
- 定期归档原始日志至对象存储（如 S3、MinIO），保留 180 天以上，供事后取证
