質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Laravel

LaravelとはTaylor Otwellによって開発された、オープンソースなPHPフレームワークです。Laravelはシンプルで表現的なシンタックスを持ち合わせており、ウェブアプリケーション開発の手助けをしてくれます。

nginx

nginixは軽量で高性能なwebサーバーの1つです。BSD-likeライセンスのもとリリースされており、あわせてHTTPサーバ、リバースプロキシ、メールプロキシの機能も備えています。MacOSX、Windows、Linux、上で動作します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Laravel 5

Laravel 5は、PHPフレームワークLaravelの最新バージョンで、2014年11月に発表予定です。ディレクトリ構造がが現行版より大幅に変更されるほか、メソッドインジェクションやFormRequestの利用が可能になります。

Q&A

解決済

1回答

591閲覧

NginxとLaravelで40%程の確立で404が返却され、60%程正常に処理が動作する

zahst7

総合スコア11

Laravel

LaravelとはTaylor Otwellによって開発された、オープンソースなPHPフレームワークです。Laravelはシンプルで表現的なシンタックスを持ち合わせており、ウェブアプリケーション開発の手助けをしてくれます。

nginx

nginixは軽量で高性能なwebサーバーの1つです。BSD-likeライセンスのもとリリースされており、あわせてHTTPサーバ、リバースプロキシ、メールプロキシの機能も備えています。MacOSX、Windows、Linux、上で動作します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Laravel 5

Laravel 5は、PHPフレームワークLaravelの最新バージョンで、2014年11月に発表予定です。ディレクトリ構造がが現行版より大幅に変更されるほか、メソッドインジェクションやFormRequestの利用が可能になります。

0グッド

1クリップ

投稿2019/02/04 03:22

前提・実現したいこと

現在、nginxとLaravelでサーバサイド(RestFul)の処理を作成中です。
php-fpmを使用してphpを動作させています。
ルーティングや、リダイレクト、phpの実行等は問題なく出来ているのですが、
アクセスする際に40%程404エラーで「File Not Found」が返却されます。
60%は問題なく200なり、こちらで設定している404で値も返却されております。
解決方法を教えていただきたくご質問させていただきます。

基本中の基本や、質問が過去にもあり被っていましたら申し訳ございませんが、
ご回答いただけますと幸いです。

試したこと

404がキャッシュされているのかとも思い、キャッシュは一度削除しております。
現象解決されませんでした。
何日経過しても解決しないため、キャッシュでは無いようです。

補足情報(FW/ツールのバージョンなど)

nginx: 1.15.7
php: 7.2.14

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

CHERRY

2019/02/04 04:37

nginx のログでは、どうなっているのでしょうか? 同じように 40% が 404 で、残りが、200 ですか? 404の場合にエラーログに何か出力はありますか?
zahst7

2019/02/04 05:07

404の場合にaccesslogには HTTP/1.1" 404 27 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" errorログには *3262 stat() "{ディレクトリフルパス}" failed (13: Permission denied), client: 49.241.164.68, server: {ドメイン}, request: "GET {アクセスパス} HTTP/1.1", host: "{ドメイン}" 2019/02/04 14:03:00 [crit] 10420#10420: *3262 stat() "{ディレクトリフルパス}" failed (13: Permission denied), client: {クライアントIP}, server: {ドメイン}, request: "GET {アクセスパス} HTTP/1.1", host: "{ドメイン}" 2019/02/04 14:03:00 [error] 10420#10420: *3262 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: {クライアントIP}, server: {ドメイン}, request: "GET /api/pay HTTP/1.1", upstream: "fastcgi://127.0.0.1:{fastcgiのポート}", host: "{ドメイン}" 以上のように出力されています。
CHERRY

2019/02/04 05:15

` FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream ` や ` {ディレクトリフルパス}" failed (13: Permission denied) ` と出ているようですので、設定や権限を見直した方がよいと思われます。
zahst7

2019/02/04 08:00

CHERRYさん ありがとうございます。 Permissionの件は、404エラーとは関係ないようですが権限見直し解決致します。 また、確認を続けたところ、 17514#17514: *21 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: {クライアントIP}, server: {ドメイン}, request: "GET {アクセスパス} HTTP/1.1", upstream: "fastcgi://127.0.0.1:{fastcgiポート}", host: "{ドメイン}" 404が発生する際には、このエラーが共通で出ておりました。 ただ、正常にアクセスされた際にはこのエラーが出力されません。 同じアクセス先にアクセスし、nginxの設定も何も変更していないにも関わらず今回のエラーが発生しております。
CHERRY

2019/02/04 09:32

情報が少ないので判断できませんが、リソース不足等はないですか?
zahst7

2019/02/05 04:54

特にリソース不足というわけでもないようです。 現在、php-fpmを一度停止し再起動したところ100%の確率で404エラーが発生するようになりました。 何から中途半端だったようです。 原因はPermissionエラーによってPrimary scriptにアクセスできない事のようです。 ただ、対象のフォルダはdocumentrootであり、一時的に「777」のパーミッションを設定しているため、今なお解決できておりません。
CHERRY

2019/02/05 05:07

ディレクトリやファイルのパーミッションの影響だとすると php のエラーは、php-fpm のログに記録されると思いますので、php-fpm のログファイル /var/log/php-fpm/error.log や /var/log/php-fpm/www-error.log (wwwの部分は設定により異なります) に詳しい情報はないでしょうか?
zahst7

2019/02/05 05:51

確認したところ、phpの稼働まで行っていないようです。 php-fpmのログには本日のものは何もありませんでした。
zahst7

2019/02/05 06:41

CHERRYさん、色々ご返信、ご返答いただきありがとうございました。 結果として、なぜ時々正常動作していたのか?のほうが不思議な事が判明しました。 home配下をdocumentrootとして設定しておりましたので、対象ユーザのグループにnginxユーザを加入させ、アクセス件をグループにも与えなければいけない。基本ですが、ユーザの~(ホームディレクトリ)の権限設定が行われておりませんでした。そのためPermissionエラーでdocumentrootにアクセスできない。という状況でした。 そのためユーザの~(ホームディレクトリ)の権限の内グループ権限を設定したところ、正常に動作しました。 良く分からない正常動作のせいで遠回りをしてしまいました。 お付き合いをいただきありがとうございました。なぜ正常に動作するタイミングがあったのか?は判明しておりません。同じ現象を発生させることはその後できませんでした。 ありがとうございました。
guest

回答1

0

自己解決

最終的に自己解決しました。

結果として、なぜ時々正常動作していたのか?のほうが不思議な事が判明しました。

home配下をdocumentrootとして設定しておりましたので、対象ユーザのグループにnginxユーザを加入させ、アクセス件をグループにも与えなければいけない。基本ですが、ユーザの~(ホームディレクトリ)の権限設定が行われておりませんでした。そのためPermissionエラーでdocumentrootにアクセスできない。という状況でした。
そのためユーザの~(ホームディレクトリ)の権限の内グループ権限を設定したところ、正常に動作しました。

良く分からない正常動作のせいで遠回りをしてしまいました。
お付き合いをいただきありがとうございました。なぜ正常に動作するタイミングがあったのか?は判明しておりません。同じ現象を発生させることはその後できませんでした。

ありがとうございました。

投稿2019/02/05 06:42

zahst7

総合スコア11

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問