1. 问题现场一次典型的SSL握手失败排查那天下午监控系统突然报警一个核心业务接口的响应时间曲线拉成了一条直线紧接着错误率飙升。登录服务器一看Nginx错误日志里刷满了同一行刺眼的记录peer closed connection in SSL handshake while SSL handshaking to upstream。这个错误对于使用Nginx作为反向代理并且后端服务upstream启用了HTTPS的场景来说堪称“经典款”故障。它直白地告诉你Nginx代理服务器试图与后端服务器建立安全的SSL/TLS连接时握手过程被对方peer无情地中断了。表面看是连接问题背后却可能藏着证书、协议、配置乃至网络层面的各种“暗礁”。对于运维和开发来说这不仅仅是一个错误日志更是一道需要综合排查的调试题。2. 核心原理SSL/TLS握手与Nginx代理的角色要解决这个问题我们必须先理解Nginx在这个架构中扮演的角色以及SSL握手是如何进行的。在一个典型的HTTPS反向代理场景中数据流经历了两次加密解密过程客户端到Nginx第一层HTTPS外部用户浏览器或客户端与Nginx服务器建立HTTPS连接。此时Nginx出示自己的SSL证书完成与客户端的握手。对于客户端而言Nginx就是终点站。Nginx到后端服务器第二层HTTPSNginx作为代理需要将请求转发给真正的后端服务如Tomcat、Node.js、另一个Nginx等。如果后端服务也要求HTTPS即proxy_pass指向https://开头的地址那么Nginx就需要扮演“客户端”的角色与后端服务建立一个新的、独立的HTTPS连接。peer closed connection in SSL handshake这个错误就发生在这第二次握手的过程中。这个过程的简化时序如下Nginx作为客户端向配置的后端服务器地址发起TCP连接。TCP连接建立后Nginx发送Client Hello消息开始SSL/TLS握手。后端服务器应回复Server Hello并发送其服务器证书。随后进行密钥交换等步骤最终完成握手建立加密信道。错误信息中的“peer closed connection”意味着后端服务器在收到Client Hello后或者在发送Server Hello及证书的过程中主动关闭了TCP连接导致握手失败。这通常是因为后端服务器对Nginx发起的握手请求“不满意”从而拒绝服务。3. 根因分析与系统性排查清单导致后端服务器拒绝握手的原因多种多样我们可以按照从外到内、从简到繁的顺序进行系统性排查。以下是一个高效的排查路径3.1 第一步基础网络与可达性检查在怀疑复杂的SSL配置之前先确保最基础的通信是正常的。网络连通性从Nginx服务器使用telnet或nc命令测试是否能连接到后端服务器的HTTPS端口通常是443。telnet upstream_ip 443如果能连接成功看到空白屏幕或光标闪烁说明TCP层是通的。后端服务状态确认后端服务进程是否在正常运行并且监听在正确的IP和端口上。使用netstat -tlnp或ss -tlnp命令查看。防火墙与安全组检查Nginx服务器与后端服务器之间的防火墙如iptables, firewalld以及云服务商的安全组规则确保443端口的入站和出站流量都是允许的。注意有时候后端服务器可能只监听在127.0.0.1或某个内网IP上而Nginx配置中使用的却是域名或另一个IP这会导致连接失败。确保Nginx的proxy_pass地址与后端服务实际监听的地址一致。3.2 第二步SSL证书与域名验证问题这是最常见的一类原因。当Nginx作为客户端连接上游时它会验证上游服务器的证书。证书是否有效后端服务器使用的SSL证书可能已过期、是自签名的、或者证书链不完整。Nginx默认会验证这些。域名不匹配Nginx通过proxy_pass中配置的域名或IP去连接后端但后端服务器证书中的Common Name (CN)或Subject Alternative Name (SAN)字段不包含这个域名或IP。例如你用proxy_pass https://backend.internal.company.com;但后端证书是为backend.service.com签发的。Nginx的SSL验证配置查看Nginx配置中proxy_ssl_verify和proxy_ssl_trusted_certificate等指令。排查命令我们可以模拟Nginx的行为使用openssl命令来诊断openssl s_client -connect upstream_host:upstream_port -servername upstream_host例如openssl s_client -connect 10.0.1.5:443 -servername backend.internal.company.com仔细查看命令输出重点关注Verify return code:是否为0成功。如果是其他数字如21说明验证失败。证书的颁发者和有效期。证书的Subject和Subject Alternative Name是否包含你连接时使用的主机名。3.3 第三步TLS协议版本与加密套件不匹配Nginx客户端和后端服务器服务端支持的TLS协议版本如TLSv1.2, TLSv1.3和加密套件列表可能没有交集。Nginx配置通过proxy_ssl_protocols指令指定了过高的协议版本如只允许TLSv1.3而后端服务器只支持到TLSv1.2。后端服务配置后端服务如旧版本的Java应用服务器可能只支持老旧的协议如SSLv3, TLSv1.0而现代Nginx默认已禁用这些不安全的协议。加密套件通过proxy_ssl_ciphers指令指定的加密套件后端服务器都不支持。排查命令使用openssl指定协议版本来测试openssl s_client -connect upstream_host:upstream_port -tls1_2 # 测试TLS 1.2 openssl s_client -connect upstream_host:upstream_port -tls1_3 # 测试TLS 1.3如果某个版本能连接成功而另一个失败就指明了问题方向。也可以使用nmap进行更详细的扫描nmap --script ssl-enum-ciphers -p 443 upstream_host。3.4 第四步Nginx代理配置细节深挖Nginx中与上游SSL连接相关的配置指令非常关键一个参数不对就可能导致握手失败。proxy_ssl_verify如果设置为on默认值Nginx会验证上游服务器的证书。如果上游是自签名证书或内部证书且未正确配置信任链就会失败。临时排查时可以将其设为off来快速定位是否是证书验证问题。生产环境慎用仅作调试。proxy_ssl_trusted_certificate当proxy_ssl_verify为on时需要指定一个包含受信任CA证书的文件用于验证上游证书。如果上游使用私有CA或自签名证书必须将对应的CA证书或自签名证书本身放入此文件。proxy_ssl_name这个指令至关重要它指定了Nginx在SSL握手时发送的SNI (Server Name Indication)扩展字段。对于现代服务器如果证书托管了多个域名多域名证书或通配符证书服务器需要根据SNI来决定返回哪个证书。如果proxy_ssl_name没有设置或者设置的值与证书域名不匹配服务器可能返回一个默认的、不匹配的证书导致验证失败。通常它应该设置为proxy_pass中域名对应的那个主机名。proxy_ssl_server_name控制是否启用SNI默认为off。对于绝大多数需要域名验证的现代HTTPS服务必须将其设置为on。proxy_ssl_certificate和proxy_ssl_certificate_key如果你的后端服务要求客户端此处是Nginx也提供证书双向TLS/mTLS那么你需要配置这两个指令。大多数内部服务不需要这个。3.5 第五步后端服务器自身日志与限制不要只盯着Nginx看后端服务器的日志往往包含拒绝连接的直接原因。查看后端应用日志登录后端服务器查看其应用日志如Tomcat的catalina.out, Spring Boot的日志文件。里面可能会有更详细的错误信息例如“收到不支持的协议版本”、“无法验证客户端证书”如果是双向TLS、“主机名不匹配”等。后端服务器的SSL配置检查后端服务器自身的SSL/TLS配置。例如Tomcat的server.xml中Connector的sslProtocol、ciphers等参数Nginx作为后端时的ssl_protocols、ssl_ciphers。连接数或速率限制后端服务器可能设置了单IP连接数限制而Nginx代理服务器的IP恰好触发了这个限制。4. 实战配置修复与示例假设我们有一个内部服务backend-app运行在https://backend.internal:8443使用内部私有CA签发的证书。Nginx配置最初可能是这样的upstream backend { server backend.internal:8443; } server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/example.com.crt; ssl_certificate_key /path/to/example.com.key; location /api/ { proxy_pass https://backend; # 这里指向upstream但upstream定义的是backend.internal:8443 proxy_set_header Host $host; # 缺少关键的proxy_ssl_*配置 } }这个配置几乎必然导致peer closed connection in SSL handshake错误。修复后的配置如下upstream backend { # 通常 upstream 块用于负载均衡对于简单的单个后端直接在 proxy_pass 中写全URL更方便。 # 但为了示例清晰我们保留upstream。 server backend.internal:8443; } server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/example.com.crt; ssl_certificate_key /path/to/example.com.key; location /api/ { proxy_pass https://backend; # 重要设置上游SSL连接的主机名用于SNI和证书验证 proxy_ssl_name backend.internal; # 启用SNI proxy_ssl_server_name on; # 验证上游服务器证书安全做法 proxy_ssl_verify on; # 指定信任的CA证书文件里面需要包含签发 backend.internal 证书的私有CA证书 proxy_ssl_trusted_certificate /path/to/internal-ca-bundle.crt; # 设置验证深度 proxy_ssl_verify_depth 2; # 指定支持的协议和加密套件可选通常用系统默认值即可除非有兼容性问题 proxy_ssl_protocols TLSv1.2 TLSv1.3; # proxy_ssl_ciphers HIGH:!aNULL:!MD5; # 传递必要的头部 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }关键修复点解释proxy_ssl_name backend.internal;明确告诉Nginx在向上游握手时声称自己是backend.internal。这决定了SNI字段和证书验证时预期的主机名。proxy_ssl_server_name on;显式启用SNI扩展这对于现代TLS服务是必须的。proxy_ssl_verify on;与proxy_ssl_trusted_certificate开启了证书验证并提供了正确的信任链。你需要将签发backend.internal证书的CA证书或该证书本身如果是自签名添加到internal-ca-bundle.crt文件中。proxy_ssl_protocols明确协议版本避免因默认协议列表不一致导致的不兼容。实操心得在调试阶段一个非常有效的“二分法”是先将proxy_ssl_verify设置为off并注释掉proxy_ssl_trusted_certificate。如果错误消失那么问题100%出在证书验证环节证书无效、域名不匹配、缺少信任链。如果错误依旧那么问题更可能出在协议/套件不匹配或SNI未设置上。5. 高级场景与疑难杂症5.1 场景后端服务监听在本地环回地址有时后端服务如一个开发中的API只监听在127.0.0.1:8443。Nginx在同一台机器上但proxy_pass https://127.0.0.1:8443;依然报错。这可能是因为证书的SAN里没有127.0.0.1或localhost。某些应用对来自环回地址的HTTPS连接有特殊处理。解决方案为本地开发生成包含127.0.0.1和localhost的SAN证书。或者在测试时让后端服务监听在0.0.0.0所有接口并使用主机名或局域网IP访问并确保证书匹配。更粗暴的测试方式在Nginx配置中对这个特定的后端关闭SSL验证proxy_ssl_verify off并禁用SNIproxy_ssl_server_name off但这仅限临时调试。5.2 场景使用Docker容器或Kubernetes在容器化环境中服务名Service Name被用作主机名。例如在K8s中proxy_pass https://my-service.namespace.svc.cluster.local:443;。问题Pod内的证书通常是为Service名签发的如my-service.namespace.svc.cluster.local但Nginx容器内可能没有配置对应的DNS解析或者SNI设置不正确。解决方案确保Nginx Pod的/etc/resolv.conf正确能解析K8s内部域名。在Nginx配置中proxy_ssl_name必须设置为完整的Service域名。将K8s内部CA的证书挂载到Nginx容器中并配置proxy_ssl_trusted_certificate指向它。5.3 场景后端服务器要求严格的Cipher Suite某些安全要求极高的后端服务可能只允许少数几个强加密套件。如果Nginx默认的或配置的套件列表与之不匹配握手也会失败。排查与解决从后端服务器管理员那里获取其允许的加密套件列表。在Nginx的proxy_ssl_ciphers指令中精确配置与之匹配的套件。例如proxy_ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;使用openssl s_client -cipher参数测试特定套件是否可行。6. 问题排查速查表与命令总结当peer closed connection in SSL handshake错误再次出现时你可以按照下表快速定位排查方向关键检查点常用命令/方法网络与可达性端口是否开放服务是否监听telnet/nc host port,netstat -tlnp,curl -v https://...直连后端证书验证证书有效性、域名匹配、信任链openssl s_client -connect ... -servername ...查看返回码和证书信息协议/套件兼容TLS版本、加密套件是否匹配openssl s_client -connect ... -tls1_2,nmap --script ssl-enum-ciphersNginx配置proxy_ssl_verify,proxy_ssl_name,proxy_ssl_server_name检查nginx.conf相关指令特别是SNI和验证设置后端日志后端应用自身的错误信息直接登录后端服务器查看应用日志文件临时调试快速隔离证书验证问题在Nginx配置中设置proxy_ssl_verify off;和proxy_ssl_server_name off;调试完务必改回一套组合诊断命令# 1. 测试基础TCP连接 nc -zv backend.internal 8443 # 2. 模拟Nginx进行完整的SSL握手和证书验证 openssl s_client -connect backend.internal:8443 \ -servername backend.internal \ -CAfile /path/to/internal-ca-bundle.crt \ -tls1_2 # 3. 如果openssl连接成功但Nginx失败检查Nginx配置细节 # 4. 如果openssl也失败根据其输出错误信息verify error, handshake failure等深入排查处理这类问题的核心思路是“分而治之”先确保物理连接畅通然后模拟客户端Nginx的行为去测试SSL握手对比成功和失败时配置的差异最后结合两端日志进行精准定位。每一次对这类错误的成功排查都会让你对HTTPS协议栈和Nginx的代理机制有更深一层的理解。