Linux怎么配置Nginx Stream模块 Nginx四层负载均衡详解

先明确一个核心概念：Nginx的Stream模块，本质上是一个四层（传输层）的袋里和负载均衡器。它不解析HTTP协议，只做最原始的TCP/UDP数据流透传。这意味着，它的配置逻辑和常见的HTTP模块有根本性的区别，很多“想当然”的配置都会直接导致服务无法启动。

首先，Stream模块必须显式启用，否则所有相关配置都会被Nginx直接拒绝。这通常不是语法错误，而是模块压根就不存在于你的Nginx二进制文件中。

确认Nginx是否带stream模块

最直接的验证方法是运行命令：nginx -V 2>&1 | grep -o with-stream。如果没有任何输出，那就说明当前安装的Nginx不支持Stream模块。

这里有个常见的坑：很多Linux发行版提供的默认Nginx包，为了保持轻量，默认是不包含Stream模块的。

• Ubuntu/Debian：别装nginx-light或nginx-core，它们通常不含Stream。你需要安装nginx-extras这个包。
• CentOS/RHEL 8+：可以通过dnf install nginx-mod-stream来安装模块，但务必注意模块版本要与Nginx主程序严格匹配，否则可能无法加载。
• 最稳妥的方式：从源码编译，在./configure阶段加上--with-stream参数，然后执行make && sudo make install。

如果你在配置文件中写了stream指令，却看到nginx: [emerg] unknown directive "stream"这个错误，别怀疑自己的语法，问题九成出在模块缺失上。

stream块必须放在顶层，不能嵌套在http里

这是结构上的硬性规定。stream和http是Nginx配置中两个平级的顶级块，它们必须并列出现在events块之后。如果你把stream {}写进了http {}的内部，Nginx会毫不客气地报错："stream" directive is not allowed here。

正确的配置结构应该是这样的：

events {
    worker_connections 1024;
}

stream {
    upstream db_cluster {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }
    server {
        listen 3306;
        proxy_pass db_cluster;
    }
}

http {
    # 其他HTTP配置
}

stream模块只支持有限指令，不兼容HTTP语义

由于Stream模块工作在四层，它无法理解HTTP协议的任何语义。因此，一大批在HTTP配置中习以为常的指令，在这里完全不可用。

• HTTP层指令全部失效：比如rewrite、proxy_set_header、return、location等。一旦使用，立刻就是unknown directive错误。
• proxy_pass格式固定：它通常只接受IP:PORT格式。如果想使用域名，必须在stream块内先配置resolver指令来指定DNS服务器。
• UDP需要特殊声明：袋里UDP协议（如DNS）时，必须在listen后加上udp标记，例如listen 53 udp;，并且通常需要配合设置proxy_responses和proxy_timeout。
• TLS路由靠“偷看”：如果想根据TLS握手信息（SNI）做路由，可以启用ssl_preread on;，然后通过变量$ssl_preread_server_name获取域名。但注意，它只读取握手包头部，不进行完整的TLS解密和应用层解析。

监听低端口需root权限，且proxy_timeout影响连接生命周期

如果你需要袋里SSH(22)、FTP(21)等低端口服务，Nginx的主进程（master process）必须以root权限启动（worker进程可以降权运行）。否则会报错：bind() to 0.0.0.0:22 failed (13: Permission denied)。

proxy_timeout这个指令控制的是空闲连接的超时时间，默认是60秒。对于数据库这类需要长连接的场景，往往需要将其调大，比如设为proxy_timeout 1h;。但这里有个平衡：如果设置得过大，在短连接频繁的场景下，可能导致大量已关闭的连接迟迟不被释放，最终耗尽服务器的文件描述符。

最后，也是最关键的一个限制：Stream模块没有内置的健康检查自动剔除机制。在HTTP模块中，我们可以用max_fails和fail_timeout让Nginx自动将失败的后端服务器临时摘除。但在Stream模块中，max_fails仅对TCP连接建立失败（connect失败）有效。如果后端服务器进程还在，但应用层服务已经卡死或无响应，Stream模块是完全感知不到的，连接依然会被转发过去，导致业务故障。

这意味着，在生产环境中使用Nginx做四层负载均衡，你必须依赖外部的服务探活（Health Check）机制或主动监控系统来发现故障节点，并通过动态更新Upstream配置等方式进行补位，否则无法保证高可用性。