Nginx Stream 模块仅做 TCP/UDP 透明转发，安全依赖边界控制、连接加固与链路加密协同；需配置 TLS 透传、来源限制、连接优化，并配合后端自身安全机制。
Nginx Stream 模块本身不解析应用层协议（如 MySQL、Redis、RDP），它只做 TCP/UDP 层的透明转发，因此安全性不来自协议解析，而来自边界控制、连接加固与链路加密的协同设计。真正起作用的是配置策略，而非模块自动防护。
启用 TLS 加密透传，防止明文窃听
Stream 支持监听 SSL 端口并透传加密流量，但需注意：它不终止也不验证证书——只是把客户端和后端之间的 TLS 流量原样转发。
- 若后端服务（如 MySQL）已启用 SSL，Nginx 只需开启
listen 3307 ssl并配置自己的证书（用于客户端到 Nginx 这一段加密）； - 客户端必须强制使用加密连接，例如 MySQL 加上
--ssl-mode=REQUIRED； - 避免混用明文与加密端口，否则攻击者可能降级到非加密通道。
限制访问来源，缩小暴露面
Stream 块内不支持 allow/deny 指令，但可通过以下方式实现有效过滤：
- 在系统层面配置
iptables或nftables，仅放行可信 IP 段（如办公网段192.168.10.0/24）； - 使用
map指令做粗粒度判断，例如拒绝已知恶意 ASN 的连接； - 为 SSH/RDP 等协议监听非标准端口（如
11682代替22），降低被自动化扫描命中的概率。
优化连接行为，防范协议层干扰
四层代理若超时或中断不当，会直接导致业务连接失败：
- 设置合理超时：
proxy_timeout 1h（RDP/SSH 空闲时间长，不宜设太短）； - 对 RDP 启用
hash $remote_addr consistent，保证同一客户端始终路由到同一后端，避免会话中断； - 添加
proxy_responses 1提升多轮握手协议（如 RDP）的首次连接成功率。
配合上游服务自身安全机制
Stream 是“管道”，不是“守门员”。真正的身份校验和加密必须由后端承担：
- MySQL 需设置
require_secure_transport = ON，并配好ssl_ca、ssl_cert、ssl_key； - Redis 应启用
requirepass+ TLS（6.0+ 支持原生 TLS）； - RDP 仍需 Windows 网络级身份验证（NLA），Nginx 不替代该能力。
不复杂但容易忽略
