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


81

Я впервые использую Nginx, но я более чем знаком с Apache и Linux. Я использую существующий проект, и когда я пытаюсь увидеть index.php, я получаю 404 Файл не найден.

Вот запись access.log:

2013/06/19 16:23:23 [error] 2216#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.ordercloud.lh"

А вот файл с сайтами:

server {
    set $host_path "/home/willem/git/console/www";
    access_log  /www/logs/console-access.log  main;

    server_name  console.ordercloud;
    root   $host_path/htdocs;
    set $yii_bootstrap "index.php";

    charset utf-8;

    location / {
        index  index.html $yii_bootstrap;
        try_files $uri $uri/ /$yii_bootstrap?$args;
    }

    location ~ ^/(protected|framework|themes/\w+/views) {
        deny  all;
    }

    #avoid processing of calls to unexisting static files by yii
    location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php {
        fastcgi_split_path_info  ^(.+\.php)(.*)$;

        #let yii catch the calls to unexising PHP files
        set $fsn /$yii_bootstrap;
        if (-f $document_root$fastcgi_script_name){
            set $fsn $fastcgi_script_name;
        }

        fastcgi_pass   127.0.0.1:9000;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;

        #PATH_INFO and PATH_TRANSLATED can be omitted, but RFC 3875 specifies them for CGI
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
    }

    location ~ /\.ht {
        deny  all;
    }
}

Мой / home / willem / git / console принадлежит www-data: www-data (мой веб-пользователь работает под управлением php и т. Д.), И я дал ему 777 разрешений из-за разочарования ...

Я думаю, что с конфигурацией что-то не так, но я не могу понять ...

ОБНОВЛЕНИЕ Итак, я переместил его /var/www/и использовал гораздо более простой конфиг:

server {
    #listen   80; ## listen for ipv4; this line is default and implied
    #listen   [::]:80 default ipv6only=on; ## listen for ipv6

    root /var/www/;
    index index.html index.htm;

    # Make site accessible from http://localhost/
    server_name console.ordercloud;

    location / {
        root           /var/www/console/frontend/www/;
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www;
            include        fastcgi_params;
    }

    location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
            try_files $uri =404;
        }

    location /doc/ {
        alias /usr/share/doc/;
        autoindex on;
        allow 127.0.0.1;
        deny all;
    }

}

Также, если я позвоню, localhost/console/frontend/www/index.phpя получу 500 PHP, что означает, что он там служит. Он просто не работает с console.ordercloud ...


Другая возможная причина: если вы используете php-fpm, убедитесь, что у пользователя, указанного в /etc/php-fpm.d/www.conf, есть разрешения для скрипта, который он пытается запустить. Я думаю, что по умолчанию Apache.
Дейв

Еще одна возможная причина, по которой ваш SElinux включен, проверьте конфигурацию SElinux и отключите его.
CK.Nguyen

Я просто переключил свою конфигурацию хоста с FCGId (запуск от имени владельца виртуального сервера) на FPM (запуск от имени владельца виртуального сервера). В дополнение к установке PhP 7.2-fpm, cli и многое другое ...
PauloBoaventura

Ответы:


92

Сообщение об ошибке «основной сценарий неизвестен» почти всегда связано с неверно установленной директивой SCRIPT_FILENAMEnginx 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 может обнаружить сразу.


1
Это решит это для меня; Я не знал, что вы должны префикс $ document_root, я предполагал, что это происходит автоматически, на основе root.
b01

3
Где можно узнать больше о плохой практике установки в rootпределах местоположения?
Дан Даскалеску

15
Для тех , кто не понимает , как именно переменная может быть неправильно: добавить в основной Nginx httpразделе следующее: log_format scripts '$document_root$fastcgi_script_name > $request';(или все , что вы питаетесь в SCRIPT_FILENAME), и к вашему server: access_log /var/log/nginx/scripts.log scripts. Перезагрузите и посмотрите на ваш новый журнал сценариев;)
igorsantos07


3
Что такое yii_bootstrap?
Любовь

43

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

Этот пример специфичен для Mac OS X , которая, по моему опыту, является самой сложной в настройке (Debian прост для сравнения) - я только что обновил PHP 5.6 до 7.0, используя homebrew и превосходные пакеты 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.


2
очень хорошо! это было для меня! Ура, приятель!
rollsappletree

Благодарю. Для меня у докеров fpm / nginx были проблемы с правами доступа к этим папкам.
Tek

@ Fleshgrinder ответ неправильный, а ваш правильный! В моем случае это действительно был только вопрос исправления владельца /etc/php/7.0/php-fpm.d/www.confфайла. Приветствую тебя, приятель. :) Многие другие люди могут начать видеть эту проблему также, поскольку бродячая популярность продолжает расти.
user392778

не могу найти что-то внутри /usr/local/etc/nginx/snippets/fastcgi-php.confна моем Mac .. но я нашел/usr/local/etc/nginx/fastcgi.conf
abbood

Хороший!!
Боролась

7

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

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

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


привет @ we0, у меня возникла та же проблема с моей настройкой. Я также запускаю другое приложение на порту 3001, поэтому мне нужно разместить мое php-приложение на порту 3002. Мой оригинальный пост можно посмотреть здесь: stackoverflow.com/questions/33229867/… и stackoverflow.com/questions/33409539/… а другой stackoverflow.com/questions/33519989/... . Есть ли у вас какие-либо идеи?
Маниш Сапкал

3
Автоматическое создание символических ссылок с сайтов, доступных для сайтов, было бы нежелательно. Вы должны создать эти символические ссылки, чтобы вы могли контролировать, какие сайты «включены», а какие «выключены» на вашем сервере.
Эратиэль

6

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


4

«Основной сценарий неизвестен» вызван контекстом безопасности 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

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

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

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

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

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


2

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

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


1

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

шаги:

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

vim /etc/selinux/config set SELINUX to disabled


0

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

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

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

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

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


0

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

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

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

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

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


0

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

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


0

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

sudo service php7.0-fpm restart

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

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

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


0

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

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

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


0

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

Я сокращал вики-адреса в соответствии с предписаниями MediaWiki, используя Bitnami / Nginx на Lightsail.

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

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

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

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

введите описание изображения здесь

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

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

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


-1

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

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

1
rootДиректива должна быть установлена на на serverоснове и не должны использоваться в любых locationблоках (если вы не профессионал и хотите , чтобы обойти некоторые особые Nginx ошибки в конфигурации).
Fleshgrinder

1
@Fleshgrinder один корень на сервер не лучшая практика.
Гарет Клаборн


@Fleshgrinder Это не то, что говорит раздел, который вы связали. Пример хорошей практики в этом разделе показывает rootдирективу внутри locationблока.
Ишигоя

@ishigoya, пожалуйста, перейдите по ссылке еще раз, несколько rootдиректив внутри нескольких locationблоков явно под заголовком BAD.
Fleshgrinder
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.