Nginx und uWSGI: Connection refused und 502 Bad Gateway Fehler

Versuchen, Nginx und uWSGI auf Ubuntu 13.10.

Wenn ich versuche auf die website zugreifen, ich erhalte die Meldung "502 Bad Gateway".

Lief apt-get install nginx uwsgi uwsgi-plugin-python3 zu installieren nginx/uwsgi.

/etc/nginx/sites-enabled/Webseite.com:

server {
        listen          80;
        server_name     webpage.com;
        access_log /var/log/nginx/webpage.com_access.log;
        error_log /var/log/nginx/webpage.com_error.log;


        location / {
            uwsgi_pass      /var/run/webpage.com.uwsgi.socket;
            include         uwsgi_params;
            uwsgi_param     Host $host;
            uwsgi_param     X-Real-IP $remote_addr;
            uwsgi_param     UWSGI_SCHEME $scheme;
            uwsgi_param     SERVER_SOFTWARE nginx/$nginx_version;     
        }
}

/etc/uwsgi/apps-aktiviert/Homepage.com

[uwsgi]
vhost = true
plugin = python3
socket = /tmp/webpage.com.sock
master = true
enable-threads = true
processes = 2
home = /var/www/webpage.com/env
wsgi-file = /var/www/webpage.com/env/hello.py
virtualenv = /var/www/webpage.com/env
chdir = /var/www/webpage.com/env
touch-reload = /var/www/webpage.com/reload

/var/log/nginx/Homepage.com_error.melden Sie

2014/01/17 16:28:58 [error] 25073#0: *13 connect() to unix:///var/run/webpage.com.uwsgi.socket failed (111: Connection refused) while connecting to upstream, client: 83.109.132.224, server: webpage.com, request: "GET /HTTP/1.1", upstream: "uwsgi://unix:///var/run/webpage.com.uwsgi.socket:", host: "webpage.com"

hello.py ist nur eine einfache hello world app.

Kämpfen haben, mit dieser für mehrere Stunden... Jetzt brauche ich Hilfe 🙂

sehr wahrscheinlich ist dein uWSGI-Instanz nicht ausgeführt wird, überprüfen Sie mit "ps aux" und überprüfen Sie, uWSGI Protokolle zu

InformationsquelleAutor | 2014-01-17

7

Blick auf die config-Dateien hier gepostet verweisen Sie auf den socket in nginx als:
```
uwsgi_pass      /var/run/webpage.com.uwsgi.socket;
```
und im uwsgi als
```
socket = /tmp/webpage.com.sock
```
- Ich änderte socket in /etc/uwsgi/apps-aktiviert/Homepage.com von /tmp/webpage.com.sock zu /var/run/webpage.com.uwsgi.socket - Aber bekomme immer noch die 502 Bad Gateway-Fehler...
- Die Datei Berechtigungen für die socket-Datei ist: -rw-r--r-- 1 www-data www-data 0 Jan 17 14:32 /var/run/webpage.com.uwsgi.socket
- und was ist der protokollierte Fehler in nginx die Datei error_log?
- Das Protokoll ist bereits in meinem ersten post.
- sind Sie sicher, dass uwsgi läuft? die Ausgabe von ps -ewwf | grep uwsgi
- Leere Ausgabe. Ok, das ist nicht einfach...
- so uwsgi wird nicht ausgeführt 🙂 Überprüfen Sie die uwsgi-Fehler-log-in /var/log/uwsgi/...
- /var/log/uwsgi/ enthält nur einen leeren Ordner mit dem Namen app. Es werden keine log-Dateien.
- so versuchen Sie, um zu überprüfen, warum uwsgi nicht starten.
InformationsquelleAutor Paolo Casciello
3

Ich weiß, das hat nichts zu tun mit der OP das problem, aber da dies ist der top-Treffer für die Fehlermeldung in Google ein, würde ich mag zu beachten, was das problem behoben für mich.

War ich nach einem tutorial empfohlen, um uwsgi_pass 127.0.0.1:9090; in die nginx Konfiguration für ein Python-Skript eingerichtet worden, in der uwsgi Konfiguration mit http-socket = :9090. das Fehlerprotokoll /var/log/nginx/error.log zeigte das problem: 2015/08/13 02:16:04 [error] 12566#12566: *2 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: ~^(www\.)?(.+)$, request: "GET /hello/HTTP/1.1", upstream: "uwsgi://127.0.0.1:9090", host: "kybyz" browser, mittlerweile, war, dass Sie mir den 502 Bad Gateway Fehler.

gab es zwei Möglichkeiten (mindestens), um es zu beheben. die erste war die änderung http-socket im uwsgi Konfiguration einfach socket (als, es stellte sich heraus, das tutorial empfohlen; ich hatte nicht Lesen Sie es sorgfältig genug). das wäre aber nicht mehr erlauben, mich zu testen, das Skript direkt mit dem Hinweis, mein browser bei http://127.0.0.1:9090/, da das Skript nun Sprach uwsgi - Protokoll anstelle von http. also wechselte ich zurück zu http-socket und geändert, in der nginx Konfiguration, die uwsgi_pass Linie zu proxy_pass http://127.0.0.1:9090;.
- Ich vermisste, dass ein Teil mich nach meiner eigenen Anleitung ... aber hier Ihre Antwort half mir bei der Suche nach Problem. Danke.
InformationsquelleAutor jcomeau_ictx
1

Diese nicht zu beantworten, die OP ' s ursprüngliche Frage, aber ich hatte den gleichen Fehler bei nginx connect() to unix:///tmp/uwsgi_dev.sock failed (13: Permission denied) while connecting to upstream, und ich war in der Lage, es zu beheben nur durch einen Neustart der uwsgi-Prozess komplett. Es ist ein Produktions-server, so war ich zögerlich zu tun, einen harten Neustart, sondern nur ein Neuladen der uwsgi-Prozess hat nicht den trick tun. Hoffe, dass jemand hilft.

InformationsquelleAutor jstaab
0

In der Regel ist dies eine Datei permission-problem, d.h. die uwsgi-socket-Datei ist nicht lesbar von der nginx-Prozess. Überprüfen Sie die socket-Datei, die Erlaubnis und dessen übergeordneten Ordner und seine Großeltern Ordner, etc. Sie können dies mit einem Befehl (angenommen, Ihr nginx Prozess wird ausgeführt durch Benutzer nginx):
```
su nginx -c "[[ -r sockfile ]] && echo ok"
```
InformationsquelleAutor Cyker
0

Für meine Python-Django-app auf der AWS-Plattform, es ist einfach überlastet.

Zuerst habe ich mehrere Server und bemerkt, dass C-Instanzen (compute) besser sind als general purpose (M) -Instanzen, da die M -Instanzen hatten 66% der CPU-Last laufen, als zu stehlen (von einigen anderen Kunden) nach dem Auslaufen der CPU-credits.

Aber nach dem ausführen der app für einige Zeit (und nachdem die Anzahl der eingehenden Anforderungen gewachsen 5x in der kurzen Zeit), ich habe auch überprüft die Datenbank-performance (RDS), und es lief auf 100%. Ich wuchs auch der Datenbank-instance-Größe von 4 CPU 8 CPU und jetzt läuft es wieder ohne Fehler.

InformationsquelleAutor PHZ.fi-Pharazon

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.