我的 node.js 应用程序在端口 80 上监听 http，在端口 443 上监听 https，我认为这是相当标准的做法。
然而，我最近阅读的一些示例使用其他端口（例如 8080 和 8081）来侦听 http/https，然后使用其他方式（例如iptables或ufw规则）通过将数据包重新路由到/来自其他端口来为端口 80 / 443 提供服务。
所以我的问题是为什么我不想直接监听端口 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.
要将 node 绑定到 port80或443，您需要以 root 身份运行它，这不是一个好主意。
您用于将流量重新路由到更高端口的方法取决于您。是iptables资源最少和最简单的。另一种方法是使用 NginX/Apache 代理到 Node.js。我想说这种方法的主要好处是您还可以从那里提供静态文件之类的东西，而不必通过 Node.js 提供它们。
Apache 和 NginX 都被明确地设计为非常擅长处理静态文件，因此它们非常擅长，而 Node 是一个完整的 JS 环境，涉及所有开销。Node 擅长处理大量同时连接，它当然可以完美地为正常负载提供文件，但它会比 NginX 使用更多的资源来完成它。
Using an HTTP-aware proxy like Apache/NginX also means that you can very easily set up multiple instances of Node to run different subdomains, or even different paths on the same domain.