淡于水处理 nginx 四层代理需求时，我遇到过最刁钻的一类场景：同一个公网 IP、同一个 443 端口，后端挂着好几套完全独立的 HTTPS 服务，流量必须按域名分发到不同的上游服务器，而且代理节点还不能参与 TLS 解密。nginx 自带的 ngx_stream_ssl_preread_module 模块就是为这个问题设计的——它在握手阶段只读取 SNI 字段，不终结连接，就能把原始 TCP 流按域名精准转发到对应的上游。这篇文章把我历次在生产环境验证过的原理、配置和排错要点完整写出来，适合负责接入层网关、负载均衡的运维同学，以及不满足于七层反代、想彻底搞明白四层转发的后端开发参考。
1. 需求场景：什么样的架构必须上四层域名分流
1.1 七层反向代理搞不定的三类流量
七层反代用 server_name 分流 HTTPS 请求是很成熟的方案，但它的前提是 nginx 必须终结 TLS：客户端先和 nginx 完成一次握手，nginx 再和后端做第二次握手，整个会话对中间节点是"看得见"的。这个模型在常规 Web 场景没什么问题，可一旦遇到下面三类流量就彻底失灵了。
第一类是非 HTTP 的 TLS 协议。PostgreSQL 的 SSL 端口、Redis 的 TLS 连接、各种 RPC 框架的私有协议、物联网设备的上报通道，这些流量对 nginx 的 http 模块来说就是一堆无法解析的二进制，七层的 location、proxy_pass 完全失效。stream 模块倒是能按 IP 和端口做四层转发，但如果这些服务都想共用 443，端口维度就分不开了，只能往 SNI 维度想办法。
第二类是安全要求高的内网链路。某些合规严格的业务场景明文要求链路里任何一跳都不能持有后端证书私钥，也不允许中间节点做重新加解密，代理只能做纯透传。七层方案在这里直接被否掉，因为终结 TLS 就意味着私钥必须暴露在代理节点上。
第三类是接入层资源紧张的场景。公网 IP 和端口是稀缺资源，几十个业务、几十个域名往往只挤在一两个入口上；后端各自独立部署，运维上又希望每个域名能单独路由到自己的集群，而不是所有流量混在一个池子里再靠应用层慢慢分。这种需求本质上是把"域名路由"从应用层下沉到了传输层。
上面三种情况指向的是同一个技术组合：四层转发加上 SNI 识别。
1.2 四层域名分流的设计思路
传统做法是每个后端单独分配一个公网 IP 加端口，前端按不同的地址访问。IP 资源充足时挺省心，可 IP 段枯竭、域名数量上去之后，成本高得离谱。用 ssl_preread 之后，所有 TLS 流量统一进一个 443 监听口，nginx 对每条新连接只做一次极短时间的"窥探"：拿到 ClientHello 里的域名，马上把这条 TCP 连接原样交给对应的 upstream，后续的 TLS 握手由客户端和后端直接完成，nginx 不再碰任何应用层数据。
这个方案最大的价值在于透明。后端证书、会话密钥、请求内容全程不过代理节点，代理只做路由决策。无论后端是 HTTP 服务还是私有协议，无论客户端用的是 TLS 1.2 还是 1.3，只要握手阶段带 SNI 就能被识别。对已经有七层反代体系的团队，四层和七层还可以共存：四层负责把不同域名的流量送进对应的七层 nginx 集群，七层再继续做路径路由和 SSL 卸载，各司其职。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 原理拆解：ssl_preread 是怎么"偷看"域名的
2.1 SNI 在 TLS 握手里为什么是明文
要理解这个模块，先得认识 TLS 握手的第一个数据包 ClientHello。客户端发起连接时，把这个数据包明文发给服务器，里面携带它支持的 TLS 版本、加密套件列表，还有一个可选的 server_name 扩展——也就是 SNI。SNI 的作用是告诉服务器"我想访问哪个域名"，让服务器能在同一个 IP 上挂多张证书，并据此选择证书和策略。
虽然 SNI 属于 TLS 协议的一部分，但设计上它必须出现在加密握手之前，否则服务器根本不知道用哪张证书来协商。换句话说，在一切加密动作发生之前，SNI 本身就注定是可见的。TLS 1.3 里提出的 ECH（Encrypted Client Hello）就是为了加密整个 ClientHello，但目前 ECH 仍处在逐步推广阶段，绝大多数客户端默认没有启用。所以在当下绝大多数真实流量里，SNI 依然是中间节点可以读取的信息。这不是漏洞，而是协议为"虚拟主机"场景留下的设计口子，nginx 正好用它做路由。
2.2 模块的工作机制与两个核心变量
ngx_stream_ssl_preread_module 做的事非常克制：在 stream 模块处理连接的 preread 阶段，把 ClientHello 数据读入内存，解析出 SNI 和协议版本，存入对应变量，然后立刻结束"窥探"，不往下走任何 TLS 状态机逻辑，连接随后进入正常的四层转发流程。正因为不保存 TLS 上下文、不占会话资源，它的性能开销极低，这也是它能扛住高并发的原因。
模块对外提供两个核心变量，配置里最常打交道的就是这两个：
| 变量 | 含义 | 典型值 |
|---|---|---|
$ssl_preread_server_name |
从 ClientHello 解析出的 SNI 域名 | www.example.com |
$ssl_preread_protocol |
客户端声明的 TLS 版本 | TLSv1.2 / TLSv1.3 |
实际配置里，承载路由逻辑的通常是 stream 块的 map 指令：把域名映射成一个自定义变量，再用这个变量作为 proxy_pass 的目标。map 会在连接建立时对 $ssl_preread_server_name 做查表，输出对应 upstream 池的名字，nginx 再根据这个名字完成转发。整个链路非常简洁：解析变量 → 查映射表 → 动态选定上游。
3. 环境准备：先把模块确认到位
3.1 一条命令确认模块是否存在
线上很多 nginx 是编译时静态编入模块的，不像 http 子模块那样能随意动态加载，所以第一步永远是确认当前二进制里到底有没有这个模块。执行：
bash复制nginx -V 2>&1 | tr ' ' '\n' | grep ssl_preread
有输出，说明编译参数里带了 --with-stream_ssl_preread_module；没输出，要么是 nginx 编译时没开 stream，要么是版本太老，需要重编。这个编译参数的名字多年来的确没有变过，网上查到的各种资料里写法基本一致，照着用不会踩坑。
3.2 源码编译的参数推荐
需要重编的话，我常用的完整参数如下：
bash复制./configure \
--prefix=/usr/local/nginx \
--with-stream \
--with-stream_ssl_module \
--with-stream_ssl_preread_module \
--with-http_ssl_module \
--with-http_v2_module \
--with-cc-opt='-O2 -g' \
--with-ld-opt='-Wl,-z,relro'
make -j4
make install
这里 --with-stream 是四层代理的基础，--with-stream_ssl_preread_module 是本次的主角。--with-stream_ssl_module 用于"代理到上游时主动发起 TLS 握手"的场景，如果你只需要纯透明转发可以不加，但我建议顺手编上，因为生产里经常会遇到后端本身就是 TLS 服务、需要代理层加密回源的情况，省得以后再重编一次。--with-http_ssl_module 和 --with-http_v2_module 是给同一台机器上的七层服务预留的，绝大多数公司一台 nginx 四层七层都会用，提前编进去没有坏处。
如果不走源码编译，Ubuntu 的 nginx-full、Rocky/AlmaLinux 官方源里的 nginx 也常带有该模块，但不同发行版构建配置差异很大，最终还是以 nginx -V 的输出为准。编译完再跑一遍确认命令，看到 --with-stream_ssl_preread_module 出现在输出里才算数。
4. 完整配置实操：单 IP 多域名四层分流
4.1 一套能直接上生产的最小配置
假设有三个后端业务：www.abc.com 对应两台 Web 服务器，api.abc.com 对应独立 API 集群，pay.xyz.com 对应支付网关；再留一个默认兜底池，处理未识别域名和非 TLS 流量。完整配置如下：
nginx复制stream {
map $ssl_preread_server_name $backend_pool {
default backend_default;
www.abc.com backend_web;
api.abc.com backend_api;
pay.xyz.com backend_pay;
~^(?i)def\.com$ backend_def;
}
upstream backend_web {
server 192.168.10.11:443;
server 192.168.10.12:443;
keepalive 32;
}
upstream backend_api {
server 192.168.10.21:443 max_fails=3 fail_timeout=10s;
}
upstream backend_pay {
server 192.168.10.31:443;
server 192.168.10.32:443 backup;
}
upstream backend_default {
server 127.0.0.1:8443;
}
server {
listen 443;
proxy_pass $backend_pool;
proxy_timeout 300s;
proxy_connect_timeout 5s;
}
}
这是最典型的 ssl_preread 用法。listen 443 监听所有进入的 TLS 流量，proxy_pass 的目标不是写死的 upstream 名，而是一个由 map 计算出来的变量。nginx 在每条新连接进入时先完成 preread，解析出 SNI，再根据 map 规则决定这条连接进入哪个 upstream 池。
4.2 配置细节逐行拆解
map 块是整个方案的"大脑"。default 那一行建议永远保留，它决定没有任何规则命中时的兜底行为。没有这行，未识别流量会被 nginx 按 map 未命中的空值处理，轻则转发失败，重则被硬塞到第一个 upstream 里造成莫名错乱。正则匹配用 ~ 开头，且要放在精确域名规则的后面——nginx 按顺序匹配 map 条目，正则如果写在前面，很容易把精确匹配也吞掉。
upstream 里是标准的四层配置，除了 server 地址，max_fails、fail_timeout、backup、down、weight 这些参数语义和 http 层一致。特别说一下 keepalive，这是 stream 模块里容易被忽略但收益极大的参数：四层上游连接的建立开销主要在网络往返，配置 keepalive 32 之后，nginx 与后端之间会维持一个空闲连接池，新来的客户端连接直接复用池里的连接，省掉一次 TCP 握手甚至 TLS 握手。注意 stream 模块的 keepalive 语义和 http 模块不完全一样，它表示每个 worker 进程里缓存的上游空闲连接数上限，所以实际空闲连接总量要乘以 worker 数量。
server 块里的 proxy_timeout 是"连接上没有数据读写"的空闲超时，不是总时长；proxy_connect_timeout 是建立上游连接的超时。这两个参数经常被误配，前者设太短会导致长连接被无故断开，后者设太长会让故障上游拖垮所有新连接。我一般把 proxy_timeout 对齐业务心跳周期设到 300s 左右，connect timeout 保持 5s 以内。
4.3 进阶玩法：协议判断、透传客户端 IP、混合接入
只按域名分流还不够，这个模块能给接入层带来更细的控制力。
先看协议判断。$ssl_preread_protocol 可以做简单的 TLS 版本路由，比如把老版本 TLS 客户端导向兼容集群：
nginx复制map $ssl_preread_protocol $backend_legacy {
default backend_new;
"TLSv1.1" backend_legacy;
"TLSv1.0" backend_legacy;
}
再看客户端 IP 透传。四层转发之后，上游看到的源地址是代理节点的出口 IP，真实客户端 IP 丢失。解决办法是启用 PROXY protocol：server 块加 proxy_protocol on，后端（通常是另一台 nginx 或 haproxy）开启对应的 proxy_protocol 解析，就能拿到完整客户端信息。这套机制在私有协议服务上实现成本比七层的 X-Forwarded-For 高，但审计需求严格的场景很值。
最后说混合接入。我在生产里常把四层分流节点的一部分 upstream 指向另一台七层 nginx 集群的 443 端口。四层只做"域名到集群"的粗粒度路由，七层继续做细粒度路径路由和 SSL 卸载，整个接入层的弹性会强很多，扩容时只需要改 map 表加几条映射。
5. 联调测试：验证分流是否真的生效
5.1 用 openssl 直接看 SNI 解析结果
配置写完别急着上业务，先用 openssl 验证分流逻辑：
bash复制openssl s_client -connect 192.168.1.100:443 -servername www.abc.com -brief
这条命令模拟一个携带 www.abc.com SNI 的 TLS 客户端。如果配置生效、后端证书链没问题，输出里会显示握手成功，证书的 CN/SAN 与 www.abc.com 匹配。如果证书是另一套后端的，说明 map 规则写错，流量没进对的池子。-brief 模式输出精简，适合快速人工核对。
再测未在 map 里登记的域名：
bash复制openssl s_client -connect 192.168.1.100:443 -servername unknown.test.com -brief
预期是流量进入 default 池。这里有个容易忽略的坑：有些客户端直接用 IP 访问、不携带 SNI，此时 $ssl_preread_server_name 是空字符串，同样走 default。老手机、低版本 curl、部分监控探针都可能出现这种情况，排查时要想到这一层。
5.2 用真实请求和日志做端到端验证
openssl 只能验证握手层，业务层用 curl 更直观：
bash复制curl -sk --resolve www.abc.com:443:192.168.1.100 https://www.abc.com/api/health
--resolve 参数强制域名解析到指定 IP，测试机上不用改 hosts 就能模拟真实域名访问。如果后端是七层 nginx，看后端的 access log 里实际到达的请求；如果后端是私有协议，就在上游节点抓包确认源 IP 来自代理节点。
更推荐的方式是给 stream server 单独开一份 access log，把 SNI 打出来：
nginx复制log_format streamlog '$remote_addr $time_iso8601 $ssl_preread_server_name -> $backend_pool';
access_log /var/log/nginx/stream_access.log streamlog;
这份日志跑上几个月就是域名流量的分布图，之后值班排查哪个域名的流量异常会非常省事。我就是靠这份日志发现了某个域名一直被刷健康检查、全部命中 default 池的问题，比在七层查日志快得多。
6. 常见问题与排错实录
6.1 非 TLS 流量怎么办
总有流量不是 TLS，比如 TCP 健康检查、监控探活、或客户端配错端口直接发明文 HTTP。这类流量没有 ClientHello，preread 阶段解析不出 SNI 变量为空，最终落进 default 池。如果 default 池正好是个 HTTP 服务，明文流量反而会被正常响应，很多人因此误判配置没问题。
我的做法是把 default 池指向一个专门的"黑洞"地址，配合监控告警，把异常探针和协议错误暴露出来。千万别把 default 指向某个真实业务，否则所有未知流量都会被偷偷送进业务集群，统计数据全被污染。
6.2 分流失效、全进同一个上游的三种原因
这类问题我排查过很多次，原因基本就三种。
第一种是 proxy_pass 写成了静态 upstream 名，比如 proxy_pass backend_web，那所有域名都会进 backend_web。必须写成 proxy_pass $backend_pool 这样的 map 变量，nginx 才会在每条连接上动态计算目标。
第二种是 map 作用域放错位置。map 定义在 http 块里，stream 块引用不到对应变量，nginx 启动时直接报错。map 必须放在使用它的 stream 块内，或者 http 块和 stream 块各自定义一份同名 map。
第三种是小写化问题。SNI 里的域名理论上是大小写不敏感的，但总有客户端会传 SoMe.Domain.Com 这种形式，map 精确匹配区分大小写，会直接失配落到 default。稳妥做法是 map 规则用全小写域名，再加一条不区分大小写的正则兜底：~^(?i)some\.domain\.com$，实测能覆盖绝大多数异常客户端。
6.3 性能与连接复用建议
四层代理的最大优势是开销低，但配置不当照样会拖垮性能。最常见的坑是 upstream 里没配 keepalive，高并发下每条新连接都要重建上游 TCP 连接，加上 TLS 握手消耗的 CPU 和时延，代理节点很快就成了瓶颈。我在 4.2 里强调过 keepalive 的收益，这里再重复一遍：这是四层高并发场景下性价比最高的一项配置。
另一个坑是盲目调大 proxy_buffer_size。解析 SNI 只需要 ClientHello，一般 2KB 以内完全够用，保持默认值就行。每连接预分配大块内存，worker 的 RSS 会涨得很夸张，纯属给自己找麻烦。
还有人问四层连接能不能做限速限流。stream 模块同样支持 limit_conn、limit_rate，写在 stream 块里，配合按域名分流的 map，可以实现"每个域名不同限速策略"。但要注意 limit_conn 依赖共享内存 zone，必须显式配置 zone 名称和大小，否则多个 worker 各自独立计数，完全限不住。我最初就在这上面吃过亏，日志显示连接数明显超了，限流却没触发，就是没配 zone。
这套方案我在生产环境已经跑过好几轮，最大的体会有三点。第一，map 的 default 分支是整条链路的保险丝，没有它，所有未知流量都会变成难以定位的"幽灵请求"；第二，map 表改动本身就是热更新，不会断连接，但正则规则一旦写错会让大量域名意外落进 default 池，上线前务必拿真实域名逐个跑一遍 openssl 验证；第三，监控不能只盯代理节点的 CPU 和带宽，stream access log 里的 SNI 分布才是判断分流质量的第一手数据。后续如果再扩展，可以在现有基础上叠加 PROXY protocol 透传、按域名的限速策略，甚至把 map 表外置到配置中心做动态下发，四层网关就能逐渐长成一套完整的接入层组件。