我的 Node.js 应用程序在端口 80 上监听 http，在端口 443 上监听 https，我认为这是相当标准的做法。
然而，我最近读到的一些例子使用其他端口（例如8080和8081）来监听http/https，然后使用其他方式，例如iptables or ufw通过将数据包重新路由到其他端口或从其他端口重新路由来服务端口 80 / 443 的规则。
看两个例子here and here.
所以我的问题是为什么我不想直接监听端口 80 和 443？
是否存在安全问题？这仅仅是这些作者没有权限侦听低于 1024 的端口的情况吗（我觉得这很令人惊讶？）？大多数人都在旁节点运行 Apache 吗？ （我不）。
假设我有充分的理由不想直接收听 80 和/或 443，我应该使用哪种方法将流量从 80 / 433 中继到我选择的替代端口？
我在上面提到了 iptables 和 ufw，其中之一比其他更好，还是我应该使用其他方法？答案是否取决于我是否在进程之间平衡负载？
提前致谢。
您链接到的第一篇文章的第一行提到了原因。
Standard practices say no non-root process gets to talk to
the Internet on a port less than 1024.
用于节点绑定到端口80 or 443，您需要以 root 身份运行它，这不是一个好主意。
将流量重新路由到更高端口的方法取决于您。这iptables是资源消耗最少且最简单的。另一种方法是使用 NginX/Apache 代理 Node.js。我想说该方法的主要好处是，您还可以从那里提供静态文件之类的东西，而不必通过 Node.js 来提供它们。
Apache 和 NginX 都被明确设计为非常擅长提供静态文件，因此它们非常擅长，而 Node 是一个完整的 JS 环境，涉及所有开销。 Node 非常擅长处理大量并发连接，并且它当然可以很好地为正常负载提供文件服务，但它会比 NginX 使用更多的资源来做到这一点。
使用像 Apache/NginX 这样的 HTTP 感知代理还意味着您可以非常轻松地设置 Node 的多个实例来运行不同的子域，甚至同一域上的不同路径。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
