Обратный прокси Nginx с SSL

Если вы запускаете веб -приложение на частном порту (например, Localhost: 3000), он не доступен непосредственно через Интернет.Один из наиболее эффективных способов надежно разоблачить это приложение - это поставить обратный прокси перед ним.

Nginx-это легкий хорошо известный инструмент, который может сделать именно это-получить входящий трафик и перенаправить его в ваше приложение-а также обрабатывать HTTPS бесплатным сертификатом SSL от Let's Encrypt.

В этом руководстве вы узнаете, как:

• Настройка Nginx как обратный прокси для внутренней веб -службы
  
• Защитите его с помощью сертификата SSL, используя CertBot
  
• Понять каждую часть конфигурации, чтобы вы знали, что он делает и почему

Новичок в веб -серверах?Проверьте наше объяснение на Как работают веб -серверы.

Что такое обратный прокси и зачем использовать его?

А Обратный прокси это сервер, который находится между вашим пользователем и вашими бэкэнд -службами.Вместо вашего приложения публично прослушивает порт (например, 3000), Nginx сначала получает трафик, а затем передает его приложению, работающему в фоновом режиме.

Вот почему этот подход так полезен:

• Скрывает внутренние порты и услуги
  Ваше приложение не должно быть выявлено непосредственно для общественности.Это уменьшает поверхность атаки и помогает вам контролировать доступ.
  
• Обрабатывает Https для вас
  Многие веб -фреймворки могут служить HTTPS напрямую, но часто проще и более надежно позволить Nginx сделать это, особенно при использовании бесплатных SSL -сертификатов из Let's Encrypt.
  
• Включает размещение нескольких сервисов на одном сервере
  Вы можете запустить несколько приложений на разных портах (например, 3000, 4000, 5000) и маршрутизации трафика на основе домена или пути, используя только один публичный IP.
  
• Улучшает ведение журнала и мониторинг
  Nginx дает вам централизованный доступ к доступу и журналам ошибок, поэтому проще контролировать производительность или исследовать проблемы.
  
• Обеспечивает дополнительное кэширование, баланс нагрузки и ограничение скорости
  Вы можете оптимизировать поток трафика и защитить сервисные сервисы только несколькими дополнительными линиями в вашей конфигурации Nginx.

Даже если ваше приложение уже может обрабатывать веб -трафик, использование NGINX в качестве обратного прокси -сервера часто упрощает настройку, повышает гибкость и увеличивает управление.

Предпосылки

Прежде чем мы начнем, давайте убедитесь, что у вас есть все, что вам нужно:

• VPS или Cloud Server, управляющий Ubuntu 20.04 или более поздней. Большинство команд и версий пакетов, используемых в этом уроке, предполагают систему на основе Debian.В то время как Nginx и Certbot работают над другими распределениями, процесс настройки может отличаться.
• Root или sudo Access: Вы будете устанавливать пакеты, редактировать системные файлы и перезагружать сервисы, которые требуют повышенных привилегий.
• Зарегистрированное доменное имя: Вам понадобится это, чтобы запросить сертификат SSL.Let's Encrypt подтверждает право собственности на ваш домен до выдачи сертификата.Без DNS на ваш сервер валидация не удастся.
• DNS указывает на публичный IP -адрес вашего сервера: Убедитесь, что записи DNS вашего домена обновлены.Простой записи, указывающей на IP -адрес вашего сервера, достаточно:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

Распространение может занять несколько минут до нескольких часов.

Не знаете, как настроить DNS?Вот Как добавить запись с большинством доменных хостов.

• Приложение, работающее на Localhost (например,, http://localhost:3000): Это приложение, которое вы будете обеспечивать.Это может быть что угодно - node.js, колба из питона, рубин на рельсах и т. Д. Пока он слушает местный порт, вы можете прокси.

Примечание: Если ваше приложение еще не работает, это нормально - вы все равно можете пройти через настройку и проверить позже.

• Nginx установлен: Nginx будет действовать как общедоступный сервер.Если он еще не установлен:

sudo apt update
sudo apt install nginx

Затем убедитесь, что он работает:

sudo systemctl status nginx

Вы должны увидеть «Active (бег)».

• Certbot установлен с помощью плагина Nginx: Certbot автоматизирует процесс получения и обновления сертификатов SSL от Let's Encrypt.Установите это так:

sudo apt install certbot python3-certbot-nginx

Этот плагин позволяет автоматическому изменению конфигурации NGINX, когда вы запросите сертификат - не требуется ручное редактирование для базовых настройки.

Есть еще одна операционная система?Следуйте этому руководству Как установить давайте зашифруйте на Fedora и Debian

Шаг 1: Настройка обратного прокси NGINX

Теперь, когда ваша система готова, первым реальным шагом является настройка Nginx для прослушивания трафика в вашем домене и перенаправить его в ваше внутреннее приложение - это то, что делает Nginx действовать как обратный прокси.

Почему это важно

Без этой настройки пользователи, пытающиеся посетить ваш веб -сайт, достигнут пустой страницы или по умолчанию Nginx Ecrement.Вам нужно явно сказать nginx:

• Какой домен (и) он должен реагировать на
  
• Что делать с входящими запросами
  
• Куда отправить трафик за кулисами

Создать новый блок сервера

Вы создадите файл конфигурации для вашего домена в каталоге NGINX-сайты.Это сохраняет организованные конфигурации и позволяет легко включить или отключить отдельные сайты.

sudo nano /etc/nginx/sites-available/yourdomain.com

Вставьте в следующий блок, настраивая домен и порт приложения по мере необходимости:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        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;
    }
}

