保持愚蠢简单：

Question

我创建并启动了这样的应用程序：

express -s -t ejs
npm install express
npm install ejs
node app.js

并且它有效（在端口3000上）。但是，当我将端口更改为80时，然后运行node app.js输出：

node.js:198
throw e; // process.nextTick error, or 'error' event on first tick
          ^
TypeError: Cannot call method 'getsockname' of null
at HTTPServer.address (net.js:746:23)
at Object.<anonymous> (/var/www/thorous/app.js:35:67)
at Module._compile (module.js:432:26)
at Object..js (module.js:450:10)
at Module.load (module.js:351:31)
at Function._load (module.js:310:12)
at Array.<anonymous> (module.js:470:10)
at EventEmitter._tickCallback (node.js:190:26)

这也适用于我的笔记本电脑，但不适用于我的Amazon EC2实例，其中端口80已打开。可以弄清楚什么是错的。有什么提示吗？

Answer 1

如果您真的想这样做，可以将端口80的流量转发到3000。

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3000

Answer 2

您是否以root身份启动了应用？因为较低的端口号需要root权限。也许sudo节点app.js有效吗？

但是，你不应该使用root权限在端口80上运行任何node.js应用程序！ NEVER！

我的建议是在前面运行nginx作为在端口上运行的node.js应用程序的反向代理。 3000

Answer 3

也许以前在端口80上还有其他东西在运行？

也许进行端口扫描并确认它还没有被使用？

nc -z <<your IP>> 80

Answer 4

保持愚蠢简单：

netcap
systemd
VPS

在常规VPS（例如 Digital Ocean ， Linode ， Vultr 或 Scaleway ）上，磁盘是永久性的，请使用“ netcap”。这将允许非root用户绑定到特权端口。

sudo setcap 'cap_net_bind_service=+ep' $(which node)

TADA！现在，您可以以普通用户身份运行node ./server.js --port 80了！

在旁边：

您还可以使用systemd停止和启动服务。由于systemd有时是点对点，因此我写了wrapper script in Go，它使部署节点项目非常容易：

# Install
curl https://rootprojects.org/serviceman/dist/linux/amd64/serviceman -o serviceman
chmod +x ./serviceman
sudo serviceman /usr/local/bin

# Use
cd ./my/node/project
sudo serviceman --username $(whoami) add npm start

或者，如果您的服务器未称为“ server.js”（事实上的标准），或其他选项：

cd ./my/node/project
sudo serviceman --username $(whoami) add node ./my-server-thing.js -- --my-options

所有要做的就是使用默认的默认设置为您创建systemd文件。我也建议您同时阅读systemd文档，但是它有点让人难以理解，而且与简单而良好的教程相比，教程可能更令人困惑，而且效果不好。

短暂实例（即EC2）不适用于长时间运行的服务器

通常，当人们使用EC2时，这是因为他们不关心单个实例的正常运行时间可靠性-他们想要的是“可伸缩”架构，而不是持久性架构。

在大多数情况下，实际上并不是要虚拟化服务器以任何方式持久化。在这些类型的“临时”（临时）环境中，“重新启动”旨在与从头开始重新安装大致相同。

您不是“设置服务器”，而是“部署映像”。登录到这样的服务器的唯一原因是对要创建的映像进行原型设计或调试。

“磁盘”是易失的，IP地址是浮动的，每次启动时映像的行为相同。您通常也不会采用传统意义上的用户帐户概念。

因此：尽管通常的确，您不应该以root用户身份运行服务，但通常情况下，您会使用易失性虚拟化……这没关系那么多。您只有一个服务，一个用户帐户，并且一旦实例失败或以其他方式“重新启动”（或启动映像的新实例），就会重新拥有一个全新的系统（这意味着任何漏洞仍然存在。

防火墙：临时与VPS

像EC2之类的东西通常旨在为仅供私人使用，而不是面向公众。这些是“云服务”系统。您应该使用许多不同的服务并自动缩放。这样，您将使用负载平衡器服务将端口转发到您的EC2组。通常，实例的默认防火墙将拒绝所有公共网络流量。您必须进入防火墙管理，并确保要使用的端口确实处于打开状态。

有时，VPS提供程序具有“企业”防火墙配置程序，但是更典型的情况是，您仅获得对虚拟机的原始访问权限，并且因为只有您实际侦听的端口才可以访问外部世界（默认情况下，它们通常（没有运行随机服务），则可能无法从防火墙获得任何其他好处。当然是个好主意，但不一定要做您需要做的事情。

请勿将EC2用作VPS

您上面的用例可能是传统VPS服务的更好候选者（如上所述： Digital Ocean ， Linode ， Vultr ， Scaleway 等），它们更易于使用，并且管理上的麻烦也少得多。您只需要一点bash CLI专门知识即可。

此外，作为额外的奖励，您不必猜测成本是多少。他们以简单的 $ / month 告诉您，而不是¢/ cpu / hour / gb / internal-network / external-network / etc-这样，当出现问题时，您会通过电子邮件或管理员得到警告控制台，而不是意外的账单，价格为6,527美元。

底线：如果您选择使用EC2，而且您不是一名“ DevOps”专家，而该公司的员工也没有会计师，那么您将很难。

Node.js + Express：应用程序不会开始侦听端口80

4 个答案:

保持愚蠢简单：

短暂实例（即EC2）不适用于长时间运行的服务器

防火墙：临时与VPS

请勿将EC2用作VPS