nginx не видит index php
PHP-FPM не видит index.php
PHP-FPM не видит index.php
October 19, 2011 06:06AM
Posts: 4
Всем привет! Проблема такая: Есть 2 сервера:
На первом в качестве фронт-енда висит nginx:80, а на втором сервере, бэк-ендом висят nginx:80 (для отдачи статики) и php-fpm:9000 (для отдачи динамики)
Nginx фронт-енд настроен следующим образом (/etc/nginx/sites-available/default):
================================================================
server <
listen 80;
\.php$ <
fastcgi_pass 10.0.0.10:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
>
Проблема в том, что php-fpm не воспринимает index.php, то есть, приходится вручную прописыват путь. К примеру, при входе на http://site.ru/ получаем ошибку от nginx (403 Forbidden), а при заходе на http://site.ru/index.php все ОК.
Re: PHP-FPM не видит index.php
October 20, 2011 07:21AM
Posts: 27
location / <
proxy_pass http://10.0.0.10;
index index.html index.htm;
>
Вот фронтенд и ищет index.html или index.htm на бэкенде. А вам надо index.php.
Конфигурацию для php лучше писать на бэкенде, так как можно тогда подключиться к php-fpm через сокет, на фронтенде оставьте вот такой конфиг:
location / <
proxy_pass http://10.0.0.10;
index index.php;
>
>
А для бэкэнда пишите так:
server <
set_real_ip_from 192.168.2.10;
real_ip_header X-Real-IP;
listen 80;
location / <
index index.php;
location
\.php$ <
fastcgi_pass 10.0.0.10:9000;
# перенастройте php-fpm на использование сокета и тогда пишите так:
# fastcgi_pass unix:/var/run/php-fpm.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
>
>
>
Re: PHP-FPM не видит index.php
October 20, 2011 11:39AM
Posts: 4
Спасибо, но не работает ((( Я уже запарился эту проблему решать!
Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.
Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.
Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:
Отсутствует корневой каталог
Небезопасное использование переменных
Чтение необработанного ответа сервера
Отсутствует корневой каталог
Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:
Потерявшийся слеш
Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:
Небезопасное использование переменных
Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.
SCRIPT_NAME
С такой конфигурацией, как эта:
XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME ;
Пример уязвимой конфигурации Nginx:
Произвольные переменные
В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.
Одним из способов проверки является установка значения заголовка referer:
Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.
Чтение необработанного ответа сервера
С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?
Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:
И со следующими директивами в Nginx:
proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.
proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.
Если мы отправим обычный GET-запрос, Nginx вернёт:
Но если мы отправим неверный HTTP-запрос, например:
То получим такой ответ:
merge_slashes отключены
Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».
Попробуйте сами
Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!
Вывод
Nginx — это очень мощная платформа веб-серверов, и легко понять, почему она широко используется. Но с помощью гибкой настройки вы даёте возможность совершать ошибки, которые могут повлиять на безопасность. Не позволяйте злоумышленнику взломать ваш сайт слишком легко, не проверяя эти распространённые ошибки конфигурации.
Вторая часть будет позднее.
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Почему nginx не видит php-fpm:9000?
nginx: [emerg] host not found in upstream «php-fpm5.6» in /etc/nginx/conf.d/default.conf:25
WARNING: Nothing matches the include pattern ‘/etc/php/5.6/fpm/pool.d/*.conf’ from /etc/php/5.6/fpm/php-fpm.conf at line 31.
error_log = /proc/self/fd/2
daemonize = no
user = www-data
group = www-data
listen = [::]:9000
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 3
pm.max_requests = 200
catch_workers_output = yes
clear_env = yes
php_admin_value[sendmail_path] = /usr/local/bin/phpmailer
php_admin_value[open_basedir]= «/data:/srv:/var/tmp:/tmp»
php_admin_value[upload_tmp_dir] = «/var/tmp»
server <
listen 80;
server_name localhost;
root /var/www/html;
fastcgi_pass php-fpm5.6:9000;
fastcgi_index index.php;
>
>
# PHP
ENV PHP_MODS_DIR=/etc/php/5.6/mods-available
ENV PHP_CLI_DIR=/etc/php/5.6/cli
ENV PHP_CLI_CONF_DIR=$
ENV PHP_CGI_DIR=/etc/php/5.6/cgi
ENV PHP_CGI_CONF_DIR=$
ENV PHP_FPM_DIR=/etc/php/5.6/fpm
ENV PHP_FPM_CONF_DIR=$
ENV PHP_FPM_POOL_DIR=$
ENV TZ=Europe/Kiev
# WORKDIR
WORKDIR /var/www/html
# Expose port 9000 and start php-fpm server
EXPOSE 9000
# COMMAND
CMD [«php-fpm5.6»]
Подскажите пожалуйста, в чем может быть проблема.
Ubuntu Server 18.04
Установил Nginx 1.14 и PHP 7.2 FPM
php.ini стандартный
Поменял в нем только вот это
cgi.fix_pathinfo=0 (было 1)
Его я не трогал тоже, стандартный.
Конфиг www.conf тоже стандартный
В директории сайта все папки и файлы выставил владельца www-data, до этого был root
В чем может быть проблема, что я не доконфигурировал?
Естественно я каждый раз при изменении конфигов перезагружал и nginx и php-fpm
systemctl restart nginx && systemctl restart php7.2-fpm
Попробуйте такой конф:
Вчера уже не получилось проверить, вот сейчас проверил.
Потом еще раз глянул в конфиг и обнаружил что когда на тостер закидывал конфиг я домен подменил на site.ru, балбес блин )))
В общем я проверил и с Вашим конфигом теперь работает все!
За что огромное спасибо!
Отмечу решением.
А еще лучше если Вы мне подскажете как вообще для каждого сайта свой юзер и группа или так не делают по феншую и просто я загоняюсь? Как правильно делать? Или оставить родную группу www-data?
Я понял Вас, оставлю как есть группу и пользователя.
Не получается подружить nginx и php
чтобы установка php не тащила httpd?
Не ставить пакет php.
У тебя же по ссылке есть Отключение Httpd
скорее всего php-fpm не настроено в /etc/php-php.d/www.conf или listen не совпадает с настройкой fastcgi_pass nginx
так там для c7 не предлагают php ставить, только php-fpm. ошибся, пора спать.
Паставить, а потом отключить. Нахуа?
Ставь «nginx php5». Есть подозрение, что по зависимостям вылезают какие-то апачевские либы и модули.
В пакете php идет mod_php для апача, ну и явно указан в зависимостях httpd. Ставить надо nginx php-fpm.
а если телнетом на порт php-fpm стукануть, то что потдается?
Ну, если даже инструкция с самого РУСЛИНУКСНЕТ не работает, то совершенно очевидно, что способов запустить лемп-стек на центоси не существует.
Стартуешь демон php-fpm и проверяешь результат 🙂
Тогда еще в конфиге пула php-fpm надо на этот сокет поменять, по дефолту там 9000 порт.
а если телнетом на порт php-fpm стукануть, то что потдается?
В подходе. Для начала разберись в общих чертах как эта связка должна работать, а потом уже настраивай её. Тебе ведь её потом эксплуатировать.
Не надо пытаться слепо повторить инструкцию.
В общих чертах понимаю, что к nginx php привязывается через fastcgi-интерфейс php-fpm, а к apache с помощью модуля mod_php.
В /etc/php-fpm.conf есть строки:
В /etc/nginx/nginx.conf есть:
У меня до php-fpm клиентские запросы кажется на доходят?
Покажи весь конфиг.
nginx обращается к демону php-fpm по протоколу FastCGI через unix или обычный сетевой сокет. Домен php-fpm запускает воркеры которые исполняют php-скрипты.
А вот это вот что такое:
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
И почему директория логов php-fpm находится внутри директории логов nginx?
Опечатка
/var/log/php-fpm/error.log
Это было в /etc/nginx/nginx.conf.default Я это перенёс в /etc/nginx/nginx.conf и раскоментировал.
Вообще-то ошибка возникает на виртуальном хосте описанном в файле /etc/nginx/conf.d/mycoolhost.ru.conf такого содержания:
\.php$ но nginx ругаясь в логах на неправильный конфиг. Тогда я добавил location
\.php$ в default_server
И ты ожидаешь что php будет работать на mycoolhost.ru?
Ладно, буду дальше курить доки по nginx. Я думал, что «_» (default_server) это глобальные настройки всех виртуальных хостов.
А может в jobs? За два килорубля настрою тебе LEMP. Ну или за килорубль, если на дебиане
Демпингую на 500 WMR 😀
А чё не сразу до одного доширака?
Так неинтересно. Должен быть аукцион дух состязания.
А вообще: не получится настроить php-fpm, повесь на бекенд Апач.
Ладно, ладно) Ты если чё пиши, не стесняйся, мы тут.
Ты опять все усложнил.
Ну ок, читай документацию дальше. Пока-что ты прочёл явно недостаточно. Или понял недостаточно.
Держи конфиг, не мучайся
Можно указать server_name yourdomain.ru для твоего домена.
Для каждого домена я делал свой конфиг.
Centos 7 стоит php7 + php-fpm + nginx + owncloud + mariadb и т.п., без httpd
Подключаешь:
Закомментируй стандартные настройки (все секции server) в
. Почистить кеш в браузере.
Зайти на example.com/info.php
Конфиг owncloud, может кстати кому то еще пригодиться:
Так,
Если другие версии (сборки) ngninx и php-fpm данная инструкция сработает?
У меня установлены nginx 1.10.2 из epel, php и php-fpm 5.4.16 из base.
То что у тебя в nginx.conf в директиве listen не стоит default_server это нормально?
Нормально, зависит от конфигурации.
Да должно сработать конечно. Про кеш в браузере не забывайте очистить.
Потом решил ещё одну проверку сделать, обратился к серверу не по имени хоста, а по ip-адресу, в этом случае обращение должно идти к default_server, который отображает заглушку. Положил в корневые директории как default_server, так и хоста mycoolhost.ru файл ttt.php с содержанием:
Для тех кто не читал переписку, любые попытки добавить директивы fastcgi_* куда-либо кроме default_server приводят к тому, что nginx отказывается запускаться.