WSGIサーバーの前にリバースプロキシを配置するのはなぜですか？
WSGIアプリケーションを展開するための一般的な構成には、リバースプロキシとして機能する汎用Webサーバー（nginxなど）の背後にあるWSGIサーバー（uWSGIやGunicornなど）が含まれます。リバースプロキシを使用する主な理由の1つは、静的ファイルを効率的に提供することです。他に理由はありますか？
私のアプリケーションがPythonコードのみを含み、静的コンテンツを気にしないと仮定します。この場合、なぜリバースプロキシが必要なのですか？uWSGIとGunicornはそれぞれ、とインターフェイスできる非同期HTTPサーバーをすでに提供しています。クライアント。
WSGI HTTPサーバーを外部に直接公開したほうがよい実際的なケースはありますか？
本格的なリバースプロキシのようなより多くの設定オプションがあります
- リライト
- 場所
- サーバ
- https
- ヘッダーのクリーンアップ
- 有効期限が切れます
- gzip
- ..。
ロードバランシングを行うことができます
- proxy_cacheを使用できます
- アプリサーバーがダウンしている場合でも、カスタムエラーページを実装できます
- wAFを実装することができます
- あなたは（時々）脆弱性に対してホットパッチをかけることができます
[〜＃〜]ボーナスポイント[〜＃〜]
- 次の設定（nginx）を使用して、（平均ハードウェアで）100.000リクエスト/秒でクライアントに印象付けることができます。
。
location /perftest/ {
return 200;
}
リバースプロキシを使用することの追加の利点。
あなたに利益をもたらすかもしれない他の利益を得ることができます。
- インターネットから情報を隠すことができます（Webサーバーのバージョン、アプリサーバー、データベースサーバー、API）
- 1つのドメインの背後に複数のWebサーバーテクノロジを実装できます（Linux Tomcat + Windows IISなど）
- Https/SSL接続を終了し、それらを内部httpサービスにマップできます。
- すべてのロギングを一元化できます。
- すべてのDDOS防止を一元化できます
- Webサーバー層からID管理を実装できます。
セキュリティ上の利点
- 上記のように隠れている内部サーバー。
- ホスト上のソフトウェアファイアウォール（DMZと呼ばれる）に頼ることなく、インターネットから内部アプリサーバーサーバーとデータベースサーバーをルーター/ファイアウォールで保護できます。
- 既知の問題（Webアプリケーションファイアウォール）または既知の攻撃パターンから、すぐに修正できないサーバーを保護できます。