1. 为什么需要四层代理你可能已经熟悉Nginx作为HTTP反向代理的用法但它的能力远不止于此。当我们需要代理MySQL、Redis或游戏服务器这类非HTTP协议时传统的七层代理就力不从心了。这就是四层代理的用武之地——它工作在传输层直接处理TCP/UDP数据流不关心应用层协议内容。我遇到过这样一个实际场景某电商平台需要将Redis请求均匀分发到多个节点。最初他们尝试用HTTP代理结果发现性能低下且经常超时。改用Nginx的Stream模块后不仅吞吐量提升了3倍还能自动剔除故障节点。这种透明管道的特性正是四层代理的核心价值。与LVS等方案相比Nginx Stream的优势在于配置灵活支持轮询、哈希、最小连接等多种算法精细控制可设置超时时间、重试策略等参数易扩展与现有Nginx生态无缝集成2. Stream模块核心配置详解2.1 基础模块结构要让Nginx支持TCP/UDP代理首先确认编译时包含--with-stream参数。配置文件通常分为三个部分worker_processes 4; events { worker_connections 8192; } stream { upstream db_cluster { server 10.0.0.1:3306; server 10.0.0.2:3306; } server { listen 3306; proxy_pass db_cluster; } }关键点在于stream块与http块是平级关系。我曾见过有人错误地将stream配置嵌套在http块内导致配置完全不生效。2.2 负载均衡算法选择根据业务特点选择合适算法轮询默认适合各节点性能均衡的场景哈希需要会话保持时使用如hash $remote_addr最小连接处理长连接服务的利器用least_conn开启实测发现在WebSocket服务中使用最小连接算法能有效避免某些节点过载的情况。3. 高可用性实战技巧3.1 健康检查机制Nginx提供被动式健康检查通过以下参数控制server 10.0.0.1:3306 max_fails3 fail_timeout30s;这个配置意味着30秒内失败3次就将节点标记为不可用30秒后再重新尝试。我在生产环境中发现对于数据库类服务适当延长fail_timeout能避免因网络抖动导致的误判。3.2 连接保持优化TCP长连接需要特别注意proxy_timeout 1h; proxy_socket_keepalive on;配合系统内核参数调整sysctl -w net.ipv4.tcp_keepalive_time600 sysctl -w net.ipv4.tcp_keepalive_intvl30曾经有个游戏服务器项目因为没设置keepalive导致玩家频繁掉线。加入这些配置后连接稳定性显著提升。4. 常见问题排查指南4.1 连接超时问题如果遇到connection timeout错误检查这些参数proxy_connect_timeout建议设置为5-10秒proxy_timeout根据业务特点调整proxy_next_upstream确保开启容错机制4.2 性能调优建议对于高并发场景增加worker_processes和worker_connections调整worker_rlimit_nofile限制考虑使用reuseport选项提升性能server { listen 3306 reuseport; # ... }在某个日活百万的社交App中启用reuseport后QPS提升了约15%。5. 典型应用场景配置5.1 MySQL读写分离stream { upstream mysql_read { server read1.example.com:3306; server read2.example.com:3306; } upstream mysql_write { server master.example.com:3306; } server { listen 3306; proxy_pass mysql_write; } server { listen 3307; proxy_pass mysql_read; } }5.2 Redis集群代理upstream redis_nodes { hash $remote_addr consistent; server 192.168.1.10:6379; server 192.168.1.11:6379; }使用一致性哈希可以最大限度减少缓存失效。有个电商项目迁移到这种架构后缓存命中率从82%提升到了97%。6. 安全加固建议6.1 访问控制列表server { listen 3306; allow 10.0.0.0/24; deny all; proxy_pass db_cluster; }6.2 SSL终端代理server { listen 443 ssl; proxy_pass backend; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; }在金融行业项目中这种配置既保证了传输安全又避免了每个后端节点单独配置证书的麻烦。
