Question

根据以下帖子，某些网络只允许连接到端口80和443： Socket IO fails to connect within corporate networks

编辑：为了澄清，问题是当最终用户在公司防火墙后面使用浏览器时。我的服务器防火墙设置在我的控制之下。

我已经阅读过Nginx使用proxy_pass来监听另一个端口上的Socket.io（我已经读过它的缺点），还使用nodejitsu / node-http-proxy反向代理将非节点流量传递给Nginx（其中还有其他缺点）。我有兴趣考虑所有可能的选择。

经过多次搜索，我没有找到有关socket.io监听端口443的可能性的讨论，如下所示：

var io = require('socket.io').listen(443);

客户端会像这样连接：

var socket = io.connect('http://url:443/', {secure: false, port: '443'});

除了在该服务器上放弃使用https之外，还有其他任何缺点吗？（例如，企业网络是否阻止通过端口443进行非SSL通信？）

Answer 1

端口443上的非加密流量可以正常工作，但是如果你想要与具有偏执和不太合适的安全策略的网络兼容，你应该假设有人已经“保护”了它们。

无论愚蠢的防火墙如何，您都应该使用SSL加密的WebSockets，因为WebSocket协议与HTTP不兼容（它伪装成这样，但这还不够）并且无法与HTTP代理可靠地协同工作。

例如，O2 UK（可能还有许多其他移动ISP）通过其代理管道所有非加密连接，以重新压缩图像和审查网站。他们的代理断开WebSocket连接，唯一的解决方法是使用SSL（除非你对Socket.IO回到jsonp轮询感到满意......）

Answer 2

这实际上取决于设置的防火墙类型。如果端口刚刚被阻止，那么几乎任何东西都可以在端口80和443上运行。我自己使用它来通过80端口的防火墙工作时通过端口80获得ssh会话。

但是，有一些防火墙具有更高级的过滤选项。除了常规端口过滤之外，这些还可以基于协议过滤掉流量。我甚至遇到了服务器前面的一个防火墙，它会以某种方式阻止通过ssh隧道的https流量。到目前为止，这些先进的过滤技术是罕见的例外，因此对于大多数情况，只需要在443上进行监听就可以了。

Answer 3

我认为您应该阅读有关Socket.IO和阻止端口的整个wiki文章（通过防病毒软件，防火墙等）：