WebSocket端口80/443 EC2和Erlang的牛仔
我的生产环境是基于EC2实例的CentOS 6.0，我现在正在编写一个视频通信应用程序，我决定使用Erlang，因为它是基于通信的应用程序的最佳语言。
我正在使用Cowboy的WebSocket进行实时通信＆amp;我决定使用80端口作为企业网络的高可用性，几天前它没有任何问题，但最近它刚刚停止工作。
当我将它切换到80/443/21或22以外的任何其他端口时，它的工作方式就像魅力而不是这些标准端口，我禁用了所有防火墙并允许来自亚马逊安全组的所有类型的流量但没有任何工作对我来说。
但是这个问题只发生在WebSocket上，我安装并使用apache在端口80上工作正常，我尝试的另一件事就是我在端口80上安装了haproxy列表并为不同的WebSocket请求设置转发在这种情况下8088的端口我注意到我在套接字服务器上收到了请求，但是一收到它就会自动断开连接。
请帮忙。
答案 0 :(得分：0)
我把我的想法作为答案，而不是写一系列评论，所以主要想法会更清晰，更扎实。
最初的假设是有一些透明代理＆＃34;您和您的服务器之间的某个地方（如果您正在工作，可能在ISP或公司的网络门口）。这个词＆＃34;透明＆＃34;这意味着它甚至在不询问您的情况下拦截您的网络流量。通常，ISP使用这种透明代理来缓存客户端的流量，因此使用较少的网络带宽。您可以谷歌搜索关键字＆＃34; squid transparent proxy＆＃34;了解更多技术细节。
现在，如果代理配置不正确，它只会破坏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工作而不加密（原样） - 这个选项实际上并不正确，但是它会起作用，很难被代理破坏。 / p>