Nginx ポート競合を解決するトラブルシューティング方法の例

問題の説明

データ転送に Nginx を使用し、フロントエンドとバックエンドが分離された Spring + Angular プロジェクト。

Nginx はポート 8100、フロントエンドポート 4200、バックエンドポート 8080 をリッスンします。

いつものように、事前に MySQL と Redis を設定し、プロジェクトの Nginx 設定ファイルをインポートしてから、フロントエンドとバックエンドを正常に起動します。

その後、問題が発生しました。フロントエンドによって開始されたリクエストのうち、バックエンドで受信できるのはごく少数で、そのほとんどが 404 でした。ブラウザをクリックすると、コンソールに 404 が表示され続けました。

404 だけの場合、問題は非常に単純で、Nginx ポート転送設定が間違っている可能性が非常に高くなります。しかし、魔法のようなのは、バックグラウンドに到達できるリクエストがまだいくつかあるということです。

(上の画像では、保存が成功すると、背景に関連するコンソール情報が出力されます)

他の友達はこの問題を抱えていなかったので、私は調査を始めました。

トラブルシューティングのプロセス

バックエンドの問題なのか、 Nginx転送の問題なのかを判断するには、まずブラウザのネットワークから、404 がバックエンドから返されたのか、Nginx から返されたのかを確認する必要があります。

確認してみると、Nginx によって返されたことがわかりました。バックグラウンドが 404 を返す場合、エラー情報が HTTP リクエストヘッダーに書き込まれます。

まず、リスニングポートに競合がないか確認します。nginx -T を使用して、インポートされた外部ファイルを含む完全な Nginx 構成ファイルを表示します。

// 設定ファイルが正しいかどうかをテストし、完全な設定ファイルを出力します nginx -T

出力結果には 8100 のみが表示されており、複数のプロジェクトが導入されているにもかかわらず、リスニングポートの競合がないことがわかります。

次に、Nginx ログからいくつかの手がかりを探す予定です。

Nginx のログモードをオンにした後、ログファイルを確認すると、数千件のアクセスレコードが見つかりました。

大部分は 404 で、いくつかは 200 ですが、ログにはそれほど役立つ情報は提供されません。

最終的に、構成ファイルに問題が見つかりました。

HomeBrew を使用してインストールされた Nginx の場合、グローバル構成ファイルのデフォルトのリスニングポートは 8080 であり、プロジェクトバックエンドが占有するポートも 8080 です。

ポート監視とポート占有の原理についてはよく分かりませんが、少なくとも、Nginx はポート 8080 を監視するため、一部のリクエストは Nginx 自体に送信され、他の部分はバックグラウンドに送信されることは分かっています。

したがって、グローバル構成ファイルを変更し、デフォルトのポートを変更すると、問題は解決します。

// 設定ファイルを変更する sudo vim /usr/local/etc/nginx/nginx.conf
// テスト設定ファイル nginx -t
// Nginxを再起動
nginx -s リロード

最後に、すべてのリクエストがバックエンドに到達できるようになります。

要約する

XAMPP を学び始めた頃、「ポート 80 で競合がある場合は、ポートを変更してください。たとえば、8080 に変更してください」とよく聞きました。

しかし、8080 が習慣になると、いくつかのプロジェクトでもこのポートが使用されるようになるため、競合の問題を解決する必要があります。

将来的にデフォルトポートを変更する場合は、プロジェクトのポートとの競合を避けるために、10000 を超えるポート番号など、使用される可能性が低いポートに変更することをお勧めします。

Nginx ポート競合を解決するためのトラブルシューティング方法の例については、これで終わりです。Nginx ポート競合のトラブルシューティング方法についての詳細は、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: