Nginx — PHP-скрипты, не вызываемые из обратного прокси
Я даю ниже выдержку из /etc/nginx/sites-available/default файл
server {
listen 443 ssl;
server_name example.com;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ = 404;
}
location /rproxy/ {
proxy_pass https://example.org:8144/;
}
location ~ \.php$ {
try_files $uri = 404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
....
}
example.org:8144 сервер
имеет файлы и
index.php— возвращает привет Мирbonjour.php— возвращает Бонжур
Теперь вот вопрос:
Если я перейду к https://example.com/rproxy это быстро возвращается Привет, мир — ожидаемый результат.
Тем не менее, если я просматриваю https://example.com/rproxy/bonjour.php (или даже https://example.com/rproxy/index.php) Я получаю 404 error,
Я понимаю, что здесь происходит. Моя конфигурация Nginx приводит к тому, что экземпляр example.com Nginx пытается найти все *.php файлы локально (т.е. на example.com), которая не работает, когда файл, который я ищу, на самом деле example.org:8144,
Я предполагаю, что есть относительно простой способ Nginx когда НЕ пытаться попытаться выполнить PHP файл — когда это на самом деле на rproxy. Тем не менее, мои знания Nginx я не могу понять, как я могу изменить конфигурацию. Я был бы очень признателен всем, кто мог бы сказать мне, как изменить конфигурацию, чтобы этого не происходило.
Я должен кое-что уточнить здесь:
Мне нужно иметь возможность запускать сценарии PHP на Оба СЕРВЕРА example.com а также example.org,
Здесь есть очень простой обходной путь — я использую другое расширение, скажем, php5, для сценариев php на проксируемом сервере, example.org. Однако это легко может привести к непредвиденным проблемам.
Решение
Для nginx регулярные выражения имеют больший приоритет, чем префиксные. Но
Если самый длинный совпадающий префикс имеет модификатор «^ ~», тогда
регулярные выражения не проверяются.
Так что попробуй заменить
location /rproxy/ {
с
location ^~ /rproxy/ {
Другие решения
На вышестоящих серверах, которые вы передаете, вы ничего не знаете о своей конфигурации nginx. Точно так же ваш nginx не знает, как ваш апстрим должен отвечать на запросы. Ни один из них никогда не будет заботиться о конфигурации другого.
Это начало для фактической передачи имени вашего скрипта, но есть множество разных способов сделать это, и все они полностью зависят от того, как настроен апстрим. Кроме того, не используйте регулярные выражения, если вы можете избежать этого; нет смысла все тормозить без причины.
upstream reverse {
server example.org:8144;
}
server {
listen 443 ssl;
server_name example.com;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ =404;
}
location /rproxy {
proxy_pass https://reverse/$request_uri;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_pass /blah/tmp.sock;
}
}
(Не обязательно умный), но аккуратный способ — это когда вы определяете свой блок PHP, чтобы использовать его вместо апстрима. =404 (опять же, это ужасная идея, если вы не знаете, что делаете, но это можно сделать):
location @proxy {
proxy_pass https://upstream$request_uri;
}
location ~ \.php$ {
try_files $uri @proxy;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_pass /blah/tmp.sock;
}