記錄一次處理https監聽不正確的過程

標籤：負載平衡   https   502   nginx   金山雲   

今天開發反饋在測試金山雲裝置的時候遇到了這樣的一個現象：

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.m3u8Resolving funchlscdn.lechange.cn... 120.92.158.134Connecting to funchlscdn.lechange.cn|120.92.158.134|:443... connected.HTTP request sent, awaiting response... 502 Bad Gateway2017-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.m3u8Resolving funchlscdn.lechange.cn... 120.92.158.134Connecting to funchlscdn.lechange.cn|120.92.158.134|:80... connected.HTTP request sent, awaiting response... 302 FoundLocation: 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.m3u8Connecting to 120.92.133.76:8090... connected.HTTP request sent, awaiting response... 200 OKLength: 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請求，就成功了！

650) this.width=650;" src="https://s3.51cto.com/wyfs02/M00/9C/FA/wKioL1l4XyLBNt4RAAEsCPefYqk951.png" title="2.png" alt="wKioL1l4XyLBNt4RAAEsCPefYqk951.png" />

其實如果非要用nginx的ssl認證的話，那麼的套路就是：開啟nginx，但是在負載平衡那裡使用tcp協議去監聽nginx的8000連接埠，這樣一樣能達到效果。

最後的最後，如果您覺得本文對您升職加薪有協助，那麼請不吝贊助之手，刷一下下面的二維碼，贊助本人繼續寫更多的博文！

650) this.width=650;" src="https://s5.51cto.com/wyfs02/M00/9C/C8/wKioL1l16m3BMYDKAACPHEqd55Q687.jpg" title="webwxgetmsgimg.jpg" alt="wKioL1l16m3BMYDKAACPHEqd55Q687.jpg" style="padding:0px;margin:0px;vertical-align:top;border:none;" />

本文出自 “生活就是等待戈多” 部落格，請務必保留此出處http://chenx1242.blog.51cto.com/10430133/1951191

記錄一次處理https監聽不正確的過程