Nginx 1 FastCGI отправил в stderr: «Основной сценарий неизвестен»

Сообщение об ошибке «основной сценарий неизвестен»: почти всегда связанный с неправильно установленным SCRIPT_FILENAME в nginx fastcgi_param директива (или неправильные разрешения, см. другие ответы).

Вы используете if в конфигурации, которую вы разместили первой. К настоящему времени должно быть хорошо известно, что если зло и часто создает проблемы.

Установка root директива в блоке местоположения - плохая практика, конечно, она работает.

Вы можете попробовать что-то вроде следующего:

server {
    location / {
        location ~* \.php$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass 127.0.0.1:9000;
            try_files $uri @yii =404;
        }
    }
    location @yii {
        fastcgi_param SCRIPT_FILENAME $document_root$yii_bootstrap;
    }
}

Обратите внимание, что приведенная выше конфигурация не тестировалась. Вы должны выполнить nginx -t перед его применением, чтобы проверить наличие проблем, которые nginx может сразу обнаружить.

Это не всегда что SCRIPT_FILENAME неправильно.
Также может быть PHP работает как неправильный пользователь / группа.

Этот пример специфичен для Mac OS X, который, по моему опыту, наиболее проблематичен в настройке (Debian прост для сравнения) - я только что обновил PHP 5.6 до 7.0, используя домашнее пиво и отличные пакеты josegonzalez.

Проблема заключалась в том, что была создана новая копия файлов конфигурации.

Основной файл конфигурации /usr/local/etc/php/7.0/php-fpm.conf, но обратите внимание на Определения пула раздел в конце, где он включает весь подкаталог.

