Nginx反向代理HTTPS服务报错排查：The plain HTTP request was sent to HTTPS port-育师

1. 问题现场：一个看似简单却令人困惑的报错

最近在给一个内部服务配置Nginx反向代理，让它通过HTTPS对外提供服务时，遇到了一个经典的报错：The plain HTTP request was sent to HTTPS port。这个错误信息直译过来就是“一个明文的HTTP请求被发送到了HTTPS端口”。乍一看，这似乎是个低级错误——客户端用HTTP协议去访问一个配置了SSL的HTTPS端口（通常是443）。但实际情况往往更微妙，尤其是在反向代理的场景下，你明明在浏览器里输入的是https://yourdomain.com，Nginx日志里却固执地报出这个错，让人一时摸不着头脑。

这个问题的核心，其实不在于客户端直接发错了协议，而在于请求在到达你配置的Nginxserver块之前，其协议特征可能就已经“丢失”或“错位”了。对于运维和开发来说，这不仅仅是一个配置错误，更是一个理解Nginx请求处理流程、SSL终止位置以及代理行为的好机会。如果你也正在被这个报错困扰，或者想深入理解Nginx在代理HTTPS上游服务时的内部机制，那么接下来的内容会带你一步步拆解问题，从现象到根因，再到多种场景下的解决方案。

2. 深入理解报错：Nginx的“协议感知”与端口监听

要解决问题，首先得明白Nginx为什么会发出这样的抱怨。这需要我们从Nginx监听端口和处理请求的基本逻辑说起。

2.1 SSL/TLS握手与协议识别

当一个客户端（比如浏览器）尝试与服务器建立HTTPS连接时，会发生一个叫做TLS握手的过程。在这个握手的最初阶段，客户端会发送一个ClientHello消息，这个消息本身是明文的，但它包含了一个关键信息：它打算使用TLS协议。服务器在收到这个ClientHello后，才会开始进行密钥交换等后续加密步骤。

Nginx的listen指令在配置了ssl参数后（例如listen 443 ssl;），它就会在指定的端口（这里是443）上期待这种TLS握手的发生。它会在TCP连接建立后，立即尝试读取并解析ClientHello。如果它收到的第一个数据包不符合TLS握手的格式，Nginx就会认为这是一个普通的、未加密的HTTP请求，于是抛出了The plain HTTP request was sent to HTTPS port这个错误。

2.2 反向代理场景下的复杂性

在简单的静态网站服务中，这个错误通常意味着客户端真的用http://访问了https://的地址。但在反向代理场景下，情况就复杂了。你的Nginx可能同时监听80和443端口，负责将请求转发给后端的应用服务器（比如运行在8080端口的Tomcat，或者另一个HTTP服务）。

这里的关键在于代理链。你的Nginx作为边缘服务器，终止了来自客户端的HTTPS连接（即解密了数据）。然后，它需要创建一个新的请求发送给后端服务器。这个新请求使用什么协议，完全由Nginx的proxy_pass指令所在location块的配置决定，与客户端最初的协议无关。

最常见的错误配置模式是这样的：

