标签：类型 低版本 name work 字符 config hello 分析 ble
使用域名指向nginx服务来代理https，nginx可以通过分析clienthello中的server_name字段得到访问域名，然后通过解析域名地址来进行代理。
这里有几个问题，第一个是低版本的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的方法才能处理。
标签：类型 低版本 name work 字符 config hello 分析 ble
原文地址：https://blog.51cto.com/xzq2000/2447183
