HTTP-прокси

HTTP-прокси — сервер-посредник, через который клиент отправляет запросы к целевым ресурсам. Прокси перехватывает запрос, при необходимости модифицирует его (добавляет заголовки, логирует) и пересылает от своего имени. Целевой сервер видит IP-адрес прокси, а не клиента.

Два типа прокси

Forward Proxy (прямой прокси): Стоит на стороне клиента. Клиент настраивает браузер или ОС на использование прокси. Все запросы идут через прокси-сервер. Цель — скрыть IP клиента, обойти географические ограничения, фильтровать контент в корпоративной сети или кэшировать часто запрашиваемые ресурсы.
Reverse Proxy (обратный прокси): Стоит на стороне сервера. Клиент вообще не знает о его существовании — он обращается к прокси, думая, что это конечный сервер. Задачи: балансировка нагрузки, терминация SSL/TLS, кэширование, защита от DDoS, WAF. Nginx в большинстве конфигураций — reverse proxy.

Режимы прокси

Transparent proxy — клиент не настраивает прокси; трафик перехватывается на уровне сети (iptables REDIRECT). Используется провайдерами и корпоративными сетями.
Anonymous proxy — скрывает IP клиента, но сообщает серверу, что является прокси (заголовок Via).
Elite proxy (high-anonymity) — не передаёт никаких заголовков, раскрывающих использование прокси.

История

Прокси-серверы появились в начале 1990-х для экономии дорогостоящего интернет-трафика через кэширование. CERN httpd (1990) реализовывал базовые функции прокси. В 1994 году Duane Wessels выпустил Squid — ставший стандартным корпоративным прокси на 20 лет. В 2004 году nginx переосмыслил роль прокси: reverse proxy для PHP-FPM, балансировки и SSL-терминации. Сегодня большинство веб-приложений используют nginx или Caddy как reverse proxy перед серверами приложений.

Nginx как reverse proxy — пример

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8000;
        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_connect_timeout 60s;
        proxy_read_timeout 60s;
    }
}

Прокси и безопасность

Обратный прокси (reverse proxy) повышает безопасность: скрывает реальные IP бэкендов, терминирует SSL централизованно, позволяет настроить rate limiting и WAF на одном уровне. Nginx как reverse proxy — стандарт для Python (Gunicorn/uWSGI), Node.js, Ruby (Puma). Конфигурация буферизации: proxy_buffering on и proxy_buffer_size 16k улучшают производительность при медленных клиентах.

Прозрачный прокси в корпоративных сетях: iptables REDIRECT перехватывает трафик на 80/443 и направляет на прокси-сервер (Squid). Пользователи не настраивают браузер — трафик перехватывается принудительно. Корпоративный CA-сертификат устанавливается на устройства для HTTPS-инспекции.

HTTP-прокси: диагностика и отладка

Отладка через заголовки: curl -I -x http://proxy:8080 http://target.com показывает ответ через прокси. Заголовок Via в ответе указывает, что запрос прошёл через прокси. X-Forwarded-For — цепочка IP при нескольких прокси. Для обратного прокси: curl -H "Host: example.com" http://backend-ip проверяет бэкенд напрямую.

Squid — классический forward proxy с кэшированием и ACL. squid.conf: http_port 3128, acl localnet src 192.168.0.0/16, http_access allow localnet. Кэш в /var/spool/squid. Squid SslBump для HTTPS-инспекции корпоративного трафика — требует установки корпоративного CA на все устройства. Для современных сценариев: mitmproxy (Python, с web UI для отладки HTTP/HTTPS), Charles Proxy (macOS/Windows, для разработки).

Прокси и хостинг

На уровне хостинга прокси используют для: терминации HTTPS перед приложением (сертификат один — на nginx, а приложение работает по HTTP локально), сокрытия реального IP сервера (защита от прямых DDoS), кэширования статики (nginx sendfile), балансировки между несколькими бэкендами. Заголовок X-Forwarded-For позволяет приложению знать реальный IP клиента, даже стоя за прокси.