Node.js app can't run on port 80 even though there's no other process blocking the port

Question

I'm running an instance of Debian on Amazon EC2 with Node.js installed. If I run the code below:

http = require('http');

http.createServer(function (request, response){
  response.writeHead(200, {'Content-Type':'text/plain'});
  response.end('Hello World\n');
}).listen(80);
console.log("Running server at port 80");

I get the output below which tells me there's another process listening at port 80:

Running server at port 80

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: listen EACCES
    at errnoException (net.js:901:11)
    at Server._listen2 (net.js:1020:19)
    at listen (net.js:1061:10)
    at Server.listen (net.js:1127:5)
    at Object.<anonymous> (/home/admin/nodetests/nodetest.js:6:4)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)

Now when I check to see if there's a process (as root in case anything is hidden) listening on port 80 using:

netstat -tupln

I get the below output, which tells me theres nothing listening at port 80:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1667/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      1667/sshd

I should note that the debian has port 80 open as an inbound rule if that makes a difference.

My question is: What am I doing wrong? How come I can't identify the process listening to port 80? Why is it blocked in Debian? What steps should I take to get the code running correctly?

Solution 1

The error code EACCES means you don't have proper permissions to run applications on that port. On Linux systems, any port below 1024 requires root access.

Solution 2

Instead of running on port 80 you can redirect port 80 to your application's port (>1024) using

iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

This will work if your application is running on port 3000.

Solution 3

Short answer: You can allow node access to that port using:

setcap 'cap_net_bind_service=+ep' /path/to/nodejs

long answer

Edit:

May not work on new node versions

Solution 4

Note that if you have apache running, you can create a reverse proxy on a vhost. If your node is running on port 8080:

<VirtualHost 127.0.0.1:80>
        ServerName myLocalServer

        ProxyPass        /  http://localhost:8080/
        ProxyPassReverse /  http://localhost:8080/
</VirtualHost>

Of course, add server to /etc/hosts:

127.0.0.1    myLocalServer

You will need to enable the relevant apache modules:

sudo a2enmod proxy_html
sudo a2enmod proxy_http
sudo a2enmod proxy_connect
sudo a2enmod proxy_ajp
sudo service apache2 restart

...and now you can connect to http://myLocalServer.

Solution 5

For those looking for a quick and easy solution for a development environment, port forwarding via ssh can be a nice alternative:

ssh -L 80:localhost:3000 yourusername@localhost -N

This forwards port 80 on localhost to port 3000 on localhost.

It needs to be run as root (privileged port). To cancel it, simply hit ctrl-c in the terminal. (You can add the -f flag to have the command run in the background, but then you need to find it again to kill it).

This solution requires you to have an ssh server running locally. It can be done quickly, but please bear in mind the security implications if you are on a shared network. You might want to apply at least some level of additional security (disable password & root login).

I personally only ever use this on my local machine. I'm not sure how it affects the processing speed of your requests if you run this on production, maybe someone has an idea. Anyway, you would need to make sure this command keeps running all the time, which introduces more headaches. For production environments, I suggest using a reverse proxy like nginx.

View more solutions