記錄一次處理https監聽不正確的過程
今天開發反饋在測試金山雲設備的時候遇到了這樣的一個現象:
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,重新測試之後,發現錯誤變成了這樣:
[[email protected] ~]# 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訪問卻是可以的,效果如下:
[[email protected] ~]# 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裏,設計路線如下:
http(80)->開發模塊(9001)
而在https裏,設計路線如下:
https(443)->nginx(8000)->開發模塊(9001)
這時候就發現了問題,原來最早的時候金山雲是沒有配置https證書的,於是開發們就用nginx的8000端口去監聽ssl這樣達到https證書的效果,但是後來金山雲控制臺添加了https證書,就不再需要nginx去配置ssl證書了,再去https監聽8000這一步也就是錯誤的了,於是在負載均衡那裏改成了:
https(443)->開發模塊(9001)
同時關閉了nginx,這時候再來測試一下https請求,就成功了!
其實如果非要用nginx的ssl證書的話,那麽的套路就是:開啟nginx,但是在負載均衡那裏使用tcp協議去監聽nginx的8000端口,這樣一樣能達到效果。
最後的最後,如果您覺得本文對您升職加薪有幫助,那麽請不吝贊助之手,刷一下下面的二維碼,贊助本人繼續寫更多的博文!
本文出自 “生活就是等待戈多” 博客,請務必保留此出處http://chenx1242.blog.51cto.com/10430133/1951191
記錄一次處理https監聽不正確的過程