Перенаправляйте всі http-запити, що стоять за Amazon ELB, на https, не використовуючи if

Наразі у мене є ELB, що обслуговує як http://www.example.org, так і https://www.example.org .

Я хотів би налаштувати його, щоб будь-який запит, що вказує на http://www.example.org , перенаправляв на https://www.example.org .

ELB надсилає https-запити як http-запити, використовуючи:

server {
      listen         80;
       server_name    www.example.org;
       rewrite        ^ https://$server_name$request_uri? permanent;
}

не працюватиме, оскільки запити, зроблені на https://www.example.org , все одно будуть зроблені до порту 80 на nginx.

Я знаю, що це можливо переписати як

server {
      listen         80;
      server_name    www.example.org;
      if ($http_x_forwarded_proto != "https") {
          rewrite ^(.*)$ https://$server_name$1 permanent;
      }
}

Але все, що я читав, говорив, що ifслід уникати будь-якою ціною в межах конфігурації nginx, і це було б для кожного запиту. Крім того, це означає, що я повинен встановити спеціальну окрему конфігурацію для перевірки стану здоров’я ( як описано тут : "... коли ви знаходитесь за ELB, де ELB виступає кінцевою точкою HTTPS і лише надсилає HTTP-трафік на ваш сервер, ви порушити можливість відповідати за допомогою відповіді HTTP 200 OK для перевірки стану здоров'я, необхідної для ELB ").

Я розглядаю можливість входу до коду веб-програми, а не конфігурації nginx (і для цілей цього питання припустимо, що це додаток на основі Джанго), але я не впевнений, чи буде це більше витрат, ніж if конфігурація.

Якщо це працює правильно, не бійтеся цього. http://wiki.nginx.org/IfIsEvil

Важливо зауважити, що поведінка, якщо вона не є непослідовною, з огляду на два однакових запити, вона не може випадково вийти з одного і працювати над іншим, за умови належного тестування та розуміння, якщо можна використовувати . Однак, поради щодо використання інших директив, де вони є, все ще дуже застосовні.

1. Налаштуйте ваш AWS ELB зіставлення ELB: 80 на примірник: 80 та ELB: 443 на примірник: 1443.
2. Прив’яжіть nginx для прослуховування на портах 80 та 1443.
3. Переадресація запитів, що надходять у порт 80 до порту 443.
4. Перевірка здоров'я повинна бути HTTP: 1443. Він відхиляє HTTP: 80, оскільки перенаправлення 301.

Налаштування NGINX

    server {
       listen         80;
       server_name    www.example.org;
       rewrite        ^ https://$server_name$request_uri? permanent;
    }

    server {
       listen         1443;
       server_name    www.example.org;
   } 

Це рішення використовує умовну логіку, але як підказує прийнята відповідь, я також думаю, що це нормально. Посилання: /programming/4833238/nginx-conf-redirect-multiple-conditions

Крім того, для цього не потрібно відкривати додаткові порти в налаштуваннях безпеки aws для зображення. Ви можете скасувати ssl в AWS LB і направити трафік https на http-порт 80 у вашому випадку.

У цьому прикладі перевірка здоров’я ЛБ потрапляє / стан здоров'я на порт 80, який прямує до сервера додатків, тому перевірка здоров'я підтверджує як nginx, так і ваш додаток.

server {
  listen 80 default deferred;

  set $redirect_to_https 0;
  if ($http_x_forwarded_proto != 'https') {
    set $redirect_to_https 1;
  }
  if ($request_uri = '/health') {
    set $redirect_to_https 0;
  }
  if ($redirect_to_https = 1) {
    rewrite ^ https://www.example.com$request_uri? permanent;
  }
  ...
}

Тепер ви можете створити нового слухача в налаштуваннях балансу завантаження AWS, який перенаправляє HTTP-порт 80 на порт HTTPS 443. Тому вам більше не потрібно торкатися конфігурації nginx / apache.