私はその問題に数時間を費やしており、それに関連する多数の投稿にもかかわらず、私はそれを解決することはできません。私はFedora 20ボックスにNginx + PHP-FPMを搭載しており、今日まで(php-fpm.serviceをリロードした後だと思いますが)かなりうまく機能しました。 Nginxは静的ファイルを問題なく提供していますが、PHPファイルはエラー403をトリガーします。
パーミッションはOKで、nginxとphp-fpmはユーザー「nginx」で実行されています。
root 13763 0.0 0.6 490428 24924 ? Ss 15:47 0:00 php-fpm: master process (/etc/php-fpm.conf)
nginx 13764 0.0 0.1 490428 7296 ? S 15:47 0:00 php-fpm: pool www
nginx 13765 0.0 0.1 490428 7296 ? S 15:47 0:00 php-fpm: pool www
nginx 13766 0.0 0.1 490428 7296 ? S 15:47 0:00 php-fpm: pool www
nginx 13767 0.0 0.1 490428 7296 ? S 15:47 0:00 php-fpm: pool www
nginx 13768 0.0 0.1 490428 6848 ? S 15:47 0:00 php-fpm: pool www
提供されたファイルもnginxユーザーに設定されており、これらのファイルを試してみるために777のchmodingを終了しましたが、すべてのPHP=.
以下は私のNginx設定のサーバーです:
server {
listen 80;
server_name localhost;
root /var/www/html;
location ~ \.php$ {
fastcgi_intercept_errors on;
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;
}
}
PHP-FPMプール:
[www]
...
listen = 127.0.0.1:9000
user = nginx
group = nginx
...
バージョンの場合:
php-5.5.11(もちろんphp-fpm-5.5.11も)
nginx-1.4.7
私はNginxエラーログを追加しています:
FastCGI sent in stderr: "Access to the script '/var/www/html' has been denied (see security.limit_extensions)" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", Host: "xxx.xxx.xxx.xxx"
そしてその正確なsecurity.limit_extensions
は正しい、に設定:security.limit_extensions = .php
。
パス許可については、/ var/www/htmlをたどることができます。私は何が欠けていますか?
考えられる解決策は次のとおりです。
Php-fpm www.confで、_security.limit_extensions
_を_.php
_または_.php5
_に設定するか、環境に適したものに設定します。一部のユーザーにとっては、すべての値を完全に削除するか、FALSE
に設定することが唯一の方法です。
Nginxの設定ファイルで、サーバーアドレスとポートではなく、_fastcgi_pass
_をソケットアドレス(たとえば、_unix:/var/run/php-fpm/php-fpm.sock;
_)に設定します。
_SCRIPT_FILENAME
_ fastcgiパラメーターを確認し、ファイルの場所に応じて設定します。
Nginxの設定ファイルで、他のすべてのfastcgiパラメーターが定義されている場所ブロックにfastcgi_split_path_info ^(.+\.php)(/.+)$;
を含めます。
Php.iniで_cgi.fix_pathinfo
_を_1
_に設定します
上記の解決策(_cgi.fix_pathinfo
から1
)はひどいアイデアです。 https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ を参照してください良い概要。
問題はおそらく、PATH_INFOに依存するアプリケーションに起因します。この問題のデバッグに役立つアプリケーションの呼び出し方法に関する詳細情報を取得するには、PHPのアクセスロギングを有効にします。
繰り返しになりますが、受け入れられる解決策はひどいアイデアであり、おそらくサイトがハッキングされる可能性があります。
Php.iniを変更した後、php5-fpmサービスを再起動することを忘れないでください!!
service php5-fpm restartまたはservice php5-fpm reload
fpmはphp5を事前起動するため、nginxを再起動して変更を適用するだけでは不十分です。
これは、vhostドキュメントルートにindex.php
がない場合にも発生する可能性があります。
Nginx設定のwww_root
パラメーターを慎重に再確認してください。次に、ヒットしようとしているphpファイルが実際にそこにあることを再確認します。
私の場合、vhost docのルートパスを誤って入力したため、空のディレクトリをポイントして403を生成しました。
後で来るものの参照のために:あなたのサイトのconfに以下を追加してみてください:fastcgi_param PATH_INFO $ fastcgi_path_info;また、SELinuxが実行していることも確認してください。無効にするには:setenforce 0ただし、問題のスクリプトを把握し、setenforce 1に戻します
selinuxに関連している可能性があります。 共有フォルダーの仮想ボックスを使用する場合、Linuxでこのフォルダーのアクセス許可を変更することはできません。したがって、selinuxを閉じてから解決できます。