Я выполнил инструкции по настройке django с nginx из django wiki (https://code.djangoproject.com/wiki/DjangoAndNginx) и настройте nginx следующим образом (несколько изменений имени в соответствии с моей настройкой).
user nginx nginx;
worker_processes 2;
error_log /var/log/nginx/error_log info;
events {
worker_connections 1024;
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';
client_header_timeout 10m;
client_body_timeout 10m;
send_timeout 10m;
connection_pool_size 256;
client_header_buffer_size 1k;
large_client_header_buffers 4 2k;
request_pool_size 4k;
gzip on;
gzip_min_length 1100;
gzip_buffers 4 8k;
gzip_types text/plain;
output_buffers 1 32k;
postpone_output 1460;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 75 20;
ignore_invalid_headers on;
index index.html;
server {
listen 80;
server_name localhost;
location /static/ {
root /srv/static/;
}
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) {
access_log off;
expires 30d;
}
location / {
# host and port to fastcgi server
fastcgi_pass 127.0.0.1:8080;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_pass_header Authorization;
fastcgi_intercept_errors off;
fastcgi_param REMOTE_ADDR $remote_addr;
}
access_log /var/log/nginx/localhost.access_log main;
error_log /var/log/nginx/localhost.error_log;
}
}
Статические файлы не обслуживаются (nginx 404). Если я смотрю в журнал доступа, кажется, что nginx ищет в / etc / nginx / html / static ..., а не в / srv / static /, как указано в конфигурации.
Я понятия не имею, почему он это делает, любая помощь будет очень признательна.
Короткий ответ: см. последнее место в длинной версии. Технически установка, описанная на этой странице, неверна. Причины см. В конце ответа.
Длинный ответ: у тебя наверно есть /etc/nginx...
путь в ваших журналах, потому что запросы статических файлов не соответствуют вашему статическому расположению (расположение регулярного выражения предшествует) а вы не указали root
для server
заблокировать себя.
Когда ваш запрос совпадает с местоположением регулярного выражения, nginx будет искать файлы в /etc/nginx
. Чтобы исправить это, вы можете добавить root
директива прямо внутри server
block, как описано выше, или под каждым местоположением без прокси (то же самое относится и к fastCGI).
Также замечено: если вы укажете root
директива в папке nginx будет искать файлы в папке $document_root/$location
, например в /srv/static/static
что на 99% не может вам понадобиться. Вы можете использовать alias
директива, но документация nginx предпочитает переопределить root
директива, если это возможно:
location /static {
root /srv;
}
В alias
Директива работает так, как вы ожидали, поэтому вы можете написать вместо этого:
location /static {
alias /srv/static;
}
Что касается местоположения регулярного выражения, вы можете поместить его внутрь /static
расположение. Кроме того, поскольку будут только статические файлы, вы можете избавиться от их местоположения регулярного выражения, и окончательное местоположение будет выглядеть следующим образом:
location /static {
root /srv;
access_log off;
expires 30d;
}
Согласно командам, которые предоставил пользователь, ему нравится, чтобы большинство компонентов были как можно более свежими, работающими на Debian-подобном Linux. Но вместо того, чтобы правильно устанавливать все вручную или просто использовать aptitude, он также начинает смешивать и устанавливать программное обеспечение из пакетов. Это будет работать для некоторых блоков разработки, но не подходит для любого производства. Итак, вот несколько моментов:
virtualenv
.www-data:www-data
в Debian. Поскольку ваша установка не предназначена для запуска какого-либо кода в контексте веб-сервера, добавление дополнительных пользователей бесполезно./etc/nginx/nginx.conf
файл, который совершенно неверен, особенно в системах, подобных Debian. Вместо этого вы можете захотеть создать sample_project
файл в /etc/nginx/sites-available
и свяжите его с /etc/nginx/sites-enabled
чтобы nginx прикрепил вашу конфигурацию:# cd /etc/nginx/sites-enabled && ln -s ../sites-available/sample_project sample_project
sample_project
файл в этом случае должен содержать только server
сам блок, не более того.log_format
и, возможно, некоторые другие) должны иметь контекст вашего виртуального хоста и, следовательно, должны быть помещены в server
блокировать в вашем sample_project
файл. Вы не повлияете на работу других сервисов, работающих на этом веб-сервере. Вы можете разместить log_format
директивы в вашем файле, но вне любого блока и до server
заблокировать себя.fastcgi_pass
директивы нужно писать include fastcgi_params
и переопределить только те, которые не соответствуют текущим настройкам.*access.log
или *error.log
подстановочный знак.Предоставление этому минимальному рабочему файлу конфигурации хоста /etc/nginx/sites-available/sample_project
может выглядеть так:
server {
listen 80;
server_name myhostname.com;
root /home/user/django/sample_project;
location /static {
root /srv;
access_log off;
expires 30d;
}
location / {
include fastcgi_params;
fastcgi_pass 127.0.0.1:8080;
}
access_log /var/log/nginx/sample_project.access.log combined;
error_log /var/log/nginx/sample_project.error.log warn;
}
Ты используешь server_name localhost
в серверном блоке. Это означает, что nginx будет отвечать только на запросы, которые имеют поле заголовка http host 'localhost' или, возможно, 127.0.0.1.
Запросы с другими полями хоста http будут отправляться по умолчанию для nginx, что, как я думал, /usr/share/nginx/html
.
Если вы хотите убедиться, что ваш серверный блок принимает все входящие запросы, используйте server_name ""
. Однако это может быть нежелательно для конфигурации django.