Linux: Nginx как Reverse Proxy — швейцарский нож для админа

Просто хостить сайт на сервере — это прошлое. Современный подход — спрятать ваше приложение (Apache, Gunicorn, Node.js) за Nginx, который будет работать как обратный прокси. Это повышает безопасность, гибкость и производительность.

1️⃣ Зачем это нужно?

SSL/TLS Termination: Nginx берёт на себя всю работу с шифрованием, разгружая ваше приложение. Управлять сертификатами в одном месте — бесценно.
Load Balancing: Легко распределять трафик на несколько серверов-бэкендов.
Security: Прячет архитектуру вашего бэкенда. Можно настроить файрвол на Nginx и заблокировать вредоносный трафик до того, как он дойдёт до приложения.
Кэширование: Nginx может кэшировать статический контент (CSS, JS, картинки) и отдавать его мгновенно.

2️⃣ Установка и базовая настройка
Устанавливаем Nginx и удаляем дефолтный конфиг.

sudo apt update && sudo apt install nginx
sudo rm /etc/nginx/sites-enabled/default

3️⃣ Конфигурация Reverse Proxy
Создаём файл /etc/nginx/sites-available/myapp.conf. Предположим, ваше приложение работает на порту 8080.

Nginx

server {
    listen 80;
    server_name your_domain.com;

    # Перенаправляем весь трафик на бэкенд
    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # Передаём реальный IP клиента и другие заголовки
        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;
    }
}

