WebSocket Port 80/443 EC2 和 Erlang's Cowboy
我的生产环境是 EC2 实例上的 CentOS 6.0，这些天我正在编写一个视频通信应用程序，我决定使用 Erlang，因为它是基于通信的应用程序的最佳语言。
我正在使用Cowboy的WebSocket进行实时通信，我决定使用Port 80，因为它在企业网络上具有高可用性的机会，几天前它没有任何问题，但最近它只是停止工作。
当我将其切换到 80/443/21 或 22 以外的任何其他端口时，它的工作方式就像魅力一样，但在这些标准端口上却没有，我禁用了所有防火墙并允许来自亚马逊安全组的各种流量，但没有任何效果对我有用。
但是这个问题只发生在 WebSocket 上，我在端口 80 上安装并使用了 apache，它工作正常，我尝试的另一件事是我在端口 80 上安装了 haproxy 列表，并在不同的端口上为 WebSocket 请求设置转发，在这种情况下是 8088，我注意到我在套接字服务器上收到了请求，但一旦收到它就会自动断开连接。
请帮忙。
我把我的想法作为一个答案，而不是写一系列的评论，所以主要思想会更清晰和扎实。
最初的假设是，在你和你的服务器之间有一些"透明代理"(如果你在工作，可能在ISP或公司的网络门上)。这里的"透明"一词意味着它甚至不问你就拦截你的网络流量。通常，ISP 使用这种透明代理来缓存客户端的流量，因此使用较少的网络带宽。您可以在谷歌上搜索关键字"鱿鱼透明代理"以获取更多技术细节。
现在，如果代理配置不正确，它只会破坏 WebSockets 协议，从而使您的应用程序无法按预期工作。这里的关键时刻是这是一个 HTTP代理，因此它只拦截与 HTTP 协议相关的流量(默认情况下，它是端口 80)，并且不会拦截其他端口上的流量，这就是为什么您的应用程序在其他端口上工作正常的原因。
不幸的是，除了使用不同的端口之外，没有可靠的方法来解决这个问题。
就个人而言，我建议您只使用TLS/SSL连接。WebSockets确实支持TLS(因为WS在HTTP/HTTPS中工作)。透明代理通常未配置为拦截 TLS 流量：您写道您的应用程序通过端口 443 运行良好，因此这意味着该端口上没有透明代理。如果您不想(或不能)使用 TLS 连接 (wss://用于 websockets)，您可以像使用未加密连接一样使用该应用程序，但只使用端口 443 - 它在应用程序架构的意义上是不正确的，但在您的情况下它是可以接受的并且可能是安全的。
更新
关于像8080这样的替代HTTP端口，如果有一个透明的代理拦截端口80上的流量，那么这些人很有可能也想拦截替代HTTP端口，如8080或81或8081或其他端口。因此，即使该应用程序通过 8080 运行良好，也不能保证它明天会继续工作，因此如果发生这种情况，您将需要再次更改端口。
从我的角度来看，通过TLS使其工作(因此默认情况下它将通过端口443工作)是最正确的想法。或者，如果您无法引入 TLS，只需通过 443 使其在没有加密的情况下工作(原样) - 同样，此选项实际上不正确，但它可以工作并且几乎不会被代理破坏。