web-dev-qa-db-fra.com

L'application Node.js ne peut pas s'exécuter sur le port 80 alors qu'aucun autre processus ne le bloque

J'exécute une instance de Debian sur Amazon EC2 avec Node.js installé. Si je lance le code ci-dessous:

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");

J'ai le résultat ci-dessous qui m'indique qu'il existe un autre processus d'écoute sur le 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)

Maintenant, quand je vérifie si un processus (en tant que root au cas où quelque chose est caché) écoute le port 80 en utilisant: 

netstat -tupln

Je reçois la sortie ci-dessous, ce qui ne me dit rien d’écouter au 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

Je dois noter que le port 80 de Debian est ouvert en tant que règle entrante si cela fait une différence. 

Ma question est: qu'est-ce que je fais mal? Pourquoi ne puis-je pas identifier le processus d'écoute du port 80? Pourquoi est-il bloqué dans Debian? Quelles étapes dois-je suivre pour que le code fonctionne correctement? 

javascriptlinuxnode.jsamazon-ec2debian
88
Brian Yeh

Le code d'erreur EACCES signifie que vous ne disposez pas des autorisations appropriées pour exécuter des applications sur ce port. Sur les systèmes Linux, tout port inférieur à 1024 nécessite un accès root.

187
hexacyanide

Au lieu d’exécuter sur le port 80, vous pouvez rediriger le port 80 vers le port de votre application (> 1024) en utilisant 

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

Cela fonctionnera si votre application est exécutée sur le port 3000.

66
Kamrul

Réponse courte: vous pouvez autoriser l'accès de nœud à ce port en utilisant:

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

longue réponse

17
Reut Sharabani

Notez que si vous avez Apache en cours d'exécution, vous pouvez créer un proxy inverse sur un vhost. Si votre noeud fonctionne sur le port 8080:

<VirtualHost 127.0.0.1:80>
        ServerName myLocalServer

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

Bien sûr, ajoutez le serveur à /etc/hosts:

127.0.0.1    myLocalServer

Vous devrez activer les modules Apache appropriés:

Sudo a2enmod proxy_html
Sudo a2enmod proxy_http
Sudo a2enmod proxy_connect
Sudo a2enmod proxy_ajp
Sudo service Apache2 restart

... et maintenant vous pouvez vous connecter à http://myLocalServer.

6
Redsandro

Pour ceux qui recherchent une solution rapide et facile pour un environnement de développement, la redirection de port via ssh peut être une alternative intéressante:

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

Cela transfère le port 80 sur localhost au port 3000 sur localhost.

Il doit être exécuté en tant que root _ (port privilégié). Pour l'annuler, appuyez simplement sur ctrl-c dans le terminal. (Vous pouvez ajouter l'indicateur -f pour que la commande soit exécutée en arrière-plan, mais vous devez ensuite la retrouver pour la tuer).

Cette solution nécessite un serveur ssh exécuté localement} _. Cela peut être fait rapidement , mais gardez à l’esprit les implications en matière de sécurité si vous êtes sur un réseau partagé. Vous voudrez peut-être appliquer au moins un certain niveau de sécurité supplémentaire (désactivez le mot de passe et la connexion root).

Personnellement, je ne l'utilise jamais que sur ma machine locale. Je ne sais pas en quoi cela affecte la vitesse de traitement de vos demandes si vous utilisez ceci en production, peut-être que quelqu'un a une idée. Quoi qu'il en soit, vous devez vous assurer que cette commande continue à fonctionner tout le temps, ce qui introduit davantage de maux de tête. Pour environnements de production}, je suggère d'utiliser un proxy inverse tel que nginx .

2
panepeter

J'ai la même erreur et j'ai essayé d'exécuter mon application avec Sudo et cela a fonctionné pour moi.

sans Sudo 

mansi@mansi:~/NodePractice$ node myFirst.js 
events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: listen EACCES 0.0.0.0:80
    at Object.exports._errnoException (util.js:870:11)
    at exports._exceptionWithHostPort (util.js:893:20)
    at Server._listen2 (net.js:1224:19)
    at listen (net.js:1273:10)
    at Server.listen (net.js:1369:5)
    at Object.<anonymous> (/home/mansi/NodePractice/myFirst.js:6:4)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)

et avec Sudo

mansi@mansi:~/NodePractice$ Sudo node myFirst.js 
^C
0
Parth Pachchigar