Nginx + (Apache + Passanger) = ошибка 403 для запроса "/"

У меня есть следующие настройки:

  • nginx как обратный прокси
  • apache (с пассажиром) для подачи контента

Теперь у меня есть простое приложение Sinatra, и происходит следующее, если я пытаюсь получить доступ к различным вещам:

  1. domain.com/hi - Синатра говорит мне привет как было закодировано

  2. domain.com/readme.txt (статический файл) - он правильно выбирается из папки 'public_html' с помощью nginx

  3. И наконец - domain.com/ или же domain.com - ошибка 403

В последнем случае nginx, вероятно, пытается создать листинг, но это не нужно (я хочу, чтобы он передал запрос '/' в apache). С разрешениями все в порядке.

Сама ошибка (от /var/log/nginx/error.log):

2012/05/12 23:39:40 [error] 19012#0: *1 directory index of "/home/com_domain/public_html/" is forbidden, client: 66.77.88.99, server: domain.com, request: "GET / HTTP/1.1", host: "domain.com"

И конфигурация:

server {
    listen 80;
    server_name domain.com;

    access_log /var/log/nginx/com_domain.access.log;
    charset utf-8;
    root /home/com_domain/public_html;

    # Include @apache location
    include /etc/nginx/sites-available/_apache;

    location ~ /\.ht {
       deny all;
    }

    location / {
       try_files $uri $uri/ @apache;
    }
}
Источник

1 ответ

Решение

Во-первых, упоминание о настройке - обратный прокси-сервер Apache сначала кажется хорошим выбором - статические файлы обслуживаются Nginx, и вы по-прежнему сохраняете функциональность Apache. Тем не менее, дополнительный сервер добавляет много накладных расходов - вы добавили больше сложности в систему и дополнительный уровень. Поскольку Nginx может взаимодействовать с другими серверами, такими как пассажирский и PHP-FPM, вы можете сопоставить большую часть функциональности Apache с гораздо меньшими издержками. Избавление от Apache снизит сложность и поддержку вашей установки, а, следовательно, улучшит общую производительность и стабильность и упростит дальнейшую отладку.

Nginx пытается отобразить содержимое корневого каталога - вы сказали ему попытаться обслужить указанный файл и указанный каталог перед проксированием в apache. Nginx будет искать файл, соответствующий файлам, указанным в директиве index, если совпадений нет, он попытается отобразить содержимое каталога (т. Е. Список каталогов), в котором происходит сбой.

Если у вас есть индексный файл, который вы хотели бы обслуживать, вам следует обновить index Директива включить его. Если у вас нет такого файла, и вы хотите, чтобы Apache полностью обработал запрос, вам нужно создать соответствующий блок местоположения и proxy_pass запросы к апачу.

Согласно вики Nginx, директивы местоположения сопоставляются в определенном порядке:

  1. Директивы с префиксом "=", которые точно соответствуют запросу (буквальная строка). Если найдено, поиск прекращается.
  2. Все остальные директивы с обычными строками. Если в этом совпадении использовался префикс "^~", поиск прекращается.
  3. Регулярные выражения, в порядке их определения в файле конфигурации.
  4. Если #3 дал совпадение, этот результат используется. В противном случае используется совпадение от #2.

Создание дополнительного location Таким образом, блок, точно совпадающий (то есть используя знак равенства) с корневым путем, позволит вам указать специальные правила для этого отдельного местоположения. Этот блок местоположения должен прокси-запросы к Apache, если он должен работать правильно.:

location = / {
 #proxy_pass ...;
 #error 200 = @apache;
 #include proxy_info;
 #try_files non_existent_file @apache;
}

В зависимости от вашей настройки, может быть несколько способов передачи запроса к прокси, некоторые из которых упоминались выше.

Вы все еще должны держать свой location / {} блок - он будет соответствовать всем запросам, которые не совпадают с вашими другими блоками местоположения. Обратите внимание, что в то время как try_files Директива может работать в соответствии с server {} блок, лучше под location блок, так как он будет обрабатываться только выборочно.

Источник
Другие вопросы по тегам