提问人：Pavel 提问时间：11/11/2018 更新时间：6/17/2022 访问量：55577
Nginx 上游到 https 主机 - ssl3_get_record：版本号错误
Nginx upstream to https host - ssl3_get_record:wrong version number
问：
我正在尝试将请求代理到远程服务器，这就是我配置 Nginx 的方式
upstream myupstream {
server remote-hostname;
}
...
location ~ ^/(v1|v2|v3)/.*$ {
proxy_pass https://myupstream;
# also tried these options:
# proxy_ssl_server_name on;
# proxy_ssl_verify off;
# proxy_set_header Host <remote-hostname-here>;
# proxy_set_header X_FORWARDED_PROTO https;
}
结果，我在错误.log中看到错误502页面和此记录
2018/11/10 19:41:38 [error] 8410#8410: *1 SSL_do_handshake() failed
(SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number)
while SSL handshaking to upstream, client: 127.0.0.1, server: <my-web-host-here>,
request: "GET /v1/some/page HTTP/1.1",
upstream: "https://<my-web-host-ip-here>:80/v1/some/page",
host: "<my-web-host-here>"
是什么原因导致的？
注意：这个 nginx 代理在我的本地机器上。
答：
20赞
Steffen Ullrich
11/11/2018
#1
upstream: "https://<my-web-host-ip-here>:80/v1/some/page",
我不太清楚你想达到什么目的。但是，您不太可能在端口 80 上拥有 HTTPS 服务器。端口 80 通常由 HTTP 而不是 HTTPS 使用。尝试通过 HTTPS 访问它通常会导致服务器发出 HTTP 错误响应，当将其解释为预期的 TLS 握手响应时，将导致奇怪的错误消息，例如 .ssl3_get_record:wrong version number
评论
5赞
Pavel
11/11/2018
谢谢伙计！我在上游配置中添加了端口，并解决了您提出的问题！我以为既然我已经指定了，就足以让 Nginx 找出正确的端口，但显然情况并非如此，我没有在日志条目中注意到该端口。所以非常感谢你，好渔获！server remote-hostname:443;https://proxy_pass https://myupstream;80
0赞
Marc
3/15/2019
谢谢你！当端口可以而且应该从协议（即 HTTPS 的 443）中推断出来时，您必须指定一个端口是多么荒谬，而该协议在此处未指定，但在 中未指定。upstreamlocation
1赞
Steffen Ullrich
3/15/2019
@Marc：在此指令的上下文中定义服务器，目前尚不清楚稍后将在哪个上下文（http vs https）中使用。虽然定义的每个服务器仍然需要一个端口，但由于上下文是已知的，因此它不能具有适合所有情况的默认值。目前，默认情况下，该端口被明确记录为 80，从本文档中可以看出。是的，如果内部工作是未知的，这是出乎意料的，但我不会说它很荒谬，因为它很清楚为什么它以这种方式工作。upstream
0赞
Marc
3/19/2019
奇怪的东西总是有原因的，结果是你绕过它并最终得到不优雅的代码/配置（如本例）。这并不意味着像我这样脾气暴躁的人不能咆哮。我看不出任何原因，当未指定端口时，它不能像网络上的标准那样默认为 443 的 HTTPS。不中断任何内容，节省重复配置。
21赞
Jinlxz Liu
9/26/2021
#2
我也遇到了这个问题，花了 2 天时间才解决。
Steffen 是正确的，上游中不正确的端口可能会导致此问题，但在我的情况下，上游端口是正确的，我有以下配置。
location / {
proxy_pass $scheme://$host:$server_port;
}
我发现上游总是在错误日志文件中解析为 IP 地址，而不是域名，如果上游运行具有相同 IP 的多个服务器/域，这可能会导致同样的问题，我在配置中添加了以下指令以强制上游始终解析为 FQDN。
proxy_ssl_server_name on;
此更改后，问题消失了。
评论
1赞
Evgeny
10/26/2021
为我工作，谢谢！
1赞
KJ7LNW
6/17/2022
#3
在我们代理旧的 CentOS 软件库的情况下，我们必须修复上游的 SNI，以便 CDN 知道将请求路由到哪里：
location / {
proxy_pass https://vault.centos.org:443;
proxy_ssl_name vault.centos.org;
proxy_ssl_server_name on;
}
评论