4️⃣ Включаем HTTPS (SSL Termination)
Добавим SSL с помощью Certbot (Let's Encrypt).

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d your_domain.com

Certbot автоматически изменит конфиг, добавив listen 443 ssl; и пути к сертификатам.

5️⃣ Активация и проверка

# Проверяем синтаксис конфига
sudo nginx -t

# Создаём символическую ссылку для активации
sudo ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/

# Перезапускаем Nginx
sudo systemctl restart nginx

📈 Итог: Вы построили базовый, но надёжный шлюз для вашего приложения.
Теперь вы можете легко добавлять новые сервисы, управлять SSL и готовиться к масштабированию.
Это уже не просто администрирование, а основы сетевой архитектуры.

#linux #nginx #proxy #security #network #архитектура

Проект на выходные: Nginx Proxy Manager. Управляем реверс-прокси и SSL через GUI

Редактировать конфиги Nginx вручную для каждого нового сервиса — рутина, в которой легко ошибиться. Если вы поднимаете много веб-приложений (особенно в своей Home Lab), вам нужен инструмент, который делает это красиво.

Nginx Proxy Manager — это готовое решение в Docker-контейнере, которое даёт вам удобный веб-интерфейс для управления всеми вашими сайтами и реверс-прокси.

Ключевые фичи:

Графический интерфейс: Забудьте про правку конфигов. Добавляйте хосты, настраивайте редиректы и защиту парой кликов.

Бесплатные SSL-сертификаты: Встроенная интеграция с Let's Encrypt. Он сам получит и будет автоматически продлевать сертификаты для ваших доменов.

Списки доступа (Access Lists): Ограничивайте доступ к сервисам по IP или через логин/пароль.

Простая установка: Запускается одной docker-compose командой.

Готовый docker-compose.yml для старта:

YAML

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # Public HTTP Port:
      - '80:80'
      # Public HTTPS Port:
      - '443:443'
      # Admin Port:
      - '81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Запустите docker-compose up -d, откройте http://<ваш_ip>:81 и начните настраивать.

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

#linux #docker #nginx #selfhosted #гайд #weekendproject

🆚 Reverse Proxy: Nginx vs Traefik

В 2025 году выбор прокси — это выбор парадигмы. Старая школа против Cloud-Native.

1. Nginx

Философия: «Конфиг — это закон». Всё прописывается в файлах .conf.

Плюсы: Невероятная производительность (C++), кэширование, работа со статикой, стандарт индустрии.

Минусы: Для обновления конфига нужен reload. В динамической среде (где контейнеры создаются и умирают ежеминутно) требует «костылей» (шаблонизаторы типа consul-template).

Вердикт: Идеален как фронт-балансировщик, ingress-контроллер для монолитов и отдачи статики.

2. Traefik

Философия: «Конфиг — это Discovery». Он сам слушает Docker/Kubernetes API и на лету создает маршруты.

Плюсы: Магия автоматизации. Повесил лейбл на контейнер — Traefik уже знает, куда слать трафик и сам выписал Let's Encrypt сертификат. Встроенный Dashboard.

Минусы: Медленнее Nginx на высоком трафике (написан на Go). Сложнее в тонкой настройке заголовков/буферов.

Вердикт: Король микросервисов и Docker Swarm/K8s.

📌 Итог: Если у вас статические IP и виртуальные машины — ставьте Nginx. Если у вас Docker/K8s и сервисы скачут по нодам — Traefik сэкономит вам сотни часов написания конфигов.

#devops #nginx #traefik #proxy #architecture #сравнение

🟢 Caddy: Веб-сервер для тех, кто ценит время

Nginx прекрасен, но настройка HTTPS, получение сертификатов Let's Encrypt и ротация ключей — это рутина. Если вы поднимаете пет-проект или домашний сервер, взгляните на Caddy.

Это веб-сервер нового поколения, написанный на Go.

Киллер-фича: Автоматический HTTPS по умолчанию. Вы просто пишете домен в конфиге, и Caddy сам стучится в Let's Encrypt, получает сертификат, привязывает его и настраивает редирект с HTTP на HTTPS.

Конфиг (Caddyfile) для Reverse Proxy: Вместо 50 строк в Nginx, здесь всего 3:

my-project.com {
    reverse_proxy localhost:3000
}

Всё. HTTP/3 (QUIC) включен из коробки. Сертификат получен. Прокси работает. Идеально для выходных экспериментов.

#caddy #web #nginx #https #homelab #opensource

🕸 GoAccess: Превращаем логи Nginx в красивый отчет

Твой босс спрашивает: "Сколько людей было на сайте вчера? С каких стран? Были ли ошибки 404?". Ты можешь грепать access.log полчаса. А можешь запустить GoAccess.

Это анализатор веб-логов, который работает в двух режимах:

1. TUI (в терминале): Красивая псевдографика с барами и статистикой.

2. HTML (веб-отчет): Генерирует интерактивную HTML-страницу с графиками, которую не стыдно показать директору.

Запуск одной строкой:

goaccess /var/log/nginx/access.log --log-format=COMBINED -a -o report.html

Он парсит гигабайты логов за секунды, определяет ботов, браузеры, гео-локацию и самые тяжелые запросы.

#web #logs #nginx #goaccess #analytics #tools #visualization

🛡️ Skill: "API Rate Limiting" — защита от «дружественного» DDoS 🚧

В 2026 году почти любая инфраструктура — это API. Самая частая причина падения сервиса — не хакеры, а свои же разработчики, которые случайно запустили кривой цикл запросов.

Навык: Умение настроить Rate Limiting на уровне Nginx или Ingress Controller.

Пример для Nginx:

1. Описываем зону (10 запросов в секунду на один IP): limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

2. Применяем к локации: limit_req zone=mylimit burst=20 nodelay;

Что это дает: Даже если клиент начнет спамить запросами, твой бэкенд получит ровно столько, сколько может обработать. Остальное Nginx вежливо отсечет с ошибкой 429. Это база стабильности любого продакшена. 💎

#devops #nginx #api #security #scalability #microservices #skills

🎓 Собеседование сисадмина. Выпуск #7: Веб-серверы и Проксирование (Nginx & Troubleshooting)

Привет, коллеги! В 2026 году «просто поднять Apache» — это путь к увольнению по статье за профнепригодность. Веб-сервер сегодня — это первая линия обороны «цифровой крепости», где мы жонглируем TLS 1.3, отечественными сертификатами и отбиваемся от ботов еще до того, как они нагрузят наш бэкенд на ARM-процессорах.

Разберем три вопроса, на которых валят тех, кто застрял в 2015-м.

---
❓ Вопрос 1: «В чем разница между proxy_pass на IP и на Unix-сокет? Когда что выбирать?»

❌ Ответ новичка: «IP — это для интернета, а сокет — это внутри сервера. Сокет вроде бы быстрее».
✅ Ответ инженера:

* Unix Sockets: Обмен данными идет напрямую через ядро Linux без участия сетевого стека (TCP/IP).
* Плюс: Меньше задержки (latency) и нагрузки на CPU.
* Минус: Работает только в рамках одной ОС. Если бэкенд переедет на соседний контейнер/сервер, придется переписывать конфиг.

* TCP (IP:Port): Данные проходят через весь сетевой стек, даже если бэкенд на том же хосте (loopback).
* Плюс: Легко масштабировать — просто меняем `127.0.0.1` на IP другого сервера.
* Вывод: В 2026-м для высоконагруженных локальных связок (Nginx + PHP-FPM/Python) используем сокеты, для микросервисов — TCP.

---

❓ Вопрос 2: «Что такое "проблема Client IP" за прокси-сервером и как ее решить?»

❌ Ответ новичка: «В логах бэкенда будет IP балансировщика. Чтобы увидеть реальный IP, нужно что-то включить в настройках».
✅ Ответ инженера:

По умолчанию бэкенд видит IP того, кто к нему обратился — т.е. вашего Nginx. Чтобы передать адрес клиента, мы используем заголовок X-Forwarded-For или X-Real-IP.

* На стороне Nginx: прокидываем заголовок.
* На стороне бэкенда: используем модуль (например, `ngx_http_realip_module`), чтобы подменить адрес источника в логах и логике приложения.
* Важно:* В 2026-м обязательно настраиваем `set_real_ip_from`, чтобы доверять заголовкам только от своих балансировщиков, иначе любой школьник подменит свой IP в HTTP-заголовке.

---

❓ Вопрос 3: «Зачем нужно прокси-буферирование (proxy_buffering) и когда его вредно выключать?»

❌ Ответ новичка: «Буферизация — это кэш. Ее лучше включить, чтобы все работало быстрее».
✅ Ответ инженера:

Буферизация позволяет Nginx «впитать» ответ от бэкенда максимально быстро и отпустить воркер бэкенда заниматься следующими задачами.

* Если включено: Nginx забирает ответ в память (или на диск) и сам медленно отдает его клиенту с плохим 5G-интернетом. Бэкенд свободен.
* Если выключено (off): Бэкенд будет «висеть» открытым, пока клиент не скачает последний байт. При 1000 медленных клиентах ваш бэкенд захлебнется в процессах.
* Исключение: SSE (Server-Sent Events) или стриминг, где данные должны уходить клиенту мгновенно.

---

Практический пример: Bulletproof Proxy Config 2026

Минимальный набор настроек для проксирования на внутренний сервис с учетом безопасности:

upstream backend_cluster {
    server unix:/run/php-fpm.sock weight=5; # Быстрый локальный сокет
    server 192.168.10.50:8080 backup;       # Резерв на случай падения
}

server {
    listen 443 ssl http2;
    server_name service.local;

    # Работа с реальными IP (только от доверенного шлюза)
    set_real_ip_from  10.0.0.1;
    real_ip_header    X-Forwarded-For;

    location / {
        proxy_pass http_backend_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # Защита от "залипания" бэкенда
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        proxy_buffering on;
        proxy_buffer_size 8k;
    }
}

Зачем это нужно

Понимание работы прокси — это разница между «у нас сервер упал под нагрузкой» и «мы просто увеличили количество воркеров».

Вывод: Берегите бэкенды, делегируйте всю «грязную» работу по общению с клиентами Nginx'у.

#собеседование_AF #nginx #linux #proxy #highload #sysadmin #admin_future