Nginx e gunicorn não estão exibindo a página inteira (problema de cache)

Question

Eu tenho um aplicativo django, que funciona bem no servidor do django. Acabei de configurá-lo para trabalhar com nginx e gunicorn. Quase todas as páginas funcionam bem, exceto por uma delas. É uma página bem grande, que consiste em 4 menus select (suspensos) com 1000 entradas em cada e tudo que é enviado por um único arquivo html por guinicorn. Gunicorn exibe apenas metade da página. O que também é interessante é que, sem o nginx, o gunicorn exibe a coisa toda bem. Embora a página gerada NÃO seja estática, o nginx, por algum motivo, quebra a página.

Aqui está minha configuração nginx:

ec2-user@ip-172-31-44-39:~/mira_website> sudo cat /etc/nginx/sites-available/miraFrontEnd
# This is example contains the bare minimum to get nginx going with
# Gunicornservers.

worker_processes 1;


user ec2-user nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead

# Feel free to change all paths to suit your needs here, of course
pid /tmp/nginx.pid;
error_log /tmp/nginx.error.log;

events {
  worker_connections 1024; # increase if you have lots of clients
  accept_mutex off; # "on" if nginx worker_processes > 1
  # use epoll; # enable for Linux 2.6+
  # use kqueue; # enable for FreeBSD, OSX
}

http {
  # nginx will find this file in the config directory set at nginx build time
#  include mime.types;

  # fallback in case we can't determine a type
  default_type application/octet-stream;

  # click tracking!
  access_log /tmp/nginx.access.log combined;

  # you generally want to serve static files with nginx since neither
  # Unicorn nor Rainbows! is optimized for it at the moment
  sendfile on;

  tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
  tcp_nodelay off; # on may be better for some Comet/long-poll stuff

  gzip on;
  gzip_http_version 1.0;
  gzip_proxied any;
  gzip_min_length 500;
  gzip_disable "MSIE [1-6]\.";
  gzip_types text/plain text/html text/xml text/css
             text/comma-separated-values
             text/javascript application/x-javascript
             application/atom+xml;

  upstream app_server {

    # for UNIX domain socket setups:
    server unix:/home/ec2-user/gunicorn.sock fail_timeout=0;

    # for TCP setups, point these to your backend servers
    # server 192.168.0.7:8080 fail_timeout=0;
    # server 192.168.0.8:8080 fail_timeout=0;
    # server 192.168.0.9:8080 fail_timeout=0;
  }

  server {
    # listen 80 default deferred; # for Linux
    # listen 80 default accept_filter=httpready; # for FreeBSD
    listen 8000;

    client_max_body_size 4G;
    server_name _;

    keepalive_timeout 10;


    location /static {
        autoindex on;
        alias /home/ec2-user/mira_website/manageDb/static/;
    }

    location / {
      # checks for static file, if not found proxy to app
      try_files $uri @proxy_to_app;
    }

    location @proxy_to_app {
      # an HTTP header important enough to have its own Wikipedia entry:
      #   http://en.wikipedia.org/wiki/X-Forwarded-For
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      # enable this if and only if you use HTTPS, this helps Rack
      # set the proper protocol for doing redirects:
      # proxy_set_header X-Forwarded-Proto https;

      # pass the Host: header from the client right along so redirects
      # can be set properly within the Rack application
      proxy_set_header Host $http_host;

      # we don't want nginx trying to do something clever with
      # redirects, we set the Host: header above already.
      proxy_redirect off;

      proxy_pass http://app_server;

    }

    # Error pages
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /path/to/app/current/public;
    }
  }
}

Este servidor está rodando no amazon ec2 com o Suse linux.

Alguma idéia?

EDIT: Ok, isso é interessante, eu limpei cache do navegador, histórico, cookies e tudo e começou a trabalhar. E então, depois de tentar novamente alguns minutos depois, teve o mesmo problema. Então parece que, quando eu limpo o cache, ele começa a funcionar, mas só por algum tempo (estranho!).

    

Answer 1

Eu tentei várias configurações diferentes e consegui que funcionasse, embora não tenha certeza do que realmente aconteceu. O que eu acho que foi o caso foi a diretiva chamada proxy_buffering . Agora está definido como off .

Além disso, o que pode resolver esse problema é definir proxy_buffer_size size . Aqui é a documentação oficial sobre esta diretiva.