server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { # 错误配置：直接使用http://指向后端 proxy_pass http://backend_server:8080; 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; # 这个头很重要 } }

这个配置看起来没问题，Nginx确实在443端口终止了SSL。但是，如果后端服务器backend_server:8080自己也配置了SSL，期待一个HTTPS请求，那么问题就来了。Nginx使用http://协议发过去一个明文HTTP请求，后端服务器如果在8080端口也期待TLS握手，就会拒绝这个请求。然而，这个拒绝信息在传递回Nginx时，可能被转换或丢失，最终在Nginx的错误日志中呈现为开头的那个报错，因为它发生在Nginx自己的443端口监听逻辑里。

另一种情况是，你可能在同一个server块里混合了带ssl和不带ssl的listen指令，或者配置了错误的default_server，导致流量被错误的服务器块处理。

3. 核心排查链路：从日志到配置的逐层验证

当遇到这个报错时，不要急于修改配置，先按照一个清晰的排查链路来定位问题。盲目修改往往会让问题更复杂。

3.1 第一步：检查Nginx错误日志与访问日志

日志是定位问题的第一现场。你需要同时查看错误日志（error_log）和访问日志（access_log），并且确保日志级别足够详细（例如error_log /var/log/nginx/error.log debug;在排查时临时开启debug级别，事后记得改回）。

在错误日志中：找到报错The plain HTTP request was sent to HTTPS port的那一行。注意看它前面的连接标识（如client: 192.168.1.100）和时间戳。
在访问日志中：根据时间戳和客户端IP，找到对应的访问记录。重点看几个字段：
- $request：记录的是完整的请求行，例如GET /api/data HTTP/1.1。这里显示的是Nginx最终处理请求时认定的协议。如果这里显示HTTP/1.1而不是HTTPS，那说明在Nginx看来，这个请求就是HTTP。
- $scheme：这个变量代表请求使用的协议（http或https）。在proxy_set_header中我们常用$scheme来告诉后端请求最初的协议。但在访问日志里，它反映的是Nginx处理时的协议判断。
- $ssl_protocol：如果这个字段是空的，那就证实了Nginx没有在这个连接上检测到SSL握手。

注意：临时修改日志级别和格式可以获取更多信息。你可以在http块或server块中自定义一个日志格式，包含更多变量，例如：
log_format debug_log '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $scheme $ssl_protocol $server_port'; access_log /var/log/nginx/debug_access.log debug_log;

3.2 第二步：验证Nginx配置语法与加载

在修改任何配置之前，先用nginx -t命令测试配置文件的语法是否正确。这个命令会检查语法，并告诉你配置文件路径。确保你修改的是Nginx真正加载的那个配置文件。

有时候，问题可能出在配置片段（include的文件）或者多个配置文件冲突上。使用nginx -T可以打印出Nginx实际加载的所有配置，方便你全局搜索listen、ssl和proxy_pass指令。

3.3 第三步：分析完整的请求路径

根据日志，画出请求的完整路径：

客户端 -> (HTTPS) -> Nginx 443端口。
Nginx 解密 -> 根据server_name和location匹配，决定转发。
Nginx -> (???) -> 后端服务器。

你需要明确第3步中，Nginx到底用了什么协议、什么端口去连接后端。使用proxy_pass http://backend:port就是HTTP，使用proxy_pass https://backend:port就是HTTPS。这里的一个微小差别就是问题的根源。

3.4 第四步：检查后端服务状态与期望

如果怀疑是后端服务的问题，直接绕过Nginx测试后端。如果后端服务监听8080，你可以用curl命令测试：

# 测试后端是否响应HTTP curl -v http://backend_server_ip:8080/health # 如果后端期待HTTPS，尝试（假设后端有自签名证书） curl -vk https://backend_server_ip:8443/health

通过curl的详细输出(-v)，你可以看到完整的HTTP请求和响应头，以及SSL握手情况。如果后端只接受HTTPS，而你用HTTP去访问，后端通常会返回一个400 Bad Request或者直接关闭连接。

4. 解决方案大全：针对不同场景的修复策略

找到了问题根源，解决方案就清晰了。以下是针对不同场景的配置修正方法。

4.1 场景一：Nginx代理HTTP后端，但客户端误访问

这是最单纯的情况。你的Nginx配置了SSL，代理到一个HTTP后端，但用户或者某个爬虫直接用http://访问了你的443端口。

解决方案：在监听443端口的server块中，配置一个重定向，将所有HTTP请求重定向到HTTPS。但注意，对于已经到达443端口的明文HTTP请求，Nginx会先报错，然后才能处理重定向指令。因此，更常见的做法是在监听80端口的server块中做重定向。

# 监听80端口的server块，处理所有HTTP请求 server { listen 80; server_name example.com www.example.com; # 永久重定向到HTTPS return 301 https://$server_name$request_uri; } # 监听443端口的server块，处理所有HTTPS请求 server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://backend_server:8080; # 代理到HTTP后端 ... # 其他proxy_set_header配置 } }

4.2 场景二：Nginx需要代理到HTTPS后端（上游服务自带SSL）

这是导致开头报错的最常见、也最隐蔽的场景。你的后端服务（例如一个Java应用使用Spring Boot内置的HTTPS，或者另一个Nginx）自己就提供了HTTPS端点。

错误配置：

proxy_pass http://secure-backend:8443;

正确配置：

proxy_pass https://secure-backend:8443;

仅仅是把http://改成https://吗？还不够。当你使用proxy_pass https://...时，Nginx需要与后端建立一个新的HTTPS连接，这意味着它需要验证后端服务器的证书。

location / { proxy_pass https://secure-backend:8443; # 关键的头信息传递 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; # 告诉后端最初的协议是https # HTTPS代理特有的配置 proxy_ssl_verify on; # 验证后端证书（生产环境建议开启） proxy_ssl_verify_depth 2; proxy_ssl_trusted_certificate /path/to/trusted_ca_certs.pem; # 信任的CA证书 proxy_ssl_certificate /path/to/client_cert.pem; # 如果后端需要客户端证书 proxy_ssl_certificate_key /path/to/client_cert.key; proxy_ssl_name $proxy_host; # 用于SNI，通常设为$proxy_host proxy_ssl_server_name on; # 启用SNI proxy_ssl_protocols TLSv1.2 TLSv1.3; # 指定协议版本 proxy_ssl_ciphers HIGH:!aNULL:!MD5; # 指定加密套件 }

实操心得：在内网环境中，后端可能使用自签名证书。这时你需要将后端证书的CA或证书本身添加到proxy_ssl_trusted_certificate，并将proxy_ssl_verify设置为off（仅限测试环境）。否则，Nginx会因证书验证失败而无法连接到后端，错误日志中会出现SSL_do_handshake() failed等相关错误，这可能与最初的报错不同，但根本原因相关。

4.3 场景三：混合监听与默认服务器冲突

如果你的Nginx配置了多个server块，并且使用了default_server参数，或者80和443端口的配置不匹配，可能导致流量被错误的server块处理。

# 错误示例：模糊的默认服务器 server { listen 80 default_server; listen 443 ssl default_server; # 443也设置了default_server server_name _; # 这个块可能会捕获所有未知域名的443请求，如果没配ssl，就会报错 return 444; # 或者一些其他处理 } server { listen 443 ssl; server_name example.com; # 正确的配置 }

解决方案：明确每个server块的server_name，谨慎使用default_server。确保监听443端口的server块都正确配置了ssl参数和证书。对于不需要处理HTTPS的default_server，只监听80端口。

4.4 场景四：使用stream模块进行TCP/UDP代理

如果你使用Nginx的stream模块进行四层代理（例如代理数据库端口或某些非HTTP协议），那么stream块内的配置不涉及HTTP/HTTPS协议，也就不会出现这个错误。这个错误是http模块特有的。确保你没有错误地将HTTP代理的配置（proxy_pass http://...）放在了本应使用四层代理的地方。

5. 进阶排查与相关陷阱

即使按照上述方案修改了，问题可能依然存在，或者以其他形式出现。这里有几个更深层次的排查点和常见陷阱。

5.1 检查防火墙与负载均衡器

在企业网络中，Nginx前面可能还有一层负载均衡器（如F5, AWS ALB/NLB）或防火墙。这些设备可能会进行SSL卸载（Termination），然后将解密后的HTTP流量转发给后端的Nginx。如果它们配置错误，比如将HTTPS流量解密后，却仍然用TCP模式转发到Nginx的443端口，那么Nginx在443端口收到的就是明文HTTP流量，从而触发报错。

如何排查：查看Nginx访问日志中的$remote_addr。如果这个IP不是你客户端的公网IP，而是某个内网IP（如10.x.x.x, 172.x.x.x），那么流量很可能经过了中间设备。你需要联系网络团队，确认负载均衡器的监听器（Listener）配置是否正确，确保它要么将HTTPS流量透传（TCP Passthrough）到Nginx，要么在SSL卸载后，将流量转发到Nginx的80端口（或其他非SSL端口）。

5.2 HTTP/2与协议升级

现代浏览器和Nginx都支持HTTP/2 over HTTPS (h2)。虽然这通常不会直接导致该错误，但在一些边缘情况下，如果客户端尝试在明文HTTP连接上发起HTTP/2连接，或者配置混乱，也可能引发问题。确保你的SSL配置支持现代协议，并且没有错误地配置了http2指令在非SSL的listen上。

5.3 代理头信息传递的重要性

头信息X-Forwarded-Proto对于后端应用至关重要。许多Web框架（如Spring Boot, Django, Express）依赖这个头来判断原始请求是否通过HTTPS访问，从而正确地生成重定向URL或设置安全cookie。如果这个头传递错误（比如传成了http），即使前端是HTTPS，后端也可能错误地生成一个HTTP的URL，导致客户端又去发起HTTP请求，形成循环或错误。

在你的location块中，确保设置了：

proxy_set_header X-Forwarded-Proto $scheme;

并且在后端应用中，配置为信任这个头（例如Spring Boot的server.forward-headers-strategy=native或使用X-Forwarded-Proto过滤器）。

5.4 Docker与容器网络中的特殊问题

在Docker环境中运行Nginx时，网络拓扑变得更加复杂。一个常见的错误是：在Docker Compose中，Nginx容器通过服务名（如app:8080）代理到应用容器，但应用容器内部只暴露了HTTP端口。然而，如果你在Nginx配置中错误地将服务名映射到了一个外部定义的、带HTTPS的域名上，就会出问题。

确保你的Docker网络内通信使用正确的协议和端口。通常，容器间通信使用HTTP即可，SSL在边缘的Nginx容器终止。检查Nginx容器中proxy_pass指令指向的地址和端口，是否确实是后端应用容器暴露的端口。

6. 一个完整的配置示例与调试流程

让我们通过一个完整的例子，串联起配置、测试和调试的全过程。

目标：将域名api.example.com的HTTPS流量，通过Nginx反向代理到内网一个运行在https://192.168.1.10:9443上的Spring Boot应用（自带SSL，使用自签名证书）。

步骤1：准备证书将Spring Boot应用的自签名证书（或其CA证书）拷贝到Nginx服务器上，例如/etc/nginx/ssl/backend-ca.crt。

步骤2：编写Nginx配置

# /etc/nginx/conf.d/api-proxy.conf upstream backend_https { # 如果后端是集群，可以在这里定义多个server server 192.168.1.10:9443; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name api.example.com; # 边缘Nginx自己的SSL证书（由公共CA签发） ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem; # 强化SSL配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512; ssl_prefer_server_ciphers off; location / { # 关键：使用https://协议连接后端 proxy_pass https://backend_https; # 传递必要的头信息 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; # 传递原始协议为https # 配置与后端HTTPS连接的参数 proxy_ssl_verify off; # 因为后端是自签名证书，临时关闭验证（生产环境应配置信任证书） # proxy_ssl_trusted_certificate /etc/nginx/ssl/backend-ca.crt; # proxy_ssl_verify on; proxy_ssl_name $proxy_host; proxy_ssl_server_name on; # 超时设置 proxy_connect_timeout 75s; proxy_send_timeout 3600s; proxy_read_timeout 3600s; } } # HTTP重定向 server { listen 80; listen [::]:80; server_name api.example.com; return 301 https://$server_name$request_uri; }

步骤3：测试与调试

语法检查：sudo nginx -t
重载配置：sudo nginx -s reload
从外部测试：curl -v https://api.example.com/actuator/health
查看Nginx日志：
- tail -f /var/log/nginx/error.log
- tail -f /var/log/nginx/access.log(使用包含$scheme和$ssl_protocol的日志格式)
直接测试后端：在Nginx服务器上，curl -vk https://192.168.1.10:9443/actuator/health，确认后端服务本身是可用的。
检查连接：如果还有问题，可以在Nginx服务器上用tcpdump抓包，分析Nginx与后端服务器192.168.1.10:9443之间的通信，看TCP连接是否建立，是否有TLS握手。