No input file specified絶望的なバックエンド環境展開問題をメモします。

背景は他の人から引き継ぎます。laravelに基づいて、開発環境はLNMPです。今はこのプロジェクトを自分のサーバーに展開します。LNMPを使ってパッケージをインストールして、サーバーにlnmp環境を配置して、それから引き継ぎの項目をディレクトリに解凍します。nginxのserverブロックを配置した後、ブラウザでテストしてエラーを発見します。
No input file specified.
このとき、Chromeの開発者ツールには、リターンコード404が表示される。
*解決案は直接に博文を参照することができます。
問題の分析

経験に基づいて、まずinxのindex命令配置を確認します。indexコマンドが正しく構成されていることを確認します。

この時、ウェブサイトのルートディレクトリの下でindex.を新規作成して正常にアクセスします。これにより、nginxの構成が正しいと考えられます。php-fpmの構成が間違っています。

は、php-fpmが正常に起動しているかどうかを確認します。inxでは、php-fpmを9000ポートに転送しますので、通常の状況では、php-fpmを起動し、900ポートの検査結果をモニタします。この時、ウェブサイトのルートディレクトリの下でtest.phpを新規作成し、test.phpを要求します。問題は依然として

です。
No input file specified
test.php内容はlaravelフレームワークに依存せず、laravelフレームワークに問題が発生する可能性を排除することができる。

//test.php
 phpinfo();
?>

検索で、複数の記事がfastcgiのパラメータ（fastcgigauaram）SCRIPT_を指摘しています。FILENAMEの設定が間違っていると、php要求応答404の問題が発生します。変数SCRIPT_を印刷するために、nginx.com nfにログフォーマットを追加します。FILENAME、ログを印刷して、この変数が正常であることを確認します。

ディレクトリの権限の問題かもしれません。wwwユーザがログイン可能（php-fpmの実行時にユーザがwwwに設定されています。バックグラウンドアプリケーションとユーザ権限の設定については、このブログを参照してください。）を修正して、現在のユーザーをwww

に切り替えます。

su www

テスト結果はwwwで、ルートディレクトリの下のすべてのphpファイルを正常に読み込むことができます。

偶然にlnmpツールが確立したデフォルトserverが正常にphp要求に応答することができることを発見しました。正常なserverブロックと異常なserverブロックを確認して、構成問題を基本的に排除します。

は、ウェブサイトのルートディレクトリを現在設定されている上位のディレクトリに変更して、test.phpを新しいウェブサイトのルートディレクトリの下に置くことを試みています。このとき、このファイルを正常に要求することができます。

test.phpをウェブサイトのいずれかの非元の設定（publicディレクトリ）に置いても、url正常要求

によっても良いです。

このとき、publicディレクトリに限ってPHPファイルが正常に応答しないと判定されました。これにより検索禁止指定ディレクトリ実行php.複数の記事を見て、nginxのdenyコマンドマッチング要求によって制限されるという考えが多くなりました。nginx配置を確認しても、関連フィルタ構成が発見されていません。また、以前に複数の異なるurlを使って同じファイルにアクセスしてもエラーが発生しました。基本的には、nginx要求制限問題を排除することができる

.ディレクトリ名をpubに変更しようとしましたが、正常に要求できませんでした。基本的にはinxまたはphpにディレクトリブラックリストが設定されている可能性があります。

ここを考慮して、publicの下で特定のファイルの制限があると疑って、

を使ってアクセスします。

ls -ahl

httaccessとweb.com figが存在しますが、この2つのファイルはnginxによってサポートされていません。

は、publicディレクトリの新規作成を試み、既存のpublicディレクトリの下のファイルを全部新しいpublicにコピーし、test.phpを

に入れます。

cp -R pub/* public/

新しいpublicの下のtest.phpを要求してみて、正常に要求に応答することができます。index.phpにアクセスしても、正常に応答できます。

ウェブサイトのルートディレクトリを変更するのはpublicで、問題の解決は

です。

既存プロジェクトファイルをバックアップし、テストファイルを削除し、問題ファイルのバックアップを検討する必要がある

。

デスクトップマシン（Windows 10）でファイルを開くと、元のpublicディレクトリの下に存在する.user.iniファイルが見つかりました。ファイルの拡張子の名前で.iniはその確率がphpの配置ファイルであることが分かります。検索の

問題が解決する
参考博文は.user.iniのドキュメントから知ることができます。これは各ディレクトリに分布しているphp.iniに相当します。あるディレクトリに対してphp-fpmの特定の配置項目を個別に配置して、部分.httaccessファイルの機能を実現できます。
既存のプロジェクトファイルの中のuser.iniを開くと、open_basedirが指定されていて、私のサーバとのパスが一致しないため、php-fpmがディレクトリの下でphpを実行することを拒否した場合。
また、元のpublicディレクトリの下のファイルを新しいpublicディレクトリにコピーする時、user.iniを新しいディレクトリにコピーしませんでした。だから、正常に要求に応じることができます。
問題のまとめ
本来は問題点に位置づけられていましたが、shellを使っていても気づかなかったです。user.iniという異常ファイルは、Windowsに隠されていません。user.iniで、設定ファイルとしてiniファイルを使っています。この特殊なファイルに気づいたのです。
また、phpの配置が不明で、この問題はなかなか見つからない。
PHP 5.3.0から、PHPは各ディレクトリに基づくhttaccessスタイルのINIファイルをサポートします。このような書類はCGI／FastCGI SAPIのみで処理されます。この機能はPECLのhttscanner拡張を無効にします。Apacheを使えばhttaccessファイルと同じ効果があります。
PHPマニュアルを前に配置すれば、この問題は早く解決できるでしょう。