排查Nginx Stream模块四层转发异常需按“模块可用→配置合规→连接通路→日志状态”分层验证：先用nginx -V确认with-stream启用，再确保stream块与http平级且仅含proxy_pass等合法指令，接着用nc/ss实测后端连通性与监听状态，最后结合error_log中errno（如111、110、104）和stream日志分析根因。
排查 Nginx stream 模块四层转发异常，核心是分层验证：先确认模块可用，再检查配置结构，接着验证连接通路，最后分析日志与状态。不是一上来就改参数，而是按“能不能用→配得对不对→连不连得上→为什么断得快”顺序推进。
确认 stream 模块已真正启用
报 unknown directive "stream" 或配置不生效，90% 是模块没加载成功：
- 运行 nginx -V 2>&1 | grep with-stream，有输出才表示编译时支持；若无，需重装含 stream 的包（如 Ubuntu 装
nginx-extras，CentOS 安装nginx-mod-stream） - 动态模块需显式加载：在
nginx.conf最顶部（events同级）加 load_module modules/ngx_stream_core_module.so;，路径要和nginx -V显示的 modules 目录一致 -
nginx -t通过 ≠ 模块已启用，必须看到with-stream才算真正就位
检查 stream 配置位置与语法合规性
stream 块不能嵌套，也不支持 http 模块指令：
- 必须与
http块平级，写在nginx.conf顶层作用域，结构为：stream { ... }；写在http { stream { } }内会直接报错 - 只允许使用
upstream、server、proxy_pass、proxy_timeout等极少数指令；location、rewrite、client_max_body_size等七层指令在 stream 中无效且会触发语法错误 - 建议用
include /etc/nginx/stream-enabled/*.conf;分离配置，避免主配置臃肿
实测 TCP 连通性与后端监听状态
不要依赖 Nginx 日志做唯一判断，必须在 Nginx 本机动手验证：
- 用 nc -zv 后端IP 端口 或 telnet 后端IP 端口 测试能否建连；超时说明链路中断、防火墙拦截或目标未监听
- 执行 ss -tlnp | grep :端口，确认后端进程是否真正在监听，注意 bind 地址是
0.0.0.0还是127.0.0.1（后者本地可连，Nginx 从外网连不上） - 若 upstream 使用域名，运行 nslookup 域名 和 dig +short 域名，确认 DNS 解析稳定且返回预期 IP；云环境还需查安全组出方向规则、目标组健康检查状态
分析 error_log 错误码与连接行为
日志里的 errno 是关键线索，结合连接数分布快速定位根因：
- 关注
error_log中高频出现的系统错误：Connection refused (111) → 后端没启；Connection timed out (110) → 网络丢包或 SYN 被静默丢弃；Connection reset by peer (104) → 后端主动断连（如 Redis 关闭空闲连接）；Cannot assign requested address (99) → 本地临时端口耗尽 - 启用 stream 日志，添加 log_format stream_log '$remote_addr:$remote_port -> $upstream_addr [$time_local]';，观察请求是否集中打到某台后端
- 在各后端执行 ss -tn state established | grep :端口 | wc -l，对比 ESTABLISHED 连接数；若某节点远高于其他，检查其应用是否线程阻塞或连接池满
