Я работаю над локальной виртуальной машиной разработки и пытаюсь протестировать обслуживание моего сайта с помощью gunicorn и nginx в качестве обратного прокси только для статических ресурсов. Сайт загружает минус статические ресурсы с user nginx; в nginx.conf. Попытка загрузить статический ресурс по отдельности выявляет ошибку 403 Forbidden.
Для фона. Статические ресурсы находятся в общей папке под /media/sf_work. Все файлы принадлежат root:vboxsf (VirtualBox по умолчанию). Моя учетная запись пользователя в системе добавлена в vboxsf группа, и у меня есть полный доступ к общей папке.
Для сравнения я попытался изменить пользователя nginx.conf на свою учетную запись. В этом сценарии статические файлы загружались, но затем сама домашняя страница выдает ошибку 403 Forbidden. Итак, я попытался добавить nginx пользователь к vboxsf group, но тогда все выдает ошибку 403 Forbidden. После дальнейшего расследования кажется, что если пользователь nginx.conf находится в любой группа, это приводит к 403 Forbidden.
Есть идеи, что здесь может происходить?
ОБНОВИТЬ
Таким образом, проблема с домашней страницей, возвращающей 403 Forbidden при использовании моей учетной записи в качестве пользователя nginx (единственный способ работы статических файлов), связана с отсутствием файла index.html в каталоге (список каталогов запрещен). Однако я, очевидно, не хочу, чтобы он отображал каталог; он должен передать этот запрос прокси-серверу. Я использую следующее:
location / {
try_files $uri $uri/ @proxy
}
location @proxy {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
proxy_pass http://127.0.0.1:8080;
}
Что-то не так?
Итак, я наконец решил это. Во-первых, очевидно, что пользователь nginx.conf должен иметь доступ к общей папке, а это значит, что мне пришлось использовать свою учетную запись. Я не доволен этим, но это всего лишь ящик для разработки, поэтому безопасность на самом деле не является проблемой.
Затем возникла проблема с моим try_files директива. Оглядываясь назад, это имеет смысл. Я прошу /, и этот каталог действительно существует, но я не хочу этого совпадения. Так что мне действительно нужно было:
try_files $uri @proxy
Потом все заработало.