Nginx は URI を php5-fpm に渡さず、代わりにテキスト ファイルとして機能します

Nginx は URI を php5-fpm に渡さず、代わりにテキスト ファイルとして機能します

上で述べたように、URI は nginx に渡されていません。これを示すために、「try」ブロック全体を含めました。

location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    set $page_to_view "/index.php";
    try_files $uri $uri.php $uri/;
    # Uncomment to enable naxsi on this location
    # include /etc/nginx/naxsi.rules
}

つまり、本質的には「ああ、$uri.php を実行し、そのファイルが存在するので、実際に php に送信するのではなく、サーバーに送ってみましょう」と言っていることになります。

私の fpm の部分は以下の通りです。

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
#   # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

#   # With php5-cgi alone:
#   fastcgi_pass 127.0.0.1:9000;
#   # With php5-fpm:
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

ほぼ標準です。私が理解できないのは、なぜ nginx がもうそれを実行しないのかということです。Debian では fastcgi で動作していたことは知っていますが、今は動作しません。また、HDD クラッシュにより古い構成ファイルを失ってしまいました。これは、ドライブを返送する前にバックアップしなかった唯一のファイルです。書き直してもまったく問題ないと思ったからです。

答え1

どの URI を読み込もうとしているのかはわかりませんが、 で終わっていないと想定します.php

try_filesここでの問題は、その命令を文字通りに受け取っていないことです。具体的には、ファイル。これはtry_files file ... uri;、最後の引数のみがフォールバックとして扱われ、内部書き換えが発生することを意味すると文書化されています。最後の引数の前の引数はすべて静的ファイルとしてテストされ、見つかった場合は静的ファイルとして提供されます。

これは、できるtry_files $uri $uri/ $uri.php;ができないことを意味しますtry_files $uri $uri.php $uri/

答え2

交換してみる

location ~ \.php$ {

location ~ \.php {

$document_root には、php ファイルが配置されている実際のディレクトリを指定します。

例えば

fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;

関連情報