我应该 node.js 监听哪些端口？如何以及为什么？答案

【问题标题】：What ports should I node.js listen on? How and why?我应该 node.js 监听哪些端口？如何以及为什么？
【发布时间】：2013-02-03 01:22:07
【问题描述】：

我的 node.js 应用程序在端口 80 上监听 http，在端口 443 上监听 https，我认为这是相当标准的做法。

但是，我最近阅读的一些示例使用其他端口（例如 8080 和 8081）来监听 http/https，然后使用其他方式（例如 iptables 或 ufw 规则通过以下方式服务端口 80 / 443）将数据包重新路由到/从其他人。

查看两个示例 here 和 here。

所以我的问题是为什么我不想直接监听端口 80 和 443？

是否存在安全问题？这仅仅是这些作者没有权限监听低于 1024 的端口的情况（我会觉得这很奇怪吗？）？大多数人是否在侧节点上运行 Apache？（我没有）。

假设我不想直接监听 80 和/或 443 有充分的理由，我应该使用哪种方法将流量从 80 / 433 中继到我选择的备用端口？

我在上面提到了 iptables 和 ufw，其中一个比其他更好，还是我应该使用其他一些方法？答案是否取决于我是否在进程之间平衡负载？

提前致谢。

【问题讨论】：

我认为这是因为您需要 root 权限才能在低于 1024 的端口上运行，并且您不希望您的应用程序具有 root 权限，但是仍有一些方法可以绑定它。我个人使用AuthBind
如果我没记错的话，1337 端口正在成为运行 nodejs 的标准。要执行应用程序，您可以使用 NGINX 作为反向代理服务器。

【解决方案1】：

您链接的第一篇文章的第一行提到了原因。

Standard practices say no non-root process gets to talk to
the Internet on a port less than 1024.

要将节点绑定到端口80 或443，您需要以root 身份运行它，这不是一个好主意。

您用于将流量重新路由到更高端口的方法取决于您。 iptables 是资源最少且最简单的。另一种方法是使用 NginX/Apache 代理到 Node.js。我想说这种方法的主要好处是您还可以从那里提供静态文件之类的东西，而不必通过 Node 提供它们。

Apache 和 NginX 都被明确地设计为非常擅长处理静态文件，因此它们非常擅长，而 Node 是一个完整的 JS 环境，涉及所有开销。 Node 擅长处理大量同时连接，它当然可以完美地为正常负载提供文件，但它会比 NginX 使用更多的资源。

使用 Apache/NginX 之类的 HTTP 感知代理还意味着您可以非常轻松地设置多个 Node 实例来运行不同的子域，甚至是同一域上的不同路径。

【讨论】：

使用 NginX/Apache 提供文件而不是 Node 有什么好处？
@loganfsmyth: 但如果你使用 Apache 或 NginX 的方法......这意味着，这些服务器需要 root 权限才能监听端口 80，对吧？......那为什么对他们来说不是问题，但对 node.js 来说是问题？
那些服务器不以您的用户身份运行。当您启动它们时，通常您是在告诉它们启动，然后它们切换为以自己的用户身份运行，并且它们的安装脚本已将其用户设置为可以访问这些端口。如果你真的想要，你可以为你自己的用户做同样的事情，但大多数人在某个代理后面运行 Node。