include=/usr/local/etc/php/7.0/php-fpm.d/*.conf

В php-fpm.d есть www.conf файл. По умолчанию это:

user = _www
group = _www

В OS X вам может потребоваться изменить это на:

user = [your username]
group = staff

(вы должны найти это соответствует ls -lh вашего document_root)

К сожалению, без этого изменения вы все равно увидите это в журнале ошибок Nginx. даже если он ищет файл в правильном месте.

"Primary script unknown" while reading response header from upstream

Проверьте, как он сейчас работает:

ps aux | grep 'php-fpm'

или точнее:

ps aux | grep -v root | grep php-fpm | cut -d\  -f1 | sort | uniq

Как проверить правильность имени файла сценария:

(украдено из igorsantos07 в другом ответе)

добавить в http блок основных /usr/local/etc/nginx/nginx.conf:

log_format scripts '$document_root$fastcgi_script_name > $request';

(где первым битом должно быть то, что вы сейчас используете, чтобы вы могли убедиться, что это правильно.)

И чтобы использовать журнал, который вы только что определили, на своем сайте server блок:

access_log /var/log/nginx/scripts.log scripts;

Если это правильно, запрос example.com/phpinfo.php выдаст что-то вроде этого:

/path/to/docroot/phpinfo.php > GET /phpinfo.php

Можете ли вы упростить существующую конфигурацию?

Вы используете location ~ \.php { заблокировать, который вы скопировали / вставили откуда-то из Интернета? Большинство пакетов позволяют сделать это быстрее и аккуратнее. например в OS X вам теперь просто нужно это:

location ~ \.php {
    fastcgi_pass 127.0.0.1:9000;
    include snippets/fastcgi-php.conf;

    # any site specific settings, e.g. environment variables
}

Такие вещи, как fastcgi_split_path_info, try_files и fastcgi_index (по умолчанию index.php) находятся в /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Это, в свою очередь, включает /usr/local/etc/nginx/fastcgi.conf это список fastcgi_param настройки, включая критический SCRIPT_FILENAME.

Никогда не дублируйте root в блоке расположения PHP.

Итак, 3 вещи, которые я нашел после дня борьбы

1. По какой-то причине у меня уже что-то работало на порту 9000, поэтому я перешел на 9001
2. Мой сайт по умолчанию перехватывает мой новый, опять же, я не понимаю, почему, так как это не должно быть, но я просто отключил его
3. Nginx не выполняет автоматическую символьную ссылку для сайтов, доступных для сайтов с поддержкой.

Надеюсь, это избавит кого-то от неприятностей!

Была такая же проблема с более новым nginx (v1.8). Более новые версии рекомендуют использовать snippets/fastcgi-php.conf; вместо того fastcgi.conf. Итак, если вы скопируете / вставите include fastcgi.conf из учебника вы можете получить Primary script unknown ошибка в журнале.

«Основной сценарий неизвестен» это вызвано Контекст безопасности SELinux.

клиент получит ответ

Файл не найден.

nginx error.log имеет следующее сообщение об ошибке

* 19 FastCGI, отправленный в stderr: «Неизвестный первичный сценарий» при чтении заголовка ответа из восходящего потока

поэтому просто измените тип контекста безопасности корневой веб-папки на httpd_sys_content_t

chcon -R -t httpd_sys_content_t /var/www/show

есть 3 пользователя для конфигурации nginx / php-fpm

/etc/nginx/nginx.conf

user nobody nobody;  ### `user-1`, this is the user run nginx woker process
...
include servers/*.conf;

/etc/nginx/conf.d/www.conf

location ~ \.php$ {
#   fastcgi_pass 127.0.0.1:9000;  # tcp socket
    fastcgi_pass unix:/var/run/php-fpm/fpm-www.sock;  # unix socket
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

/etc/php-fpm.d/www.conf

[www]
user = apache  ### `user-2`, this is the user run php-fpm pool process
group = apache

;listen = 127.0.0.1:9000  # tcp socket
listen = /var/run/php-fpm/fpm-www.sock  # unix socket

listen.onwer = nobody  ### `user-3`, this is the user for unix socket, like /var/run/php-fpm/fpm-www.sock
listen.group = nobody  # for tcp socket, these lines can be commented
listen.mode = 0660

Пользователь-1 и пользователь-2 не обязательно должны быть одинаковыми.

для сокета unix пользователь-1 должен быть таким же, как пользователь-3, поскольку nginx fastcgi_pass должен иметь разрешение на чтение / запись в сокете unix.

иначе nginx получит 502 Неверный шлюз, и nginx error.log имеет следующее сообщение об ошибке

* 36 connect () в unix: /var/run/php-fpm/fpm-www.sock не удалось (13: в доступе отказано) при подключении к восходящему потоку

и пользователь / группа корневой веб-папки (/ var / www / show) не обязательно должны совпадать с любым из этих трех пользователей.

У меня тоже была эта проблема, и я решил ее, поменяв строки include fastcgi_params и fastcgi_param SCRIPT_FILENAME ....

Действительно, nginx устанавливает последнее значение каждого параметра FastCGI, поэтому вы должны поместить свое значение после значения по умолчанию, включенного в fastcgi_params.

Я решил эту проблему, закрыв SELINUX в ​​системе CentOS7.3

шаги:

• exec setenforce 0
• Вам также необходимо изменить файл конфигурации

vim /etc/selinux/config set SELINUX to disabled

Я обнаружил, что ваш вопрос ищет то же сообщение об ошибке, но с использованием apache + php-fpm (без nginx). Для меня проблема заключалась в косой черте не в том месте: многие предложения по настройке включают строку в форме:

SetHandler "proxy:unix:/path/to/file.socket|fcgi://localhost/:9000"

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

SetHandler "proxy:unix:/path/to/file.socket|fcgi://localhost:9000/"

проблема исчезла для меня. Может ты сможешь сделать что-то подобное

Я сделал все, что описано выше, потерял 2 часа, биться головой, и проблема не исчезла. Наконец я сделал:

sudo service php7.0-fpm restart

И альт сработало!

Кстати, я настраивал новый проект symfony 3.4 с nginx conf по ссылке: https://symfony.com/doc/3.4/setup/web_server_configuration.html

Это был мой пятый раз, когда я начинал новый проект на symfony, и я не мог поверить, что это «первичный сценарий неизвестен».

Проверьте разрешения для вашего sock-файла php-fpm, почему-то он был недоступен:

chmod 755 /usr/local/var/run/php-fpm.sock

затем попробуйте перезапустить nginx.

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

Я сокращал URL-адреса вики, как предписано MediaWiki, с Bitnami / Nginx на Lightsail.

Я искал и читал много сообщений, этот, кажется, суммирует все возможные сценарии, и я перепробовал их все:

• nginx в порядке, корневая папка php работает, подпапка нет
• ошибка 404 + пустая строка «Файл не найден», а не nginx
• Добавить root на сервер, не работает
• проверьте права доступа к папкам и php-fpm / nginx, без проблем корень и подпапки совпадают
• проверьте руководство по php-fpm для интерпретации кода ошибки, не смог найти его
• включить журнал доступа php-fpm, обнаружил, что URI запроса был правильным, но возвращается 404
• попробуйте включить режим подробного / отладочного для php-fpm, не сработало, предполагаемый файл журнала ошибок всегда пуст

Поэтому мне пришлось попробовать последнее средство, поскольку корневая папка php работала, а подпапки - нет, единственное существенное различие между ними, кроме root используется корневая папка $request_filename и используемые местоположения вложенных папок $document_root и $fastcgi_script_name, поэтому я изменил настройки расположения вложенных папок, чтобы они соответствовали настройкам корневой папки.

Тогда это сработало ... Я до сих пор не уверен Зачем это сработало. Потому что, когда я проверяю журнал доступа php-fpm, я вижу один и тот же URI, один - 404, а другой - 200.

Единственное отличие было в конфигурации. Поскольку они производят одинаковый результат, я не знаю, почему результат получился по-разному.

В любом случае я решил разместить здесь свои 2 цента, надеюсь, это поможет.

PS: Я действительно надеюсь, что PHP предоставляет более качественные сообщения об ошибках и подробный режим, потому что это действительно разочаровывает, когда невозможно изолировать проблему и нет возможности увидеть подробный вывод и информацию об отладке.

Для меня это были расширения.

Мой php-fpm.www.access.log сообщал:

"GET /index.php5" 404

Тем не менее, индексный файл для сайта (MediaWiki) был index.php. Оказывается, у меня были смешанные расширения (php против php5) в соответствующих nginx.conf записи. Вот рабочий конфиг:

location / {
    index index.php;
    try_files $uri $uri/ = @mediawiki;
}
location = /favicon.ico {
    return 204;
}
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /path/to/viki$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT /path/to/viki;
    fastcgi_intercept_errors on;
}

location @mediawiki {
    rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$args last;
}

Вы можете использовать все эти записи index.php5 вместо этого просто добавьте index.php5 файл в корень с таким содержимым:

<?php require './index.php';

(без закрывающего тега).

Попробуйте добавить корневую директиву в местоположение вашего php.

location ~ \.php {
      root /home/willem/git/console/www;
      ...
}

Встречаю тот же вопрос, но Другой метод не помог мне решить вопрос!

Я решаю это, я считаю, что ключ в том, что: Право пользователя Linux приводит к вопросу: FastCGI отправлено в stderr: «Основной сценарий неизвестен»

Поскольку группа user: по умолчанию PHP-FPM - это apache: apache, но ваш каталог кода - someBody: someBody. Так что вы должны изменить права пользователя!

Я пишу блог, чтобы решить этот вопрос, вы можете увидеть этот блог:

[Nginx FastCGI отправил в stderr: «Неизвестный первичный скрипт»] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Я клонировал удаленный сайт, и уже существующий wp-config.php содержал информацию о базе данных удаленного сервера.

Я решил эту проблему, настроив мою локальную конфигурацию wordpress с информацией о моей локальной базе данных.