Что делает эта конфигурация

• Слушайте 80;
  Сообщает Nginx прослушать HTTP -трафик на порту 80.
  
• server_name yourdomain.com www.yourdomain.com;
  Соответствует этому блоку с запросами, сделанным в вашем домене.Вы можете добавить или удалить субдомены по мере необходимости.
  
• расположение /
  Похватывает все запросы в корень и пересылает их в ваше приложение.
  
• proxy_pass http: // localhost: 3000;
  Это сердце обратного прокси - он отправляет запрос на ваше бэкэнд -приложение, работающее на порту 3000.
  
• Прокси_SET_HEADER LINES
  Они сохраняют подробности из исходного запроса клиента, например:
  
  • IP -адрес пользователя (Рентгеновский IP)
    
  • Исходный протокол (http или https)
    
  • Оригинальное имя хоста
    
• Эта информация полезна для ведения журнала, аналитики или когда ваше приложение необходимо для создания URL -адресов, которые соответствуют опыту посетителя.

Включить конфигурацию

Nginx использует символические ссылки в с поддержкой сайтов каталог для активации сайтов.Итак, теперь вы создадите ссылку и перезагрузите Nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Проверьте на наличие синтаксических ошибок.Если все выглядит хорошо:

sudo systemctl reload nginx

Ваш обратный прокси сейчас вживую - просьба http://yourdomain.com будет передано в ваше приложение на порту 3000.

Шаг 2: Добавьте SSL с Let's Encrypt и Certbot

С обратным прокси, работающим над HTTP, следующим шагом является обеспечение его HTTPS.Это добавляет шифрование ко всему общению между вашими пользователями и вашим сервером - защита учетных данных, запросов API, личных данных и многого другого.

Вы используете Ellis Encrypt, бесплатный орган сертификации и сертификат, который автоматизирует процесс.

Почему https важен

• Шифрует трафик так что никто не может перехватить или вмешиваться в него
  
• Улучшает SEO - Поисковые системы предпочитают безопасные сайты
  
• Укрепляет доверие - Пользователи ожидают увидеть значок замка
  
• Требуется для многих API, входа в систему и платежных систем

Запросить сертификат

Запустите эту команду, заменив домены на ваши фактические значения:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Что это делает:

• Сообщает Certbot использовать плагин Nginx
  
• Указывает, какие домены вы запрашиваете сертификат

Certbot будет:

• Выполните проверку домена, создав временный файл в вашей конфигурации Nginx
  
• Свяжитесь с давайте зашифруем, чтобы проверить владение доменом
  
• Загрузите свой сертификат SSL и закрытый ключ
  
• Измените конфигурацию Nginx для использования HTTPS
  
• По желанию перенаправить весь http -трафик на HTTPS

Кончик: Если ваш DNS не полностью распространяется, или ваш сервер брандмауэр блокирует 80, проверка не удастся.Вы можете проверить это с помощью:

curl -I http://yourdomain.com

Чтобы лучше понять порты, ознакомьтесь с нашим руководством на Как работают порты веб -сервера.

Проверьте изменения

После завершения Certbot ваш конфигурация Nginx должна включать что -то подобное:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Теперь вы должны иметь возможность посетить https://yourdomain.com и увидеть свой сайт с действительным сертификатом SSL.

Необязательно: Force https

Если вы не выбрали опцию перенаправления во время настройки CertBot, вы можете добавить это вручную:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

Это заставляет все HTTP -трафик быть перенаправленным на HTTPS, что гарантирует, что пользователи случайно не используют небезопасную версию вашего сайта.

Шаг 3: Улучшение настроек SSL (рекомендуется для производства)

После того, как ваш сертификат SSL будет на месте, вы можете точно настроить Nginx для повышения безопасности и совместимости.Эти настройки заходят внутри блока HTTPS Server.

Вот улучшенный пример:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Что делают эти настройки

• ssl_protocols TLSv1.2 TLSv1.3
  Отключает старые, менее безопасные протоколы, такие как TLS 1.0 и 1.1.
  
• ssl_prefer_server_ciphers on
  Позволяет вашему серверу решать алгоритм шифрования, а не отсрочить в браузер, что может снизить воздействие слабых атак шифров.
  
• ssl_ciphers High :! anull :! Md5
  Определяет сильные шифры и исключает слабые или сломанные (например, MD5 и нулевые шифры).
  
• ssl_session_cache и ssl_session_timeout
  Управление повторным использованием сеанса SSL, которое может немного повысить производительность без ущерба для безопасности.
  
• ssl_session_tickets off
  Отключает билеты с сеансами, которые могут быть проблемой безопасности, если не регулярно вращаться.

