Предположим, что каталог данных MySQL является C:\mysql\data, и Вы хотите определить местоположение нечто базы данных в D:\data\foo. Настройте символьную ссылку с помощью этой процедуры:
Для получения дополнительной информации, http://dev.mysql.com/doc/refman/5.0/en/windows-symbolic-links.html
У вас должен быть раздел location
для обработки запросов PHP, настроенный аналогично этому:
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
(дополнительный try_files
разрешает безопасность уязвимость , которая может позволить запускать произвольные файлы как PHP.)
Кроме того, ваш корень
должен быть определен в разделе server
файла конфигурации, , а не раздел местоположения
. Это одна из наиболее распространенных неправильных конфигураций nginx .
Это примечание для установки пассажиром.
Я только что установил nginx из исходного кода через пассажира, что вызвало проблему с php5-fpm. По умолчанию nginx.conf использует проблему, описанную Майклом Хэмптоном. Решение состоит в том, чтобы удалить блок вокруг директив root и index, поэтому:
location / {
root html
index index.html index.htm
}
становится:
root html
index index.html index.htm
Кроме того, блок php настроен неправильно. См. Ответ Майкла Хэмптона, чтобы узнать, как это сделать.
Дополнительным примечанием может быть то, что если php5-fpm настроен на использование сокетов, укажите параметр fastcgi_pass в блоке php в nginx.conf на настройку сокета в /etc/php5/fpm/pool.d/www.conf .
Я видел:
FastCGI, отправленный в stderr: «Первичный сценарий неизвестен» при чтении заголовок ответа от восходящего потока
на сервере, который я поместил под высокую нагрузку во время стресс-тестирования. Мое подозрение, которое еще предстоит подтвердить, состоит в том, что доступные дескрипторы файлов из ОС были исчерпаны. В этом случае php-fpm не может получить ссылку на файл.
Я понимаю, что это предположение, но оно определенно соответствует моему сценарию и может также помочь кому-то другому.
У меня только что возникла эта проблема в новой версии nginx. (конфигурация взята из более старой версии)
Что мне нужно было сделать, так это разместить include fastcgi_params;
над моим пользовательским SCRIPT_FILENAME
следующим образом:
location @web {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
Как SCRIPT_FILENAME
перезаписывался.
Если вы используете псевдонимы в блоках местоположения, необработанная ошибка 404 также может проявлять такое поведение. Вы можете увидеть это, если страница, отображаемая в браузере, представляет собой простой текст «Файл не найден», в отличие от более отформатированной (центрированной) страницы nginx 404. По сути, это действительно говорит о том, что страница 404 не может быть найдена.
Чтобы решить эту проблему, добавьте дополнительную строку try_files $ uri = 404
в свой блок местоположения и перезагрузите конфигурацию nginx. В дополнение к тому, что Майкл Хэмптон сказал о решении конкретной уязвимости системы безопасности , это также позволяет обработчику fastcgi переопределить определение псевдонима и найти сценарий 404 в местоположении по умолчанию.
sudo vim /etc/php-fpm.conf
о строке 149, сменить пользователя php && группу пользователей
Сейчас я успешно тестирую.
Спасибо @homeway, ваш ответ вдохновляет мне. Большое спасибо!
Я отвечаю на тот же вопрос, но другой метод не помог мне решить вопрос!
Я решил это, я считаю, что ключ в следующем: Право пользователя Linux ведет к вопрос: FastCGI отправлено в stderr: "Первичный скрипт неизвестен"
Потому что группа пользователей PHP-FPM по умолчанию: apache: apache, но ваша директория кода - это someBody: someBody. Поэтому вам следует изменить права пользователя!
Я пишу блог, чтобы решить этот вопрос. Вы можете увидеть этот блог:
[Nginx FastCGI отправил в stderr: «Неизвестный первичный сценарий»] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html