如何检测tcp连接是否已从ssl连接转发？

我正在处理的特定场景是，尝试连接到AWS弹性负载平衡器后面的websocket连接，同时强制使用https/ssl而不是http/tcp

为了从http/s启用TCP/SSL升级，负载平衡器上的协议必须在端口80上设置为TCP而不是http，在443上设置为SSL而不是HTTPS，这两种协议都使用TCP转发到80的实例端口

但是，将协议设置为TCP/SSL的一个副作用是不再设置

x-forwarded-proto

头，如下所示：

这使得使用http/tcp到https/ssl的301I任何传入请求的下一个挑战有些问题，因为这通常依赖于检查

x-forwarded-proto

头

关于具体情况的更多细节：存在一个docker容器，其中运行一个Meteor.js进程，该进程依次驻留在AWS Elastic Beanstalk应用程序中（默认情况下，它有一个Nginx代理层，但由于使用了docker，而docker只是从docker hub中提取一个容器定义，因此无法访问该层），它位于前面提到的ELB后面

最后，当请求通过ELB、Nginx和docker代理层时，我会检查应用程序可用的头文件，试图确定客户端发出的原始请求是以http还是https开始的

传入的

https://

请求头：

{
    host: 'whatever.elasticbeanstalk.com',
    'x-real-ip': '999.99.99.99',
    'x-forwarded-for': '999.99.99.99',
    'cache-control': 'max-age=0',
    accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
    'upgrade-insecure-requests': '1',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
    'accept-encoding': 'gzip, deflate, sdch',
    'accept-language': 'en-US,en;q=0.8'
}

{
    host: 'whatever.elasticbeanstalk.com',
    'x-real-ip': '999.99.99.99',
    'x-forwarded-for': '999.99.99.99',
    'cache-control': 'max-age=0',
    accept: 'image/webp,image/*,*/*;q=0.8',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
    'accept-encoding': 'gzip, deflate, sdch',
    'accept-language': 'en-US,en;q=0.8',
    'if-none-match': '"141699-1446507991000"',
    'if-modified-since': 'Mon, 02 Nov 2015 23:46:31 GMT'
}

传入的

http://

请求头：

{
    host: 'whatever.elasticbeanstalk.com',
    'x-real-ip': '999.99.99.99',
    'x-forwarded-for': '999.99.99.99',
    'cache-control': 'max-age=0',
    accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
    'upgrade-insecure-requests': '1',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
    'accept-encoding': 'gzip, deflate, sdch',
    'accept-language': 'en-US,en;q=0.8'
}

{
    host: 'whatever.elasticbeanstalk.com',
    'x-real-ip': '999.99.99.99',
    'x-forwarded-for': '999.99.99.99',
    'cache-control': 'max-age=0',
    accept: 'image/webp,image/*,*/*;q=0.8',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
    'accept-encoding': 'gzip, deflate, sdch',
    'accept-language': 'en-US,en;q=0.8',
    'if-none-match': '"141699-1446507991000"',
    'if-modified-since': 'Mon, 02 Nov 2015 23:46:31 GMT'
}

其中唯一一个看起来很有用的是

升级不安全请求

头，但基于此

我敢肯定不是

---

但是，也许我遗漏了什么…

当您使用TCP时，ELB不会注入HTTP头，例如x-forwarded-proto或x-forwarded-for。您可能可以从中获得所需信息。

如果问题实际上是“我如何确保通过HTTP访问我的网站的任何人被重定向到https/ssl”（事实证明这就是我的意思），这是可能的

将弹性负载平衡器设置为将80上的HTTP转发到实例上的80上的HTTP（而不是以前的80上的TCP），然后将443上的HTTPS转发到实例上的80上的TCP

协议检测期间的“假设HTTPS/SSL”：即检查是否存在

x-forwarded-proto

，如果存在，则它来自http请求，因此301到HTTPS。如果不存在，则假设它是HTTPS，不要重定向它（在实践中，我觉得在重定向之前最好检查协议是否为http，但在当前设置中，我非常确定这是唯一可能发生的情况）

---

好主意，谢谢，但不幸的是，在我的实例前面的NGIX实例没有被配置为接收这样的设置，而它在日志中看起来很好，任何请求都会返回400错误，直接从NGNXCAN重新配置NGIX来绕过它，或者甚至考虑从图片中删除ELB，并执行您自己的L。B和SSL终止。可能是的，但我不想这样做：我选择elastic beanstalk的一半原因是不必管理nginx之类的东西。事实证明，我找到了基本忽略问题的方法（见下文）很好的解决方案Joshua，今晚一直在使用类似的配置。我会尝试一下，谢谢！很好，这是解决这个问题的一个非常简单的聪明的解决方案。其他所有解决方案都依赖于代理层和配置。再次感谢您分享它。@Joshua如果我在80上将HTTPS转发到TCP，websocket会工作吗？还是会失败回到长轮询？