在现代网络架构中，TLS 加密传输已成为保障数据安全的基础设施。然而，许多遗留应用或内部服务本身并不支持 TLS 协议，直接将这些服务暴露在公网中会带来严重的安全风险。stunnel 正是为解决这一问题而设计的工具 —— 它作为 TLS 代理，可以在不修改原有程序代码的情况下，为任意 TCP 服务添加加密传输能力。本文将从配置模式与性能调优两个维度，探讨如何高效使用 stunnel 搭建生产级别的 TLS 隧道。
stunnel 的核心设计理念与适用场景
stunnel 由 Michał Trojnara 开发，采用 GNU GPL v2 许可证发布，其核心设计目标是为现有的客户端和服务器透明地添加 TLS 加密功能，而无需对原有程序的源代码进行任何修改。这种设计理念使得 stunnel 成为一个极其灵活的通用 TLS 代理工具。
从架构层面来看，stunnel 工作在应用层与传输层之间，扮演着 TLS 卸载与负载均衡的双重角色。当客户端连接到配置了 stunnel 的服务端口时，stunnel 会首先与客户端建立 TLS 连接，完成加密握手后，再将解密后的原始流量转发给后端服务；反之亦然。这种双向代理机制使得 stunnel 可以灵活部署在网络边界、DMZ 区域，甚至是容器化环境中。
stunnel 的典型应用场景包括以下几类：第一，为内部数据库、缓存服务、消息队列等非加密服务提供安全访问入口；第二，在微服务架构中实现服务间的 TLS 加密通信，而无需修改每个服务的代码；第三，作为 TLS 卸载网关，将后端服务的计算压力转移到专门的加密层；第四，穿越不安全的网络环境，建立加密的隧道通道。理解这些场景有助于我们在实际项目中准确判断何时应该引入 stunnel，以及如何规划其部署拓扑。
基础配置结构与全局参数设置
stunnel 的配置文件采用 INI 格式，结构清晰，主要分为全局配置段和服务配置段两大部分。全局配置段用于设置影响整个进程的参数，如进程管理、日志级别、动态库路径等；服务配置段则定义具体的代理规则，每条规则对应一个监听端口及其对应的转发目标。
在全局配置中，首先需要关注的是 pid 文件与 foreground 模式的选择。对于守护进程部署，指定 pid 文件路径是必要的，这便于系统管理工具监控和管理 stunnel 进程的生命周期。其次是日志配置，stunnel 支持 syslog 和文件两种日志输出方式，生产环境建议将日志级别设置为 notice 或 info，既能捕获关键事件，又不会产生过多的调试信息影响磁盘空间。
pid = /var/run/stunnel.pid
foreground = no
debug = 4
syslog = yes
socket 层参数是影响性能的关键全局配置项。RDC（Reuse Data Connection）选项控制是否复用底层 TCP 连接，对于高并发场景，开启此选项可以显著减少 TCP 握手开销。TCP_NODELAY 选项禁用 Nagle 算法，消除数据发送的延迟，对于需要低延迟的交互式服务尤为重要。需要注意的是，这两个选项需要在 connect 指令中为每个服务单独配置，而 accept 端的连接复用则在全局范围内生效。
线程模型方面，stunnel 5.71+ 版本引入了基于线程池的并发处理机制，通过 thread 参数可以指定处理连接的线程数量。在多核服务器上，适当增加线程数可以充分利用 CPU 资源，但过多的线程反而会增加上下文切换开销。对于一般的代理场景，建议将线程数设置为 CPU 核心数的 50% 到 100% 之间，并通过实际压测来确定最优值。
服务级配置：accept 与 connect 的组合模式
服务配置段是 stunnel 功能的核心所在，每条服务配置都以方括号括起的服务名开头，后跟一系列指令。最核心的指令是 accept 和 connect，前者指定 stunnel 监听客户端连接的地址和端口，后者指定转发目标服务器的地址和端口。
最基础的代理模式是标准端口转发。例如，将本地的 443 端口收到的 TLS 流量解密后转发到后端的 80 端口：
[http-to-https]
accept = 0.0.0.0:443
connect = 127.0.0.1:80
cert = /etc/stunnel/server.crt
key = /etc/stunnel/server.key
在上述配置中，stunnel 扮演的是 TLS 服务器角色，接收客户端的加密连接，然后以明文方式连接后端 HTTP 服务。这种模式常用于为内部 Web 应用提供 HTTPS 入口，stunnel 承担 TLS 卸载职责，后端服务无需任何加密相关代码。
反过来，当需要让不支持 TLS 的客户端访问远端的 TLS 服务时，可以启用 client 模式：
[client-mode]
accept = 127.0.0.1:8080
connect = remote.server.com:443
client = yes
此时 stunnel 作为 TLS 客户端，与远程服务器建立加密连接，而本地客户端则以明文方式连接 stunnel。这种模式适用于穿越防火墙、访问内部 API 网关等场景。
更复杂的场景是双向 TLS 认证。通过 verify 参数可以要求对端提供证书并进行验证：
[mutual-tls]
accept = 0.0.0.0:443
connect = 10.0.0.5:8443
cert = /etc/stunnel/client.crt
key = /etc/stunnel/client.key
CAfile = /etc/stunnel/ca.crt
verify = 2
verify = 2 表示要求对端提供证书并验证其是否由指定的 CA 签发，这是金融、医疗等强监管行业的常见配置要求。
性能优化：从瓶颈定位到参数调优
根据 stunnel 官方性能测试数据，在 Intel Core i5-3570K 单核环境下，使用 ECDHE-RSA-AES128-GCM-SHA256 加密套件可达到 688 MB/s（约 5.5 Gbit/s）的吞吐量。然而，在实际生产环境中，由于网络条件、服务器配置、应用负载等因素的综合影响，性能往往会低于这个理论值。2025 年 6 月的社区补丁讨论显示，通过优化 I/O 处理逻辑，stunnel 性能可进一步提升约 17%。
性能瓶颈通常集中在三个层面：网络 I/O、加密计算和内存复制。针对网络 I/O 的优化，首先应调整 socket 缓冲区大小。stunnel 默认的接收和发送缓冲区可能无法充分利用高带宽网络，在 10Gbit/s 以上的网络中，建议将缓冲区大小设置为 64KB 到 256KB 之间：
[high-throughput]
accept = 0.0.0.0:443
connect = 10.0.0.100:80
receive buffer = 131072
send buffer = 131072
加密计算层面的优化主要依赖合适的加密套件选择。在安全性满足要求的前提下，优先使用支持硬件加速的 AES-GCM 系列套件。TLS 1.3 相比 TLS 1.2 减少了握手往返次数，引入 0-RTT 模式，对于频繁建立的短连接场景有明显性能优势。配置示例：
sslVersion = TLSv1.3
ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
options = NO_SSLv2:NO_SSLv3:NO_TLSv1:NO_TLSv1.1
内存复制是常被忽视的性能瓶颈。stunnel 在内部需要在加密层和明文层之间进行数据拷贝，频繁的小数据包会导致大量的内存分配和释放操作。根据社区的性能分析，通过启用预分配缓冲区和减少动态内存操作，可以有效降低 CPU 在这一环节的消耗。
连接管理参数的调优同样关键。会话恢复（Session Resumption）机制允许客户端复用之前的 TLS 会话状态，避免完整的握手过程，这对于高频率短连接的场景意义重大。配置方法如下：
session = 300
options = SESSION_RESUME
session 参数设置会话缓存的生存时间（秒），options = SESSION_RESUME 启用会话恢复功能。根据测试数据，启用会话恢复后，新连接处理能力可以从每秒 750 个提升到 4700 个，提升超过 6 倍。
高并发场景下的系统资源规划
在需要处理大量并发连接的场景中，系统资源的规划直接决定了 stunnel 的承载能力。根据官方文档，在 Unix 平台上，处理 N 个并发连接需要将文件描述符限制（ulimit -n）设置为高于 2*N，同时用户进程限制（ulimit -u）需要高于 N。这是因为每个连接需要两个文件描述符（一个用于 accept 端，一个用于 connect 端），而每个线程本身也是一个进程。
内存消耗是另一个需要关注的资源维度。stunnel 的内存占用由基础常量和连接增量两部分组成：基础 RSS（Resident Set Size）约为 5 MB，每个并发连接额外消耗约 60 KB。因此，在规划 10000 个并发连接时，需要预留约 600 MB 的内存空间用于 stunnel 进程。
线程模型的选择需要根据业务特点来决定。对于 I/O 密集型的代理场景，单线程事件驱动模型可能已经足够；但如果后端服务处理较慢，导致连接保持时间较长，多线程模型可以更好地利用多核 CPU。stunnel 5.71+ 版本的线程池实现采用工作窃取（Work Stealing）算法，能够在保持低内存开销的同时实现高效的负载均衡。
对于极端高并发场景，可以考虑在前端部署负载均衡器，将流量分散到多个 stunnel 实例。stunnel 本身支持通过 redirect 指令实现简单的健康检查和故障转移，但更复杂的负载均衡策略通常需要借助 L4 或 L7 负载均衡器来实现。
监控指标与健康检查
生产环境中，完善的监控体系是保障服务稳定运行的基础。stunnel 提供了多种方式暴露运行状态信息，便于接入监控系统。
进程级别的监控可以通过信号机制获取。例如，向 stunnel 进程发送 USR1 信号会在日志中输出当前的连接统计信息，包括活跃连接数、连接建立速率、字节传输量等。这些数据可以定期采集并绘制趋势图，用于容量规划和异常检测。
更细粒度的监控需要结合外部工具。使用 ss -tan 或 netstat -an 命令可以查看 stunnel 当前维持的连接状态；配合 iostat、sar 等系统工具可以监控网络带宽利用率和系统负载。当发现性能下降时，这些数据可以帮助快速定位瓶颈所在。
健康检查是保障服务可用性的关键环节。对于部署在反向代理后面的 stunnel 实例，建议配置主动健康探测，定期检查 accept 端口的可达性。对于客户端模式的配置，可以通过 checkHost 和 checkPort 参数在连接建立时验证后端服务的可用性，避免将流量转发到已经宕机的后端。
实践建议与配置模板
综合以上分析，这里给出一个面向生产环境的完整配置模板，涵盖安全加固、性能优化和可维护性等多个方面：
; 全局配置
pid = /var/run/stunnel.pid
foreground = no
syslog = yes
debug = 4
; 性能相关全局参数
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
; 服务配置
[https-proxy]
accept = 0.0.0.0:443
connect = 127.0.0.1:8080
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key
CAfile = /etc/stunnel/ca.crt
verify = 2
; 性能优化
sslVersion = TLSv1.3
ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
options = NO_SSLv2:NO_SSLv3:NO_TLSv1:NO_TLSv1.1:SESSION_RESUME
; 连接管理
session = 300
TIMEOUTclose = 0
TIMEOUTconnect = 10
TIMEOUTidle = 43200
; 负载均衡与健康检查
redirect = 10.0.0.20:8443 ; 故障转移目标
在实际部署中，建议从测试环境开始逐步调优，收集基准性能数据后再应用于生产环境。同时，保持对 stunnel 社区的关注，及时获取性能改进和安全补丁。
资料来源：stunnel 官方网站（https://www.stunnel.org）、stunnel-users 邮件列表性能优化讨论（2025 年 6 月）。