nginx: échec de la connexion () (111: connexion refusée) lors de la connexion à l'amont


16

Je continue de voir les messages d'erreur ci-dessous dans le journal des erreurs, je peux accéder à toutes les ressources mais je ne sais pas pourquoi l'erreur est en train de marquer.

Erreur:

[erreur] 13368 # 0: * 449 échec de la connexion () (111: connexion refusée) lors de la connexion en amont, client: xxxx, serveur: myserver.com, demande: "GET / stories / mine HTTP / 1.1", en amont: " http: // [:: 1]: 5000 / stories / mine ", hôte:" myserver.com "

Ma configuration Nginx

Je passe la connexion à un node.jscluster fonctionnant sur le port 5000. Vous ne voyez pas ce que j'aurais manqué?

upstream api {
    server localhost:5000;
}

server {
    listen 80; 
    server_name myserver.com;
    root /home/user/_api;


# Logging 

error_log /home/user/log/api.error.log notice;
    location / {
        proxy_redirect off;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   Host                   $http_host;
        proxy_set_header   X-NginX-Proxy    true;
        proxy_set_header   Connection "";
        proxy_cache one;
        proxy_cache_key sfs$request_uri$scheme;
        proxy_pass         http://api;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Nous sommes en 2015 et j'ai ce même problème. chaque fois qu'un message Websocket est supprimé, cette erreur apparaît dans le journal.
r3wt

Réponses:


19

Nginx se connecte à nodjs sur le bouclage IPv6 [:: 1]. nodejs écoute probablement juste sur IPv4.

Essayez de définir

upstream api {
    server 127.0.0.1:5000;
}
...

Pour ceux qui sont confus, changez localhostpour127.0.0.1
kouton

Des idées si j'ai 127.0.0.1 au lieu de localhost et que cela continue?
Ken

3
Vous devez vérifier si le service écoute. Essayez de sudo netstat -pantuvérifier si le service écoute réellement sur le port.
Christopher Perrin

1
@ChristopherPerrin merci pour ce conseil. Cela m'a aidé à réaliser que l'un de mes pools n'écoutait pas sur son port, et il s'est avéré que c'était parce qu'une autre configuration de pool réutilisait le même nom afin d'écraser sa configuration
Robbie Averill

@RobbieAverill ravi d'entendre que cette réponse est toujours utile
Christopher Perrin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.