2015-05-26 25 views
16

Od wielu dni walę sobie z tym problemem i wreszcie dotarłem do ceglanego muru.nginx uwsgi websockets 502 Zła brama w górę przedwcześnie zamknięta podczas odczytywania nagłówka odpowiedzi z wyższego poziomu

Próbowałem dostać mój stos uruchomić:

http://django-websocket-redis.readthedocs.org/en/latest/running.html#django-with-websockets-for-redis-behind-nginx-using-uwsgi

byłem patrząc na niektóre inne tak artykułach jak ten:

nginx - uWSGI HTTP + websocket config

Wydają mieć podobny problem, z którym się spotykam, ale rozwiązanie nie działa dla mnie.

Zasadniczo wciąż napotykam ekran złej bramy nginx 502 za każdym razem, gdy próbuję uruchomić moje procesy uWSGI. Mam uruchomione dwa oddzielne procesy uwsgi zgodnie z instrukcjami w dokumentacji.

gdy uruchomię websocket uwsgi przykład, pojawia się następujący:

*** running gevent loop engine [addr:0x487690] *** 
[2015-05-27 00:45:34,119 wsgi_server] DEBUG: Subscribed to channels: subscribe-broadcast, publish-broadcast 

który mówi mi, że uwsgi instancja działa w porządku. Następnie uruchamiam mój następny proces uwsgi i nie ma tam żadnych dzienników błędów ...

Po przejściu do strony w przeglądarce strona zawiesza się na kilka sekund, zanim uzyska ekran złą bramę 502.

Według dzienników nginx, nginx mówi:

2015/05/26 22:46:08 [error] 18044#0: *3855 upstream prematurely closed connection while reading response header from upstream, client: 192.168.59.3, server: , request: "GET /chat/ HTTP/1.1", upstream: "uwsgi://unix:/opt/django/django.sock:", host: "192.168.59.103:32768" 

To jedyny dziennik błędów i uzyskać podczas próby uzyskania dostępu do strony w przeglądarce internetowej.

Wszelkie pomysły ktokolwiek ???

Poniżej znajdują się niektóre z moich plików konfiguracyjnych:


nginx.conf

user www-data; 
worker_processes 4; 
pid /run/nginx.pid; 

events { 
    worker_connections 768; 
} 

http { 

    ## 
    # Basic Settings 
    ## 

    sendfile on; 
    tcp_nopush on; 
    tcp_nodelay on; 
    keepalive_timeout 65; 
    types_hash_max_size 2048; 
    # server_tokens off; 

    # server_names_hash_bucket_size 64; 
    # server_name_in_redirect off; 

    include /etc/nginx/mime.types; 
    default_type application/octet-stream; 

    ## 
    # SSL Settings 
    ## 

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE 
    ssl_prefer_server_ciphers on; 

    ## 
    # Logging Settings 
    ## 

    access_log /var/log/nginx/access.log; 
    error_log /var/log/nginx/error.log; 

    ## 
    # Gzip Settings 
    ## 

    gzip on; 
    gzip_disable "msie6"; 

    # gzip_vary on; 
    # gzip_proxied any; 
    # gzip_comp_level 6; 
    # gzip_buffers 16 8k; 
    # gzip_http_version 1.1; 
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; 

    ## 
    # Virtual Host Configs 
    ## 

    include /etc/nginx/conf.d/*.conf; 
    include /etc/nginx/sites-enabled/django.conf; 
} 

Mam następujący django.conf plik, który rozciąga nginx.conf

upstream django { 
    server unix:/opt/django/django.sock; 
} 

server { 
    listen 80 default_server; 
    charset utf-8; 
    client_max_body_size 20M; 
    sendfile on; 
    keepalive_timeout 0; 
    large_client_header_buffers 8 32k; 

location /media { 
    alias /opt/django/app/media/media; 
} 

location /static { 
    alias /opt/django/app/static; 
} 

location/{ 
    include /opt/django/uwsgi_params; 
} 

location /ws/ { 
     proxy_http_version 1.1; 
     proxy_set_header Upgrade $http_upgrade; 
     proxy_set_header Connection "upgrade"; 
     proxy_pass http://unix:/opt/django/app.sock; 
     proxy_buffers 8 32k; 
     proxy_buffer_size 64k; 
    } 
} 

A dwa pliki, które są odpowiedzialne za moich procesów uwsgi następująco:

runserver_uwsgi.ini:

[uwsgi] 
ini = :runserver 

[default] 
userhome = /opt/django 
chdir = %dapp/ 
master = true 
module = chatserver.wsgi:application 
no-orphans = true 
threads = 1 
env = DJANGO_SETTINGS_MODULE=myapp.settings 
vacuum = true 

[runserver] 
ini = :default 
socket = /opt/django/app.sock 
module = wsgi_django 
buffer-size = 32768 
processes = 4 
chmod-socket=666 

i wsserver_uwsgi.ini

[uwsgi] 
ini = :wsserver 

[default] 
userhome = /opt/django 
chdir = %dapp/ 
master = true 
module = chatserver.wsgi:application 
no-orphans = true 
threads = 1 
env = DJANGO_SETTINGS_MODULE=chatserver.settings 
vacuum = true 

[wsserver] 
ini = :default 
http-socket = /opt/django/django.sock 
module = wsgi_websocket 
http-websockets = true 
processes = 2 
gevent = 1000 
chmod-socket=666 

Odpowiedz

6

znalazłem problem.

Mój [runserver] gniazdo (app.sock) powinno być wskazane pod upstream django i moje gniazdo [wsserver] (django.skarpeta) Należy podkreślić pod location /ws/ tak:

upstream django { 
    server unix:/opt/django/app.sock; 
} 

server { 
    listen 80 default_server; 
    charset utf-8; 
    client_max_body_size 20M; 
    sendfile on; 
    keepalive_timeout 0; 
    large_client_header_buffers 8 32k; 

location /media { 
    alias /opt/django/app/media/media; 
} 

location /static { 
    alias /opt/django/app/static; 
} 

location/{ 
    include /opt/django/uwsgi_params; 
} 

location /ws/ { 
     proxy_http_version 1.1; 
     proxy_set_header Upgrade $http_upgrade; 
     proxy_set_header Connection "upgrade"; 
     proxy_pass http://unix:/opt/django/django.sock; 
     proxy_buffers 8 32k; 
     proxy_buffer_size 64k; 
    } 
} 
+0

Ach, więc nie musi być dodatkowa konfiguracja na apache2/nginx? Tak jak na maszynie do rozwoju lokalnego działa bezbłędnie bez problemu, ale na produkcji dostaję taki sam błąd jak ty. Używam Apache, więc nie jestem całkiem pewien, czy istnieje podobny sposób rozwiązania tego problemu. – kiradotee

+0

Skonfigurowałem to tylko poprzez NGINX. Ta konfiguracja zakłada, że ​​serwer WWW i django działają na tym samym hoście, jeśli to pomaga. – Dominooch