记录一次处理https监听不正确的过程
今天开发反馈在测试金山云设备的时候遇到了这样的一个现象：
|
1
2
3
4
5
6
|
wget https:
//funchlscdn
.lechange.cn
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8
--2017-07-26 11:49:26-- https:
//funchlscdn
.lechange.cn
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8
Resolving funchlscdn.lechange.cn... 120.92.158.134
Connecting to funchlscdn.lechange.cn|120.92.158.134|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
|
爆“error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol”的错误，就是在当向只提供http的服务发送https请求造成的。
#ping funchlscdn.lechange.cn，获得了这个域名对应的IP之后，返回到金山云的控制台，发现这个IP是一个负载均衡，但是这个负载均衡配置的时候对80端口是http协议，而对443端口还是http协议，于是更改成https，重新测试之后，发现错误变成了这样：
|
1
2
3
4
5
6
|
[root@js-develop ~]
# wget https://funchlscdn.lechange.cn/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8.m3u8
--2017-07-26 16:08:15-- https:
//funchlscdn
.lechange.cn
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8
Resolving funchlscdn.lechange.cn... 120.92.158.134
Connecting to funchlscdn.lechange.cn|120.92.158.134|:443... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2017-07-26 16:08:15 ERROR 502: Bad Gateway.
|
在浏览器打开效果如图：
502 Bad Gateway
The proxy server received an invalid response from an upstream server.
_____
KSYUN ELB 1.0.0
同时发现金山云负载均衡里对nginx的8000健康检查是“异常”。但是使用http访问却是可以的，效果如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
[root@js-develop ~]
# wget http://funchlscdn.lechange.cn/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8.m3u8
--2017-07-26 15:31:55-- http:
//funchlscdn
.lechange.cn
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8
Resolving funchlscdn.lechange.cn... 120.92.158.134
Connecting to funchlscdn.lechange.cn|120.92.158.134|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http:
//120
.92.133.76:8090
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8 [following]
--2017-07-26 15:31:55-- http:
//120
.92.133.76:8090
/LCLR/2K02135PAK01979/0/0/20170726085033/dev_20170726085033_lpxh73ezzb92xxa8
.m3u8
Connecting to 120.92.133.76:8090... connected.
HTTP request sent, awaiting response... 200 OK
Length: 66 [application
/x-mpegURL
]
Saving to: “dev_20170726085033_lpxh73ezzb92xxa8.m3u8”
100%[========================================================================================================================================================>] 66 --.-K
/s
in
0s
2017-07-26 15:31:55 (3.02 MB
/s
) - “dev_20170726085033_lpxh73ezzb92xxa8.m3u8” saved [66
/66
]
|
于是就叫来开发问一下http和https详细的流程，开发说在http里，设计路线如下：
|
1
|
http(80)->开发模块(9001)
|
而在https里，设计路线如下：
|
1
|
https(443)->nginx(8000)->开发模块(9001)
|
这时候就发现了问题，原来最早的时候金山云是没有配置https证书的，于是开发们就用nginx的8000端口去监听ssl这样达到https证书的效果，但是后来金山云控制台添加了https证书，就不再需要nginx去配置ssl证书了，再去https监听8000这一步也就是错误的了，于是在负载均衡那里改成了：
|
1
|
https(443)->开发模块(9001)
|
同时关闭了nginx，这时候再来测试一下https请求，就成功了！
其实如果非要用nginx的ssl证书的话，那么的套路就是：开启nginx，但是在负载均衡那里使用tcp协议去监听nginx的8000端口，这样一样能达到效果。
最后的最后，如果您觉得本文对您升职加薪有帮助，那么请不吝赞助之手，刷一下下面的二维码，赞助本人继续写更多的博文！
本文转自 苏幕遮618 51CTO博客，原文链接:http://blog.51cto.com/chenx1242/1951191