Эти изменения улучшают ваш балл безопасности SSL и защищают посетителей от атак понижения или небезопасного выбора шифрования.

Необязательный: Вы можете проверить свой сайт с помощью SSL Labs, чтобы увидеть, как работает ваша конфигурация, и получить конкретные предложения по улучшению.

Шаг 4: (Необязательно) Добавить параметры Diffie-Hellman

Для еще более сильного шифрования вы можете генерировать пользовательский ключ Diffie-Hellman (DH).Этот шаг не является обязательным, но его часто рекомендуется для производственных сред.

Запустите эту команду, чтобы создать 2048-битную группу DH:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Затем добавьте следующую строку в свой блок SSL -сервера:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Зачем это добавлять?

Параметры Diffie-Hellman укрепляют Впередная секретность, что означает, что даже если ваш личный ключ каким -то образом скомпрометирован в будущем, прошлые зашифрованные сеансы все равно будут безопасными.

Чтобы создать группу DH, требуется несколько минут, но это единовременный шаг, который стоит сделать для лучшей осанки безопасности.

Шаг 5: Настройка автоматического обзора для сертификатов SSL

Давайте истекаем сертификаты зашифровать каждые 90 дней.К счастью, Certbot устанавливает системный таймер, который проверяет два раза в день на сертификаты из -за истечения срока действия и автоматически продлевает их.

Вы можете подтвердить, что таймер активен:

sudo systemctl list-timers | grep certbot

Вы должны увидеть что -то вроде этого:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Чтобы проверить процесс обновления вручную (без внесения изменений), запустите:

sudo certbot renew --dry-run

Это имитирует полный процесс обновления и подтверждает, что ваша система готова к автоматическому обработке.

Если ошибок нет, ваши сертификаты будут тихо продлить в фоновом режиме.

Последние шаги и хорошие привычки

Теперь, когда ваш обратный прокси настроен и защищен SSL, рекомендуется завершить несколько практических проверок и лучших практик.

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

Даже если все, кажется, работает, потратить несколько дополнительных минут здесь, может сэкономить ваше время и проблемы позже.

Перезапустите приложение, если оно не обнаруживает изменений
Некоторые приложения должны быть перезапущены, чтобы правильно работать за прокси.

Проверьте журналы
Вы можете отслеживать журналы Nginx на предмет ошибок или необычного трафика:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Держите Nginx и Certbot
Используйте Sudo Apt Update && Sudo APT обновление регулярно.Обновленные пакеты исправляют ошибки, улучшение совместимости и проблемы безопасности исправления.

Усовершенствованные варианты использования для Nginx Reverse Proxy с SSL

После того, как вы освоили основы настройки безопасного обратного прокси, вы можете расширить свою конфигурацию, чтобы удовлетворить более сложные потребности.Вот несколько общих сценариев, которые могут помочь вам получить больше от вашего сервера.

Размещение нескольких приложений на одном сервере

Если вы запускаете несколько веб -приложений в разных портах, Nginx может направлять запросы в каждое приложение на основе пути домена или URL.

Пример: разные домены

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

server {
    listen 80;
    server_name app2.example.com;

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Эта настройка позволяет вам обслуживать несколько приложений, используя отдельные субдомены, все через Nginx на стандартных портах.

Используете Docker?Учиться Как прокси -раз.

Прокси на основе пути

В качестве альтернативы, вы можете прокси на основе путей URL, что полезно, если вы хотите все приложения под одним доменом:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Примечание: При использовании прокси, основанного на пути, сцепления с задними чертами и переписыванием URL могут стать хитрыми-убедитесь, что ваше бэкэнд-приложение может обрабатывать, что подпадает под патроном.

Добавление ограничения ставки для защиты вашего приложения

Вы можете ограничить количество запросов, которые клиент может сделать в заданный срок, чтобы защитить ваш бэкэнд от злоупотребления или случайной перегрузки.

Добавьте это в блок http в /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Затем в вашем сервере или блоке местоположения:

limit_req zone=mylimit burst=20 nodelay;

Эта конфигурация допускает 10 запросов в секунду с всплесками до 20 запросов, отбрасывая избыточные запросы, чтобы избежать перегрузки вашего приложения.

Балансировка нагрузки на несколько бэкэнд -серверов

Если у вас есть несколько экземпляров вашего приложения (например, несколько контейнеров или VPS), Nginx может распространять трафик среди них:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

NGINX уравновешивает запросы по кругу по умолчанию, но вы можете настроить их для других методов, таких как наименьшие соединения или IP-хэш.

Чтобы узнать больше, ознакомьтесь с нашим руководством на DNS Балансировка нагрузки.

Лесозаготовка и отладка

Вы можете настроить журнал, чтобы включить важную информацию о доверенности для устранения неполадок или аналитики:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Это регистрирует время отклика вверх по течению и общее время запроса, помогая определить медленные ответы на бэкэнд.

Пользовательские заголовки и улучшения безопасности

Вы можете добавить или изменить заголовки HTTP для безопасности или функциональности:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Эти заголовки защищают от ClickJacking, Mime Sniff и обеспечения использования HTTPS.