Nginx仅作无状态日志流转发，不参与聚合；真正聚合须由Kafka+Flink、Loki+Promtail等专用组件完成，stream模块应配置hash一致性分发、proxy_responses 1（UDP）及合理超时以保障有序低丢包转发。
直接用 Nginx 做日志聚合是走偏了方向。Nginx 本身不解析、不存储、不格式化日志，它在高可用集群里只该做一件事：把原始日志流快速、稳定、有序地转发出去。真正的聚合工作必须交给后端专用组件。
明确 Nginx 的角色边界
Nginx（配合 stream 模块）本质是无状态流量调度器，不是日志处理器：
- 它不读取日志内容，不识别 JSON 或 Syslog 结构，不做过滤或字段提取
- 它只按连接、IP 或会话哈希做 TCP/UDP 层转发，延迟低、吞吐高
- 所有“聚合”动作——去重、时间对齐、字段合并、指标计算——都应由 Kafka + Flink、Loki + Promtail、Vector 或自研接收服务完成
用 stream 模块做可靠分发，避免乱序和丢包
在 nginx.conf 顶层配置 stream 块，不进 http 块：
- UDP 日志必须设 proxy_responses 1，否则部分 syslog 客户端因收不到响应而反复重发
- 顺序敏感场景禁用轮询（round-robin），改用 hash $remote_addr consistent，确保同一设备日志始终打到同一后端节点
- 设置合理超时：
proxy_timeout 1s（UDP）或proxy_timeout 3s（TCP），防止僵死连接占资源
Keepalived 保障入口不中断，但不解决聚合逻辑
VIP 漂移只管“谁能收”，不管“怎么合”：
- 主 Nginx 故障时，VIP 秒级切到备机，客户端无感知继续发日志
- 但后端聚合系统（如 Kafka 集群）需自行实现消费者组重平衡、offset 管理、exactly-once 语义
- 别指望 Keepalived 自动同步 Nginx 的连接状态或 session 信息——它没这个能力
真正聚合环节的衔接建议
让 Nginx 分发与后端聚合解耦，提升可维护性：
- 若后端是 Kafka：Nginx 不直连 Kafka broker（协议不兼容），中间加一层 Vector 或 Fluentd，负责协议转换与缓冲
- 若需 TLS 加密：Nginx stream 启用 ssl_preread，透传 SNI，后端按域名路由到不同解析集群
- 加轻量健康检查：在 upstream 中配
max_fails=3 fail_timeout=30s，自动摘除挂掉的接收节点，避免日志堆积
