Djangoアプリケーションがあり、Djangoのサーバーで正常に動作します。nginxとgunicornで動作するように構成しました。1つを除いてほとんどすべてのページが正常に動作します。かなり大きいです。ページは、4つの選択(ドロップダウン)メニューで構成され、それぞれに1000のエントリがあり、すべてがguinicornによって単一のhtmlファイルによって送信されます。Gunicornはページの半分だけを表示します。また興味深いのは、nginxがないと、gunicornが全体を表示することです。生成されたページは静的ではありませんが、nginxは何らかの理由でページを壊します。
これが私の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;
}
}
}
このサーバーは、Suselinuxを搭載したAmazonec2で実行されています。
何か案は?
編集:わかりました、これは興味深いです。ブラウザのキャッシュ、履歴、Cookieなどをすべてクリアすると、機能し始めました。そして、数分後に再試行した後、同じ問題が発生しました。したがって、キャッシュをクリアすると、キャッシュが機能し始めますが、しばらくの間だけです(奇妙です!)。
私はさまざまな構成を試し、それを機能させましたが、実際に何が起こったのかはわかりません。私がそうだったと思うのは、proxy_buffering
というディレクティブでした。これで、off
に設定されます。
また、この問題を解決できるのは、proxy_buffer_size size
を設定することです。 ここ は、このディレクティブに関する公式ドキュメントです。