Nginx と upstream と SSL(https) とロードバランシング

HTTPリクエストのヘッダフィールド「Host」について - Qiita

HTTP/HTTPSについて学んだことまとめにて HTTP/HTTPSについて学んだことを書きとめたが、HTTPリクエストのヘッダフィールド「Host」について理解ができていなかったため、再度学習。簡単にメモります。 Hostとは...

qiita.com

Apache や nginx などの http サーバーは、リクエストの Host ヘッダーを見てどの virtual host としての処理を行うかを決定する。

What does upstream mean in nginx?

upstream app_front_static { server 192.168.206.105:80; } Never seen it before, anyone knows, what it means?

stackoverflow.com

proxy_pass の指定により、 nginx は他サーバーへの L7 のリバースプロキシとして動作する。 ここで通常は、 Host ヘッダには $host を設定しておくことが多く、これにより、上流側でも nginx が受け取ったリクエストの Host と同じ Host に対するリクエストとして処理を行う。

location / {
  # ...
  proxy_set_header Host $host;
  # ...
}

逆に、 nginx が受け取った Host すなわちドメイン名とは別のドメインで動いているサーバーに対しても、そのサーバーが期待する Host 値を適切に設定することで、上流として動かすことが可能。 例え上流が https つまり ssl 通信を採用していて、かつ別ドメインであっても、レスポンスが Host に依存していなければ、普通に上流として動かすことが可能。

What does upstream mean in nginx?

upstream app_front_static { server 192.168.206.105:80; } Never seen it before, anyone knows, what it means?

stackoverflow.com

upstream のブロックにより、複数のサーバー(IPとポートにより指定される接続先)をひとまとめにして、それを proxy_pass にて用いることが可能となる。 upstream は、なので、ロードバランシングのための上流サーバーグループ、を表す。

また、 upstream と proxy_pass の記述として、 upstream のサーバーに http と https の接続を混ぜることはできない模様。 (proxy_pass を記述するときに、それは http で接続するのか https で接続するのかを決めておく必要がある。)

ぱっとできる迂回策としては、ただ https としてその上流に繋ぎなおすような適当な http のサーバー(server)の設定を nginx 自体に記述しておいて、それを適当なポートに割り振っておいて、ロードバランスする時はすべて http としてプロキシすること。

upstream http-and-https {
  http上流サーバー
  127.0.0.1:9000
}

# https へのプロキシ
server {
  listen 9000;
  location / {
    proxy_pass https://https上流サーバー
    # その他オプション
  }
}

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://http-and-https
    # その他オプション
  }
}