Nœud EADDRINUSE sur AWS quel que soit le port

Je suis tellement frustré … Je ne trouve aucune information en ligne pour m’aider.

Ma configuration est la suivante:

  • Instance AWS EC2
  • Nginx montrant 127.0.0.1:3000
  • Node JS v0.10.32
  • processus mongoDB en cours d’exécution en tant que démon

J’ai essayé d’utiliser mon DNS public / IP publique et de redémarrer nginx, j’ai essayé le port 80, 8000, 1337, etc. J’ai essayé de supprimer Nginx. ps aux | grep :3000 ps aux | grep :3000 ne renvoie rien. ps aux | grep :80 ps aux | grep :80 ne renvoie rien. etc…

Voici le code correspondant:

 https.createServer(options, app).listen(app.get('port'), '127.0.0.1', function() { console.log('Express server listening on port ' + app.get('port')); }); http.createServer(function(req, res) { res.writeHead(301, { "Location": "https://" + req.headers['host'] + req.url }); res.end(); }).listen(3000); 

Quel que soit le port que j’utilise, j’obtiens la même erreur pour sudo node app.js et node app.js :

 events.js:72 throw er; // Unhandled 'error' event ^ Error: listen EADDRINUSE at errnoException (net.js:904:11) at Server._listen2 (net.js:1042:14) at listen (net.js:1064:10) at net.js:1146:9 at dns.js:72:18 at process._tickCallback (node.js:419:13) at Function.Module.runMain (module.js:499:11) at startup (node.js:119:16) at node.js:906:3 

Je l’ai fait fonctionner, mais je dois redirect le trafic vers le port 443 et utiliser https:

 app.listen(3000, '127.0.0.1', function() { console.log('Express server listening on port ' + app.get('port')); }); 

Vous pouvez utiliser netstat -tulpn | grep :XX netstat -tulpn | grep :XX , XX étant le port que vous voulez vérifier.

Il semble que vous essayiez de démarrer un serveur http et un serveur https sur le même port. Supprimez le bit http.createServer et tout ira bien.

Selon ma propre expérience (pas sur EC2) et aussi selon ce commentaire de l’OP , je parierais que la solution à ce problème est d’exécuter le processus en tant que sudo – ou, si vous voulez, il doit y avoir un groupe Linux et des permissions quelque part qui empêchent les utilisateurs non-groupes d’attacher des processus au port 80 ou 443, auquel cas exécuter le processus en tant que superutilisateur fera le travail.

Le fait que l’OP ait délégué le travail d’attachement au bon port à Nginx et que Nginx soit normalement exécuté en tant que processus super utilisateur est compatible avec cette explication.