使用域名指向nginx服務來代理https，nginx可以通過分析clienthello中的server_name字段得到訪問域名，然后通過解析域名地址來進行代理。

靈壽網站建設公司創新互聯公司,靈壽網站設計制作，有大型網站制作公司豐富經驗。已為靈壽上1000+提供企業網站建設服務。企業網站搭建\外貿營銷網站建設要多少錢，請找那個售后服務好的靈壽做網站的公司定做！

這里有幾個問題，第一個是低版本的ie瀏覽器，使用的是低版本的tls，沒有這個字段，無法得到域名，不過現在使用低版本IE的越來越少了，可以忽略。
第二個是蘋果的某些系統應用，填寫的域名不是真正的域名，不過有跡可循，可以通過字符串修改為真正的域名，進行代理。

最近測試京東的時候發現訪問京東二級域名的時候偶爾會返回200，偶爾會301一個異常頁面。

而如果新開瀏覽器打開二級頁面，就沒有這種問題。
偶爾發現如果不使用域名直接代理，而是使用瀏覽器代理設置，訪問一切正常，非常奇怪。
通過對比發現，使用域名代理時使用的是HTTP2.0，而設置瀏覽器代理時使用的是HTTP1.1，于是在瀏覽器禁止http2.0（火狐設置 about：config network.http.spdy.enabled.http2為假/gg瀏覽器沒找到怎么設置），訪問京東一切正常。
客戶端在請求的時候會攜帶自己支持的http類型

于是想到在代理時篡改字段，把http2.0給關掉，只申請http1.1，但是連接會被中斷。
https://blog.csdn.net/mrpre/article/details/77868570
根據這個網頁可以知道，雖然hello是明文的，但是也有校驗，篡改是走不通的。
繼續進一步抓包，發現在訪問二級頁面時，瀏覽器發出了幾十個請求（不同域名），但是抓包只有一個鏈接，難道HTTP2.0會把不同域名同樣IP的請求放在一個鏈接里面復用嗎？所以導致了問題。
這里做了一些嘗試，使用jiadian.jd.com的url訪問www.jd.com 的ip地址。

我們發現剛好和瀏覽器出現的錯誤一樣，都帶了一個cdn_nohost。
基本可以確定HTTP2.0對于多個域名解析到同一個ip上的情況下，會復用連接，那么在這種情況下，簡單的https代理就不開行了，只能針對一個域名給予一個ip的方法才能處理。