Nginxの前段に置くならどっち？uWSGI構成とGunicorn構成の実務比較
uWSGI構成はNginxとuWSGIプロトコル、Gunicorn構成はNginxとHTTPでつなぐ。要はプロトコル設計と運用作法の違いである。
何が違うのか（最小構成の図）
この図が示すのは単純で、Nginxから上流サーバへ渡すプロトコルが異なるという事実だ。uWSGI構成はuwsgi_passでuWSGIプロトコル、Gunicorn構成はproxy_passでHTTPを話す。どちらもUNIXソケットでつなげる点は同じだが、デバッグ方法やヘッダ取り扱い、可観測性のツボが変わる。
プロトコル差がもたらす実務的な違い
-
ヘッダとメタ情報の扱い
uWSGI構成ではuwsgi_param群でWSGI環境変数にマッピングする。一方、Gunicorn構成はHTTPのまま渡すのでproxy_set_headerで素直に制御できる。CDNやAPIゲートウェイと並べる時、HTTPのほうが知識の再利用が効く。 -
ツール互換とデバッグ
HTTPはcurlやブラウザ拡張でそのまま観測でき、アクセスログも一般的な形式になりやすい。uWSGIプロトコルは専用知識が要るが、きめ細かなuWSGI機能（オフロード、mule等）を活用できる。 -
WebSocketと将来拡張
FlaskはWSGIのためWebSocket自体は扱えないが、将来的にASGIへ移る可能性があるならGunicorn構成はUvicornWorker等で移行しやすい。NginxはUpgradeヘッダ等のパススルー設定が必要だがHTTP系の知識で完結する。 -
パフォーマンスの肌感
uWSGIプロトコルは軽量で実装が成熟しており、超高負荷のWSGI運用で微差の強みが出ることがある。とはいえ多くの業務アプリではHTTPプロキシとの差は誤差内で、運用容易性が勝つことが多い。
起動とプロセス管理の観点
コンテナでの管理は大きく二択。1プロセス原則に従い、アプリサーバだけをPID1にし、NginxはIngressやGatewayに任せる。もしくはNginxとアプリサーバを同居させ、tini等でシグナルを正しく中継する。どちらでも、優雅停止と標準出力へのログ集約を意識すると運用が安定する。
比較表（同じ階層のもの同士）
| 項目 | uWSGI構成 Nginx→uWSGI | Gunicorn構成 Nginx→Gunicorn |
|---|---|---|
| Nginxの上流ディレクティブ | uwsgi_pass | proxy_pass |
| 上流プロトコル | uWSGI独自 | HTTP 1.1 |
| ヘッダ制御 | uwsgi_paramでWSGI環境に写像 | proxy_set_headerでHTTPヘッダ直制御 |
| ソケット | UNIX or TCP どちらも可 | 同左 |
| 静的配信 | Nginx aliasで同様 | 同左 |
| WebSocket適性 | WSGI前提のため工夫が必要 | ASGI移行時にUvicornWorker等で素直 |
| 並行性モデル | 多様 uWSGI emperor mule等 | workers種別が豊富 gthread geventなど |
| デバッグ容易性 | 専用知識寄り | HTTP生態系で容易 |
| 可観測性 | 専用メトリクスが多い | HTTP系メトリクスを横展開しやすい |
| パフォーマンス | 高負荷WSGIで微有利な場面あり | ほぼ同等が多い 運用で勝負 |
| 設定学習コスト | やや高め | 低め 既存知識が効く |
| 将来拡張 | 既存WSGIを磨く方向 | ASGI移行含め選択肢が広い |
| 運用の型 | 老舗のやり方が豊富 | K8sやAPIゲートウェイと馴染む |
最小サンプル
uWSGI構成の例
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/uwsgi.sock;
}
Gunicorn構成の例
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_pass http://unix:/tmp/gunicorn.sock;
}
どちらを選ぶかの目安
- Gunicorn構成を選ぶ: まずはHTTPでシンプルに回したい、K8sやGatewayと親和、将来ASGIへ拡張したい。チームの共通知識を活かしやすく、障害対応も読みやすいログに寄せやすい。
- uWSGI構成を選ぶ: 既存の安定運用があり、uWSGIの細かな機能を使い込んでいる、超高負荷WSGIで最後の数パーセントを詰めたい。
結論として、多くの現代的なWebバックエンドではNginx→Gunicorn HTTPがデフォルトの第一手になり、要件次第でNginx→uWSGIを選ぶ、という順番で考えると判断が速い。