Nginx http-перенаправление на https при https proxy_pass

Содержание

Вопрос или проблема
Ответ или решение
Конфигурация Nginx для Перенаправления HTTP на HTTPS
Ключевые Моменты для Оптимизации и безопасности:

Вопрос или проблема

У меня есть конфигурация nginx, которая перенаправляет с http на https, но на стороне https расположение / {} включает proxy_pass к сервису на Go.

server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_name *.domain.com domain.com;

  return 301 https://$host$request_uri;
}
server {
  listen 443 ssl http2 default_server;
  listen [::]:443 ssl http2 default_server;
  server_name auth.domain.com;

  location / {
    proxy_pass http://localhost:PORT;
  }
}

Но это не перенаправляет расположение, где я установил proxy_pass.

ОБНОВЛЕНИЕ:

Я хочу перенаправить с http на https. Есть несколько мест, которые указывают на статические файлы (html), а также есть /api и /, которые показаны ниже. Когда я хочу перенаправить с http на https в расположениях статических файлов, оно перенаправляет, но для расположений, которые имеют в себе proxy_pass, просто загружается по http, и ничего не происходит.

Вот конфигурация, которую я использую для перенаправления HTTP на HTTPS:

server {
    listen [::]:80 default_server;
    listen 80 default_server;
    return 301 https://$http_host$request_uri;
}
server {
    ...normal HTTPS conf ...
}

Попробуйте конфигурацию, упомянутую ниже:

# Принудительное перенаправление всех пользователей на https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/www.example.com.pem; // путь к pem или crt файлу для домена
    ssl_certificate_key /etc/nginx/ssl/www.example.com.key; // путь к ключевому файлу для домена
    return 301 https://www.example.com$request_uri;
    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log    /var/log/nginx/example.access.log;

    location / {

      proxy_set_header        Host www.example.com;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      # Исправляем ошибку «Похоже, что ваша настройка обратного прокси сломана»
      proxy_pass          http://localhost:PORT;
      proxy_read_timeout  90;

      proxy_redirect      http://localhost:PORT https://example.com;
    }
}

Одного определения сервера достаточно:

upstream backend {
  server 127.0.0.1:8080; # замените фактическим адресом и портом
}

server {
  listen 80 default_server;
  listen 443 ssl http2 default_server;
  listen [::]:80 default_server;
  listen [::]:443 ssl http2 default_server;

  server_name *.domain.com domain.com;

  ssl_certificate /etc/letsencrypt/live/*.domain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/*.domain.com/privkey.pem;

  location / {
    proxy_pass http://backend;
  }

  # перенаправление на https
  if ($scheme = http) {
    rewrite ^ https://$server_name$request_uri? permanent;
  }
}

Ответ или решение

Чтобы успешно настроить перенаправление HTTP на HTTPS с учетом использования proxy_pass в Nginx, вам необходимо уделить внимание нескольким критическим моментам конфигурации. В данной ситуации вы используете Nginx для прокси-трафика на Go-сервис и желаете, чтобы весь трафик перешел на HTTPS. Рассмотрим, как можно это реализовать, принимая во внимание типичные ошибки и практики.

Конфигурация Nginx для Перенаправления HTTP на HTTPS

Общий Виртуальный Сервер: В вашем случае, можно использовать единый виртуальный сервер, который будет слушать как HTTP, так и HTTPS запросы. Это упрощает поддержание конфигурации и минимизирует ошибки.
Использование upstream: Непосредственное решение, представленное ниже, основывается на использовании upstream, что обеспечивает более эффективное управление соединениями к бэкенду. Это позволяет абстрагировать бэкенд-серверы и обеспечивает гибкость в управлении пулом соединений.
Перенаправление Запросов: Обратите внимание на использование условия if ($scheme = http), которое анализирует текущий протокол соединения. Если протокол является HTTP, то производится перенаправление на HTTPS версия того же URI.

upstream backend {
    server 127.0.0.1:PORT;  # Замените PORT на фактический номер порта вашего Go-сервиса
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name *.domain.com domain.com;

    # Укажите путь к SSL сертификатам
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    # Общий блок для всех запросов
    location / {
        if ($scheme = http) {
            rewrite ^ https://$server_name$request_uri? permanent;
        }

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_pass http://backend;
        proxy_read_timeout 90;
    }
}

Ключевые Моменты для Оптимизации и безопасности:

SSL Конфигурация: Соблюдайте лучшие практики в части безопасности SSL. Отключите устаревшие протоколы и настройки, такие как SSLv3, и включите только актуальные и безопасные версии TLS.
Логи и Диагностика: Настройте ведение логов доступа и ошибок, чтобы иметь возможность быстро находить и исправлять проблемы производительности и безопасности.
SEO Оптимизация: Перенаправление с HTTP на HTTPS также способствует улучшению SEO ранжирования, так как поисковые системы отдают предпочтение защищенным соединениям.

Следуя лучшим практикам и внимательно настраивая конфигурацию как приведено выше, вы сможете успешно реализовать требуемое перенаправление в Nginx без потерь производительности и безопасности. Убедитесь, что вся конфигурация протестирована в безопасной среде перед развертыванием в продакшен.