Nginx 1 FastCGIがstderrで送信：「プライマリスクリプトが不明」

初めて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などを実行しているWebユーザー）が所有しており、フラストレーションから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を提供していないだけです...

「プライマリスクリプトが不明です」というエラーメッセージは、ほとんどの場合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は比較することによって簡単です） -私はちょうど使用して、7.0にPHP 5.6からアップグレードした自作と優れたホセ・ゴンザレスパッケージ。

問題は、構成ファイルの新しいコピーが作成されたことです。

メインの設定ファイルはですが/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ます。

これには、重要なSCRIPT_FILENAMEを含む設定の/usr/local/etc/nginx/fastcgi.confリストが含まれfastcgi_paramます。

rootPHPロケーションブロックで複製しないでください。

それでは、1日苦労して見つけた3つのこと

1. 何らかの理由で、すでにポート9000で何かが実行されていたため、9001に変更しました
2. デフォルトのサイトが新しいサイトをインターセプトしていましたが、なぜそうすべきではないのか理解できませんが、リンクを解除するだけです
3. Nginxは、サイトが有効なサイトのsymリンクを自動的に行いません。

これが誰かのトラブルを救うことを願っています！

新しいnginx（v1.8）でも同じ問題がありました。新しいバージョンでは、のsnippets/fastcgi-php.conf;代わりにを使用することをお勧めしますfastcgi.conf。したがってinclude fastcgi.conf、チュートリアルからコピー/貼り付けするとPrimary script unknown、ログにエラーが記録される場合があります。

「プライマリスクリプトが不明」は、SELinuxセキュリティコンテキストが原因です。

クライアントは応答を得ます

ファイルが見つかりません。

nginx error.logには次のエラーメッセージがあります

* 19 stderrで送信されたFastCGI：上流からの応答ヘッダーの読み取り中に「Primary script unknown」

Webルートフォルダのセキュリティコンテキストタイプをhttpd_sys_content_tに変更するだけです

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

nginx / php-fpm configには3人のユーザーがいます

/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ソケットの場合、user-1はuser-3と同じである 必要があります。nginxfastcgi_passには、unixソケットに対する読み取り/書き込み権限が必要です。

そうしないと、nginxは502 Bad Gatewayを取得し、nginx error.logに次のエラーメッセージが記録されます。

* 36上流への接続中にunix：/var/run/php-fpm/fpm-www.sockへのconnect（）が失敗しました（13：許可が拒否されました）

また、Webルートフォルダーのユーザー/グループ（/ var / www / show）は、これら3人のユーザーのいずれかと同じである必要はありません。

私もこの問題を抱えていましたが、ラインinclude fastcgi_paramsとを交換することで解決しましたfastcgi_param SCRIPT_FILENAME ...。

実際、nginxは各FastCGIパラメーターの最後の値を設定するため、fastcgi_paramsに含まれるデフォルト値の後に値を配置する必要があります。

CentOS7.3システムでSELINUXを閉じることでこの問題を解決しました

手順：

• 幹部 setenforce 0
• Uは設定ファイルも変更する必要があります

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/"

問題は私にとって消えた。似たようなことができるかもしれません

私は同じ質問に答えますが、他の方法では質問を解決できませんでした！

私はそれを解決し、キーは次のとおりであることがわかります： Linuxユーザー権利が質問につながる：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

リモートサイトを複製し、既存のwp-config.phpにリモートサーバーデータベース情報が含まれていました。

ローカルのデータベース情報を使用して、ローカルのワードプレス設定をセットアップすることで、この問題を解決しました。

上記のすべてを実行しましたが、頭を叩いて2時間を失いましたが、問題は解決しませんでした。最後に私がやった：

sudo service php7.0-fpm restart

そしてビオラはうまくいきました！

ところで、私はリンクからhttps://symfony.com/doc/3.4/setup/web_server_configuration.htmlからnginx confで新しいsymfony 3.4プロジェクトを設定していました

これが新しいsymfonyプロジェクトを開始する5回目であり、この「プライマリスクリプト不明」が起こっているとは信じられませんでした。

php-fpm sockファイルのアクセス許可を確認してください。どういうわけかアクセスできませんでした。

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

その後、nginxを再起動してください。

私は非常に長い間、この奇妙なメッセージに囚われています。すべてがしばらく動作し、その後突然動作が停止したため、原因がわかりません。

LightsailのBitnami / Nginxを使用して、MediaWikiで規定されているWiki URLを短縮していました。

多くの投稿を検索して読んで、これはすべての可能なシナリオを要約しているようで、私はそれらすべてを試しました：

• nginxは問題ありませんが、ルートフォルダーphpは機能していますが、サブフォルダーは機能していません
• nginxではなく、404 +裸の文字列「File not found」としてスローされるエラー
• rootサーバーに追加、機能しませんでした
• フォルダーとphp-fpm / nginxのアクセス許可を確認します。ルートとサブフォルダーは同じです。
• エラーコードの解釈についてはphp-fpmマニュアルを確認してください。見つけられませんでした
• php-fpmアクセスログをオンにし、リクエストURIが正しいことを発見したが、404が返される
• php-fpmの詳細/デバッグモードを有効にしようとしましたが、動作しませんでした。想定されるエラーログファイルは常に空です

だから私は、ルートフォルダのPHPが動作し、サブフォルダれたため、最後の手段を試していた、それらの間の唯一の大きな違いはありませんでした以外のrootルートフォルダが使用されている$request_filenameとサブフォルダの場所を使用$document_rootして$fastcgi_script_name、私は、ルートフォルダのものと一致するサブフォルダの場所の設定を変更しました。

それがうまくいった... なぜそれがうまくいったのかまだわかりません。php-fpmアクセスログを確認すると、同じURIが表示されるため、1つは404で、もう1つは200でした。

唯一の違いは構成にありました。それらは同じ出力を生成するため、なぜ結果が異なるようになったかはわかりません。

とにかく、ここに2セントを投稿することにしました。

PS：PHPがより良いエラーメッセージと詳細モードを提供することを本当に望んでいます。なぜなら、これは問題を切り分けられず、詳細な出力とデバッグ情報を見ることができないために本当にイライラするからです。

phpの場所にルートディレクティブを追加してみてください。

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