環境: nginx のバージョンは 1.2.6
最近、プロジェクトの作業中に奇妙な問題が発生しました。URL を再設計したかったため、次の nginx 書き換えルールを使用しました:
この書き換えルールはよく使われているので、何か問題があるのか分かりません~(アドバイスをお願いします)
これらのルールを使用しなかった場合、サーバー上の既存のディレクトリにアクセスすると自動的にスラッシュが追加されますが、このとき nginx の自動書き換えルールがトリガーされましたが、これは正常で問題ありません。
しかし、上記のルールを追加すると、サーバー上に既に存在するフォルダーにアクセスするときにスラッシュが自動的に追加されなくなります。さらに、テストを繰り返した結果、2 番目と 3 番目のルールが問題を引き起こしていることがわかりました:
1. 2 番目のルールのみを削除すると、フォルダーが存在するかどうかに関係なく、フォルダーは存在しないと検出され、スラッシュは追加されず、3 番目のルールに直接入力され、最終的に一致します。これにindex.phpを入力すると、この時点でファイル単位で処理されていることが分かります。
2. 2 番目のルールが削除された場合、3 番目のルール -f
のファイルの判定は -e
、つまりファイルまたはフォルダー:
これで問題は解決しました、ディレクトリが存在すれば自動でスラッシュが追加され、存在しなければそれに合わせてindex.phpと入力します。
非常に混乱しています。アドバイスをお願いします。なぜこのようになるのでしょうか?
さらに、プロジェクトの元々の問題により、3 番目のルールには他の対象となる書き換えルールが多数あるため、入力フォルダーが存在し、それが存在する場合は 3 番目のルールを入力したくありません。パフォーマンスへの影響は大きくありませんが、ルールに一致します。
大家讲道理2017-05-16 17:31:15
多くのテストの後、私はそれを自分で理解しました。
これら 3 つのルールには何も問題はなく、前に述べたように 2 つ目もおかしくありません。
まず、入力したパスが存在し、末尾にスラッシュが含まれていない場合、nginx はユーザー定義のルールに従って照合します。
私のフォルダーにはindex.phpが存在するので、
、その後のマッチングを実行します。言い換えれば、このフォルダーが存在し、このフォルダー内にindex.htmlまたはindex.phpが存在する限り、上で示した1番目または2番目のルールに一致することに疑いの余地はありません。 $request_filename/index.php
匹配第二条规则成功,注意这里的/
このルールの意味は、フォルダーが存在し、スラッシュがない場合、自動的にスラッシュが追加され、301 ジャンプが実行され、問題は解決されるということです。
过去多啦不再A梦2017-05-16 17:31:15
最後のロジックは、前の条件が満たされない場合、つまり「アクセスされたパスがファイルでない場合」に、自動的に /index.php にジャンプするというものです。
提案: 3 番目の項目の前に文 -e を挿入して、フォルダーであるかどうかを確認し、フォルダーである場合は、自動的にスラッシュとブレークを追加します。
テストは行っておりませんので、参照のみを目的としています。