Вопросы Теги

Блок местоположения передается в другой сокет php-fpm

Есть два хоста с пулом PHP-FPM каждый - one.com и two.com. Я бы хотел, чтобы one.com/two прошел и показал two.com с использованием пула two, но, похоже, у меня возникли трудности.

Через псевдоним и try_files , я ' Мне удалось получить статические ресурсы из файлов two.com, обслуживаемых через. one.com/two/path/to/asset.ext, но запросы PHP, например, one.com/two/index.php (и запросы к файлам, которые не существуют в двух и попытка отладки путем добавления заголовков в каждый блок местоположения показывает только заголовок, присутствующий в последнем универсальном блоке php.

-

РЕДАКТИРОВАТЬ 2:

Оказывается, что fastcgi_split_path_info необходимо изменить на также учитывайте префикс каталога.

Итак, я вырезал файл фрагмента и немного изменил его внутри блока местоположения: 

location ^~ /two {
        alias /data/srv/nginx/two.com/public/;
        try_files $uri $uri/ /two/index.php$is_args$args;

        location ~* ^\/two.+\.php$ { # have also tried with just \.php$
            alias /srv/two.com/public/$1;

            fastcgi_split_path_info ^/two(.+\.php)().*$; # the second group is deliberately empty.

            try_files $fastcgi_script_name =404;

            fastcgi_param PATH_INFO $path_info;

            fastcgi_index index.php;
            include snippets/fastcgi_params.conf;

            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

            fastcgi_pass unix:/var/run/php/7.1-two.com.sock;
        }
}

Похоже, это заставляет блоки местоположения работать, за исключением случаев, когда я прохожу на один уровень глубже, например / two / account - который снова показывает страницу 404 one.com.

Я сбросил отказ во внешнем местоположении, который останавливает запрос, но удаление отказа во внутреннем местоположении вместо этого не блокирует запрос. По какой-то причине он решает использовать последнее местоположение регулярного выражения в исходном коде.

0
задан 28 September 2018 в 19:35
1 ответ

Итак, я обнаружил проблему и отказался -такое отличное решение.

Согласно документации nginx, существует известная ошибка, когда использует try_files и псевдоним в том же контексте (который выиграл не будет исправлено).

В багтрекере nginx есть обсуждение ошибки , включая случаи и то, что на самом деле происходит.

Поэтому мне пришлось в конечном итоге изменить свои config следующим образом:

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

Во-вторых, try_files в первом блоке необходимо для дважды префикс имени запроса - вместо /two/index.php он стал /two/two/index.php (потому что псевдоним обрезает первую часть перед определением следующий блок местоположения).

Наконец, для PHP мне нужно было настроить REQUEST_URI , чтобы вместо /two/index.php он проходил как / index .php .

Я создал отображение переменных в своей основной конфигурации nginx следующим образом: 

http {

    # ...

    map $request_uri $prefixless_request_uri {
        "~^/[^/]+(?P<path>.*)$" $path;
    }

И затем сослался на него прямо перед тем, как вызвать fastcgi_pass , чтобы переопределить переданное значение. 

fastcgi_param REQUEST_URI $prefixless_request_uri;
0
ответ дан 5 December 2019 в 05:16

Теги

Похожие вопросы