Web-сервис в 2026 году: большой гид по технологиям, производительности и архитектуре

Nginx · Caddy · Traefik · HAProxy · Envoy · Kong · Apache HTTP Server · Apache APISIX · Envoy Gateway · Varnish · Apache Traffic Server

От простого HTTPS-прокси до собственной платформы уровня Cloudflare: что выбрать, как сравнивать производительность и во что обойдется эксплуатация.

Введение. Почему выбор прокси стал архитектурным решением

Еще недавно выбор reverse proxy казался простой технической задачей. Нужно принять HTTP-запрос, завершить TLS-соединение, определить backend и передать ему запрос. Для большинства проектов было достаточно Nginx или Apache HTTP Server.

Но инфраструктура изменилась.

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

Параллельно произошло еще одно важное изменение: функции, которые раньше выполнялись отдельными устройствами или коммерческими платформами, теперь доступны в open-source компонентах.

Сегодня на базе свободного программного обеспечения можно построить не только reverse proxy, но и значительную часть инфраструктуры CDN, WAF или API Gateway.

Возникает соблазн найти универсальный продукт, который умеет всё.

Однако именно такой подход часто приводит к ошибкам.

Прокси, балансировщик, API Gateway, Ingress Controller, CDN Cache и WAF решают пересекающиеся, но разные задачи. Иногда они реализуются одним продуктом, иногда требуют нескольких специализированных компонентов.

В этой статье мы последовательно разберем одиннадцать решений, сравним их архитектуру, зрелость, популярность, производительность и эксплуатационные свойства. Затем рассмотрим единый пример конфигурации и завершим проектированием собственной CDN/WAF-платформы — от регионального MVP до архитектуры, способной развиваться в сторону Cloudflare.

1. Сначала разберемся с терминами

Различия между технологиями лучше понимать не по названиям продуктов, а по их роли в обработке трафика.

Упрощенная модель современной платформы доставки и защиты приложений. Некоторые уровни могут совмещаться в одном программном компоненте.

Reverse Proxy принимает запросы от клиентов и направляет их к внутренним серверам. Может выполнять TLS termination, маршрутизацию, изменение заголовков и балансировку.

Load Balancer распределяет соединения или запросы между серверами, учитывая их доступность, нагрузку и заданные алгоритмы.

Ingress Controller связывает Kubernetes-ресурсы с конфигурацией прокси, обеспечивая доступ к сервисам кластера.

API Gateway управляет не только маршрутизацией, но и потребителями API: аутентификацией, авторизацией, квотами, политиками и аналитикой.

CDN (Content Delivery Network) — распределенная сеть точек присутствия, которая доставляет контент пользователям с минимальными задержками и снижает нагрузку на исходные серверы.

WAF (Web Application Firewall) — средство анализа и фильтрации HTTP-трафика для защиты веб-приложений от атак на прикладном уровне.

Service Proxy — компонент управления взаимодействием сервисов, часто работающий внутри service mesh.

Главная идея: наличие HTTP proxy еще не делает продукт полноценным API Gateway, а поддержка HTTP-кэширования еще не превращает сервер в CDN.

2. Одиннадцать решений: кто есть кто

2.1. Шесть основных универсальных и инфраструктурных продуктов

Nginx — универсальный фундамент

Высокопроизводительный веб-сервер и reverse proxy на C. Подходит для статики, TLS, HTTP-маршрутизации, балансировки и edge-развертываний. Сильные стороны — зрелость, предсказуемость, огромная база знаний и широкое распространение.

Caddy — минимизация эксплуатационной сложности

Веб-сервер на Go, известный автоматическим HTTPS и лаконичной конфигурацией. Хорош для небольших и средних развертываний, где важно быстро получить надежный HTTPS reverse proxy без отдельной инфраструктуры управления сертификатами.

Traefik — прокси для динамической инфраструктуры

Cloud-native reverse proxy на Go. Обнаруживает сервисы через Docker, Kubernetes и другие providers. Основная ценность — автоматическая маршрутизация при изменении состава приложений.

HAProxy — специализированная балансировка

Зрелый L4/L7-балансировщик на C. Особенно силен в обработке соединений, health checks, ACL, управлении отказами и высоконагруженных конфигурациях.

Envoy Proxy — программируемый сетевой data plane

Прокси на C++, созданный для распределенных систем. Отличается развитой L7-маршрутизацией, наблюдаемостью, фильтрами и динамическим управлением через xDS.

Kong Gateway — API как управляемый продукт

API Gateway на базе OpenResty/Nginx. Сильная сторона — плагины, политики безопасности, управление потребителями API, rate limiting и централизованное API governance.

2.2. Еще пять продуктов, которые нельзя игнорировать

Apache HTTP Server

Один из самых зрелых веб-серверов. Через mod_proxy, mod_proxy_balancer, mod_ssl и другие модули выполняет функции reverse proxy. Особенно актуален для существующих корпоративных приложений и традиционных веб-инфраструктур.

Apache APISIX

Динамический API Gateway на базе Nginx/OpenResty. Прямой конкурент Kong, ориентированный на высокую производительность, расширяемые плагины и динамическое управление конфигурацией.

Envoy Gateway

Kubernetes Gateway API-реализация, использующая Envoy как data plane. Это не отдельный конкурент Envoy Proxy, а способ управлять им через Kubernetes-native ресурсы.

Varnish Cache

Специализированный HTTP accelerator и кэширующий reverse proxy. Особенно полезен для CDN, новостных сайтов, каталогов, электронной коммерции и других сценариев с высокой повторяемостью запросов.

Apache Traffic Server

Высокопроизводительный caching proxy, исторически ориентированный на крупные системы доставки контента. Интересен для многоуровневого кэширования, больших объемов трафика и построения собственных CDN.

2.3. Архитектурная классификация

Продукт	Основная роль	Типичный сценарий
Nginx	Web / Reverse Proxy	Универсальный edge
Caddy	Web / Reverse Proxy	Простой HTTPS
Traefik	Dynamic Reverse Proxy	Docker, Kubernetes
HAProxy	L4/L7 Load Balancer	Высокая нагрузка
Envoy	Service / Edge Proxy	Распределенные системы
Kong	API Gateway	Партнерские API
Apache HTTP Server	Web / Reverse Proxy	Традиционные приложения
Apache APISIX	API Gateway	Динамические API
Envoy Gateway	Kubernetes Gateway Controller	Gateway API
Varnish Cache	HTTP Cache	Ускорение контента
Apache Traffic Server	Caching Proxy	CDN и большие объемы трафика

Не все эти продукты должны участвовать в одном и том же benchmark. Например, сравнение Varnish с Kong по числу запросов к кэшируемому статическому объекту почти ничего не скажет о пригодности Kong для управления API.

3. Современность, популярность и перспективы

Популярность — важный фактор выбора инфраструктуры, но ее необходимо оценивать правильно.

Существуют как минимум четыре разных показателя:

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

Они не всегда коррелируют.

3.1. Зрелость против технологической актуальности

Nginx, HAProxy и Apache HTTP Server существуют давно, но возраст не означает устаревания.

Traefik, Caddy и Envoy появились позже и проектировались с учетом других эксплуатационных моделей: контейнеризации, автоматизации и распределенных систем.

Apache Traffic Server и Varnish представляют еще один тип зрелости: специализацию на задачах, которые универсальные прокси обычно решают менее глубоко.

Архитектурная пригодность для современных сценариев

Экспертная оценка от 1 до 5. Это не измерение популярности, скорости или качества реализации.

На диаграмме хорошо видна специализация. Универсальный Nginx не доминирует во всех категориях, но остается достаточно гибким. Kong и APISIX сильнее в API governance. Varnish и Apache Traffic Server существенно интереснее при проектировании CDN.

3.2. Что происходит с Kubernetes Ingress

Одно из наиболее значимых событий для инфраструктурного рынка — завершение поддержки community-проекта Ingress NGINX в марте 2026 года.

Важно не путать его с самим Nginx: веб-сервер Nginx продолжает развиваться. Прекращение поддержки относится к конкретному Kubernetes ingress-контроллеру.

Это ускоряет интерес к Kubernetes Gateway API и альтернативным контроллерам, включая Traefik и Envoy Gateway.

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

3.3. Популярность: как ее измерять корректно

Метрика	Что показывает	Чего не показывает
Доля публичных веб-серверов	Видимое использование на сайтах	Внутренние прокси
GitHub stars	Интерес разработчиков	Production-инсталляции
Contributors / releases	Активность разработки	Надежность под нагрузкой
CNCF surveys	Применение в cloud-native выборке	Весь рынок
Коммерческие клиенты	Зрелость экосистемы	Долю open-source установок
Docker pulls	Популярность образов	Количество независимых пользователей

По публичной распространенности веб-серверов Nginx и Apache остаются особенно заметными. Но HAProxy, Envoy, Traefik и Kong часто работают внутри инфраструктуры, где обычная статистика сайтов их не обнаруживает.

Поэтому я не стал бы строить единый количественный рейтинг «популярности всех одиннадцати»: для него нет сопоставимого набора данных.

3.4. Перспективность на горизонте нескольких лет

Продукт	Зрелость	Перспектива	Основной фактор
Nginx	Очень высокая	Устойчивая	Массовость и универсальность
Caddy	Высокая	Положительная	Автоматизация HTTPS
Traefik	Высокая	Положительная	Cloud-native и Gateway API
HAProxy	Очень высокая	Устойчивая	Высоконагруженная балансировка
Envoy	Очень высокая	Положительная	Service mesh и xDS
Kong	Высокая	Положительная	API/AI Gateway
Apache HTTP	Очень высокая	Стабильная	Установленная база
Apache APISIX	Высокая	Положительная	Динамический API Gateway
Envoy Gateway	Развивающаяся	Положительная	Kubernetes Gateway API
Varnish	Очень высокая	Специализированная	HTTP caching
Apache Traffic Server	Высокая	Специализированная	CDN-инфраструктура

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

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

4. Производительность: кто быстрее и почему это не всегда важно

Когда сравнивают Nginx, HAProxy, Envoy или Traefik, обычно задают один вопрос: сколько запросов в секунду способен обработать каждый продукт?

Но RPS — лишь одна из характеристик.

Рассмотрим два сценария.

В первом прокси получает запрос и передает его backend. Во втором он проверяет JWT, выполняет rate limiting, анализирует запрос с помощью WAF, пишет подробный access log и проверяет доступность нескольких backend-серверов.

Даже на одинаковом оборудовании результаты будут принципиально различаться.

4.1. Какие показатели действительно важны

4.2. Почему опубликованные бенчмарки трудно сравнивать

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

Особенно некорректно сравнивать:

HAProxy без дополнительных фильтров с Kong, выполняющим аутентификацию.
Varnish с попаданием в кэш и Nginx, обращающимся к backend.
Envoy с активным tracing и Traefik без телеметрии.
Kubernetes ingress-контроллер со standalone reverse proxy.

Для каждого такого сравнения необходимо выровнять функциональность.

4.3. Как выглядит правильный эксперимент

Предлагаемый стенд:

Параметр	Значение
Ресурсы прокси	8 vCPU / 16 GB RAM
Протоколы	HTTP/1.1, HTTP/2
TLS	Без TLS / TLS 1.3
Размер ответа	1 KB, 16 KB, 256 KB
Соединения	100, 500, 1000, 5000
Длительность	5 минут после прогрева
Сценарии	Proxy / TLS / Logs / Security
Инструменты	wrk2, Fortio, Prometheus
Результаты	RPS, p50/p95/p99, CPU, RSS, errors

4.4. Почему включение функций меняет результаты

Иллюстрация стоимости дополнительных функций

Условная модель, не результаты испытаний. Базовая пропускная способность нормирована к 100 для демонстрации принципа.

Наличие WAF, аутентификации и расширенного логирования потребляет ресурсы. Но величина затрат зависит от конкретной реализации, правил, нагрузки и настроек.

Для практического выбора важнее ответить на вопрос: какой продукт обеспечивает требуемый p99 и уровень защиты при минимальных CPU/RAM и эксплуатационных расходах?

4.5. Производительность для CDN

В CDN ситуация отличается.

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

Cache hit ratio.
Скорость чтения объектов из RAM и SSD.
Производительность TLS.
Сетевой throughput.
Эффективность хранения.
Поведение при cache miss и массовой очистке кэша.
Защита origin от лавины запросов.

Именно поэтому Varnish и Apache Traffic Server заслуживают отдельного класса тестов.

5. Практика: один API, разные конфигурации

Рассмотрим типовую задачу:

Публичный домен api.example.com.
HTTPS.
Два backend: 127.0.0.1:3000 и 127.0.0.1:3001.
Round Robin.
Передача исходного Host.
Передача клиентского IP через доверенные proxy-заголовки.

Во всех примерах предполагается, что backend-сервисы доступны прокси по указанным адресам. В Docker и Kubernetes обычно используются DNS-имена сервисов, а не 127.0.0.1.

Конфигурации ниже демонстрируют эквивалентную маршрутизацию, но не полностью одинаковый набор production-функций. Для TLS и клиентских IP нужно отдельно определить доверенные сети, цепочку прокси и политику сертификатов.

5.1. Nginx

upstream api_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

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

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/ssl/api/fullchain.pem;
    ssl_certificate_key /etc/ssl/api/privkey.pem;

    location / {
        proxy_pass http://api_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;
    }
}

Nginx использует Round Robin для upstream по умолчанию.

Преимущество — понятная и зрелая модель. Изменения применяются через graceful reload.

5.2. Caddy

api.example.com {
    reverse_proxy 127.0.0.1:3000 127.0.0.1:3001 {
        lb_policy round_robin
    }
}

Caddy автоматически управляет HTTPS при выполнении условий ACME.

Это наиболее компактная конфигурация из рассматриваемых вариантов.

5.3. Traefik

Статическая конфигурация:

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

  websecure:
    address: ":443"

providers:
  file:
    filename: /etc/traefik/dynamic.yml
    watch: true

certificatesResolvers:
  letsencrypt:
    acme:
      email: admin@example.com
      storage: /etc/traefik/acme.json
      httpChallenge:
        entryPoint: web

Динамическая конфигурация:

http:
  routers:
    api:
      rule: "Host(`api.example.com`)"
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
      service: api

  services:
    api:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:3000"
          - url: "http://127.0.0.1:3001"

В этом примере используется file provider. При использовании Docker provider маршруты можно объявлять непосредственно через labels контейнеров.

5.4. HAProxy

global
    log stdout format raw local0

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend http
    bind *:80
    http-request redirect scheme https code 301

frontend https
    bind *:443 ssl crt /etc/haproxy/certs/api.pem

    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Real-IP %[src]
    http-request set-header X-Forwarded-For %[src]

    default_backend api_backend

backend api_backend
    balance roundrobin
    option httpchk GET /health

    server api1 127.0.0.1:3000 check
    server api2 127.0.0.1:3001 check

Здесь дополнительно включены health checks. Предполагается, что оба backend предоставляют /health.

HAProxy удобен, когда требуется тонко управлять алгоритмами балансировки, отказами и поведением соединений.

5.5. Envoy

static_resources:
  listeners:
  - name: https_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 443
    filter_chains:
    - transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            tls_certificates:
            - certificate_chain:
                filename: /etc/ssl/api/fullchain.pem
              private_key:
                filename: /etc/ssl/api/privkey.pem
      filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: routes
            virtual_hosts:
            - name: api
              domains: ["api.example.com"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: api_backend
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: api_backend
    type: STATIC
    connect_timeout: 2s
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: api_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 3000
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 3001

Этот минимальный вариант не включает отдельный HTTP listener для перенаправления с 80 на 443. В production также следует явно настроить доверие к X-Forwarded-For и другие параметры HTTP Connection Manager.

Основное достоинство Envoy — возможность вынести управление подобными конфигурациями в xDS control plane.

5.6. Kong

_format_version: "3.0"

services:
  - name: api-service
    host: api-upstream
    port: 80
    protocol: http
    routes:
      - name: api-route
        hosts:
          - api.example.com
        protocols:
          - https
        paths:
          - /
        strip_path: false

upstreams:
  - name: api-upstream
    algorithm: round-robin
    targets:
      - target: 127.0.0.1:3000
      - target: 127.0.0.1:3001

DB-less запуск:

export KONG_DATABASE=off
export KONG_DECLARATIVE_CONFIG=/etc/kong/kong.yml
export KONG_PROXY_LISTEN="0.0.0.0:443 ssl"
export KONG_SSL_CERT=/etc/ssl/api/fullchain.pem
export KONG_SSL_CERT_KEY=/etc/ssl/api/privkey.pem

Дополнительная политика:

plugins:
  - name: rate-limiting
    service: api-service
    config:
      minute: 600
      policy: local

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

5.7. Apache HTTP Server

<VirtualHost *:80>
    ServerName api.example.com
    Redirect permanent / https://api.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName api.example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/api/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/api/privkey.pem

    ProxyPreserveHost On
    ProxyAddHeaders On

    <Proxy "balancer://api">
        BalancerMember "http://127.0.0.1:3000"
        BalancerMember "http://127.0.0.1:3001"
        ProxySet lbmethod=byrequests
    </Proxy>

    ProxyPass "/" "balancer://api/"
    ProxyPassReverse "/" "balancer://api/"
</VirtualHost>

Требуются модули mod_ssl, mod_proxy, mod_proxy_http, mod_proxy_balancer, mod_lbmethod_byrequests и mod_headers для дополнительных заголовков при необходимости.

Apache HTTP Server остается жизнеспособным вариантом, особенно когда инфраструктура уже построена на нем.

5.8. Apache APISIX

Пример маршрута для Admin API:

{
  "uri": "/*",
  "host": "api.example.com",
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:3000": 1,
      "127.0.0.1:3001": 1
    }
  }
}

Конфигурация передается через Admin API, например в ресурс /apisix/admin/routes/1, с необходимым ключом администратора.

TLS-сертификаты и HTTPS listener настраиваются отдельно. Преимущество APISIX — динамическое обновление маршрутов и богатая модель плагинов.

5.9. Envoy Gateway

Для Kubernetes используются ресурсы Gateway API. Ниже показан фрагмент маршрутизации; предполагается, что Gateway, TLS listener и backend-сервисы уже созданы.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: public-gateway
      sectionName: https
  hostnames:
    - api.example.com
  rules:
    - backendRefs:
        - name: api-v1
          port: 3000
          weight: 1
        - name: api-v2
          port: 3001
          weight: 1

Здесь api-v1 и api-v2 — Kubernetes Services. Envoy Gateway преобразует ресурсы Gateway API в конфигурацию Envoy.

5.10. Varnish Cache

Varnish имеет другую задачу. Он обычно размещается за TLS-терминатором и перед origin.

vcl 4.1;

backend api1 {
    .host = "127.0.0.1";
    .port = "3000";
}

backend api2 {
    .host = "127.0.0.1";
    .port = "3001";
}

sub vcl_init {
    new api_pool = directors.round_robin();
    api_pool.add_backend(api1);
    api_pool.add_backend(api2);
}

sub vcl_recv {
    set req.backend_hint = api_pool.backend();
}

Для использования директора нужен импорт directors:

import directors;

Этот пример иллюстрирует Round Robin между backend. Для полноценного CDN необходимо дополнительно разработать правила кэширования, TTL, bypass, purge и обработки cookies.

5.11. Apache Traffic Server

Apache Traffic Server использует несколько конфигурационных файлов. Для базового reverse proxy в remap.config можно определить:

map https://api.example.com/ http://127.0.0.1:3000/

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

Поэтому конфигурацию ATS некорректно считать прямым аналогом нескольких строк Nginx. Его сильная сторона раскрывается не в минимальном API reverse proxy, а в сложной архитектуре кэширования и доставки контента.

5.12. Что показывает сравнение конфигураций

Продукт	Удобство простой конфигурации	Динамическое управление	Специализация
Nginx	Высокое	Среднее	Универсальный proxy
Caddy	Очень высокое	Высокое	HTTPS и простота
Traefik	Высокое	Очень высокое	Discovery
HAProxy	Высокое	Высокое	Балансировка
Envoy	Низкое вручную	Очень высокое	Control plane
Kong	Высокое	Очень высокое	API policies
Apache HTTP	Среднее	Среднее	Web
APISIX	Высокое	Очень высокое	API policies
Envoy Gateway	Высокое в Kubernetes	Очень высокое	Gateway API
Varnish	Среднее	Специализированное	Cache
ATS	Среднее	Специализированное	CDN

Ключевое наблюдение: краткость конфигурации не равна простоте эксплуатации. Envoy может выглядеть громоздким в YAML, но при наличии control plane его конфигурации вообще не редактируются вручную.

6. CDN и WAF: можно ли построить собственный Cloudflare?

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

Cloudflare объединяет несколько классов инфраструктуры: глобальную доставку контента, DNS, защиту от DDoS, WAF, управление ботами, TLS, маршрутизацию, аналитические сервисы и дополнительные edge-функции.

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

6.1. Из чего состоит CDN

CDN — это не просто сервер с включенным HTTP-кэшем.

Полноценная CDN должна решать как минимум пять задач:

Направлять пользователя к подходящей точке присутствия.
Хранить и выдавать популярные объекты из локального кэша.
Обращаться к origin при отсутствии объекта.
Согласованно управлять правилами кэширования и очисткой.
Поддерживать наблюдаемость, отказоустойчивость и безопасность всей сети.

PoP (Point of Presence) — узел сети, размещенный ближе к пользователям. Он может включать маршрутизаторы, TLS-прокси, WAF, кэширующие серверы и средства мониторинга.

Origin Shield — промежуточный уровень кэширования, который защищает origin от большого количества одновременных cache miss из разных PoP.

Control Plane — централизованная система, управляющая доменами, сертификатами, правилами, конфигурациями, политиками безопасности и очисткой кэша.

6.2. Какой движок выбрать для CDN

Движок	HTTP Cache	Edge TLS	Гибкость cache rules	Роль в CDN
Nginx	Да	Да	Высокая	Edge + Cache
Caddy	Через модули	Да	Зависит от модуля	Edge TLS
Traefik	Не основная функция	Да	Ограниченная	Ingress / Routing
HAProxy	Не полноценный CDN cache	Да	Ограниченная	L4/L7 Edge
Envoy	Через cache filters / интеграции	Да	Зависит от реализации	Edge / Routing
Kong	Ограниченные API cache-сценарии	Да	Через плагины	API Edge
Apache HTTP	Да	Да	Высокая	Web Cache
APISIX	Да, через соответствующие возможности	Да	Высокая	API Edge
Varnish	Очень развитый	Обычно внешний TLS	Очень высокая	HTTP Cache
ATS	Очень развитый	Да	Очень высокая	CDN Cache

Среди рассматриваемых продуктов для серьезного CDN особенно интересны Varnish Cache и Apache Traffic Server.

Nginx также способен эффективно кэшировать HTTP-контент и часто оказывается достаточным для небольшого регионального CDN.

6.3. Varnish или Apache Traffic Server?

Это один из наиболее важных архитектурных выборов.

Varnish Cache особенно удобен там, где правила кэширования тесно связаны с бизнес-логикой: разными TTL, cookies, заголовками, сегментами пользователей, персонализированным контентом и управлением cache keys.

VCL позволяет выразить достаточно сложную логику обработки запросов.

Apache Traffic Server интересен для инфраструктуры, ориентированной на большие объемы контента, иерархическое кэширование, disk cache и сетевые сценарии доставки.

Критерий	Varnish	Apache Traffic Server
Основная специализация	HTTP acceleration	Large-scale caching proxy
Язык правил	VCL	Конфигурация + плагины
Гибкость HTTP-логики	Очень высокая	Высокая
Disk cache	Требует выбора подходящей реализации/хранилища	Встроенная сильная сторона
TLS	Часто внешний terminator	Поддерживается
Многоуровневая CDN	Да	Да
Простота старта	Выше	Ниже
Типичный приоритет	Управление HTTP-кэшированием	Большие CDN-нагрузки

Для регионального CDN с несколькими PoP я бы в первую очередь проверял две архитектуры:

Nginx/HAProxy + Varnish и Apache Traffic Server как основной edge cache.

Выбор следует делать по измерениям cache hit ratio, throughput, p99, дисковых операций и поведения при отказах.

7. WAF: защита веб-приложений

WAF — это Web Application Firewall, система фильтрации HTTP-запросов на уровне приложения.

В отличие от сетевого firewall, который в основном анализирует адреса, порты и сетевые протоколы, WAF работает с HTTP-методами, URI, заголовками, cookies, параметрами и телом запроса.

7.1. От чего защищает WAF

Типичные классы угроз:

SQL injection.
Cross-site scripting (XSS).
Path traversal.
Аномальные и вредоносные HTTP-запросы.
Эксплуатация известных уязвимостей приложений.
Некоторые формы автоматизированного злоупотребления API.

Но WAF не заменяет безопасную разработку, управление уязвимостями и защиту от объемных DDoS-атак.

7.2. Основные open-source компоненты WAF

ModSecurity

Известный WAF engine с поддержкой правил SecLang. Исторически тесно связан с Apache HTTP Server, но используется и с другими веб-серверами через соответствующие коннекторы.

Coraza WAF

Современный WAF engine на Go, поддерживающий SecLang и OWASP CRS. Интересен для новых платформ благодаря возможностям интеграции с разными proxy/data-plane решениями.

OWASP Core Rule Set (CRS)

Набор правил для обнаружения распространенных атак на веб-приложения. CRS — не самостоятельный WAF engine, а правила, которые выполняются совместимым движком.

CrowdSec

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

BunkerWeb

Платформа защищенного reverse proxy, объединяющая несколько механизмов безопасности. Интересна как готовая основа для небольших защищенных edge-инсталляций.

7.3. Сравнение подходов

Решение	Роль	Главная ценность
ModSecurity	WAF engine	Зрелая экосистема SecLang
Coraza	WAF engine	Современная интеграционная модель
OWASP CRS	Набор правил	Базовая защита от типовых атак
CrowdSec	Detection / Remediation	Поведенческая защита
BunkerWeb	Security reverse proxy	Готовая сборка механизмов защиты

Для нового собственного CDN/WAF я бы оценивал Coraza + OWASP CRS как один из основных вариантов, а ModSecurity — как зрелую альтернативу.

Однако совместимость Coraza с конкретным прокси нужно проверять по поддерживаемым адаптерам и версиям. Нельзя считать, что любой WAF engine подключается к любому reverse proxy без разработки.

7.4. WAF и защита от DDoS — не одно и то же

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

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

Для серьезной DDoS-защиты требуются достаточная пропускная способность, сетевые политики, взаимодействие с провайдерами, BGP/Anycast и механизмы фильтрации до попадания трафика на прикладные серверы.

8. Архитектура собственного аналога Cloudflare

Теперь объединим рассмотренные технологии в одну платформу.

Сразу определим границы: под аналогом Cloudflare здесь понимается собственная инфраструктура CDN + WAF + TLS + DNS/Traffic Steering + API Edge + Observability.

Это не полное воспроизведение всех продуктов Cloudflare, включая Workers, Zero Trust, R2, глобальную DDoS-сеть и другие сервисы.

8.1. Рекомендуемая модульная архитектура

Reference architecture: собственная CDN/WAF

Логическая архитектура. В реальной реализации порядок WAF, кэша и API Gateway может отличаться, а часть функций может совмещаться. Для cache hits путь обычно завершается на кэше без обращения к origin.

Важное дополнение: WAF должен анализировать именно те запросы, которые требуют проверки. Например, размещение WAF только после кэша может означать, что cache hits обходят часть правил защиты. Напротив, размещение всех дорогостоящих проверок до кэша увеличивает стоимость каждого запроса.

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

8.2. Control Plane — самый недооцененный компонент

На первый взгляд кажется, что основная задача — выбрать прокси и WAF.

На практике коммерческая платформа требует гораздо больше.

Control Plane должен управлять:

Доменами и клиентскими аккаунтами.
TLS-сертификатами.
DNS и маршрутизацией.
Конфигурациями PoP.
Cache rules и purge.
WAF rules и исключениями.
Квотами и тарифами.
Аналитикой трафика.
Доступностью origin.
RBAC, аудитом и изменениями конфигураций.
Версионированием и rollback.

Именно здесь формируется значительная часть интеллектуальной собственности будущего продукта.

Сам reverse proxy может быть заменяемым open-source компонентом, тогда как control plane, единая модель объектов, пользовательские интерфейсы и автоматизация будут собственными разработками.

8.3. Наблюдаемость как конкурентное преимущество

Для CDN/WAF недостаточно знать, что сервер отвечает на HTTP-запросы.

Необходимо видеть:

Область	Метрики и события
CDN	Hit ratio, miss ratio, eviction, purge
Performance	RPS, p50/p95/p99, TTFB
Network	Throughput, packets, retransmits
WAF	Blocked/challenged requests, false positives
Origin	Errors, latency, health
Security	Attack patterns, bot signals
Economics	Traffic by customer, PoP, egress cost
Operations	Config versions, failed rollouts, incidents

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

8.4. Интеллектуальные функции

Современная платформа может включать не только фиксированные правила, но и алгоритмическую аналитику.

Adaptive WAF: динамическая оценка аномальности запросов с учетом истории конкретного клиента, API и географии.

Bot detection: поведенческие признаки автоматизированных клиентов, частота запросов, последовательности действий, репутационные сигналы.

Predictive caching: прогнозирование востребованности объектов и предварительное размещение популярных данных.

Traffic anomaly detection: обнаружение нетипичных изменений RPS, распределения статусов, географии и структуры запросов.

AI-assisted RCA: анализ инцидентов с использованием метрик, логов, трассировок и истории изменений конфигураций.

LLM Operations Assistant: интерфейс вопросов к состоянию платформы, документации, журналам инцидентов и постмортемам.

Важно: LLM не должен напрямую и бесконтрольно менять WAF-правила или маршрутизацию. Автоматические действия требуют проверяемых политик, ограничений, аудита и rollback.

9. Три варианта построения собственной CDN/WAF-платформы

Не обязательно сразу создавать глобальную сеть. Гораздо разумнее рассматривать три уровня развития.

MVP

Вариант A. Региональная CDN/WAF

1–3 PoP, HTTPS, кэширование, базовый WAF, управление доменами, аналитика, очистка кэша. Подходит для первых клиентов, пилотирования и проверки коммерческой модели.

Возможный стек: Nginx/HAProxy + Varnish + Coraza/CRS.

API Edge

Вариант B. Защищенная платформа API Edge

2–5 PoP, WAF, API authentication, rate limiting, квоты, наблюдаемость и клиентский портал. Ориентирована на SaaS, банки, операторов связи и B2B API.

Возможный стек: HAProxy/Envoy + Coraza + Kong/APISIX, с кэшем там, где он нужен.

CDN Network

Вариант C. Распределенная коммерческая CDN

10+ PoP, централизованный control plane, многоуровневое кэширование, интеллектуальная маршрутизация, собственные сетевые политики, биллинг и развитая безопасность.

Возможный стек: HAProxy/Envoy + ATS/Varnish + WAF + DNS/Traffic Steering + собственная система управления.

9.1. Сравнение трех вариантов

Критерий	Региональный CDN	API Edge	CDN Network
PoP	1–3	2–5	10+
Основной продукт	Кэш + WAF	Защита API	Доставка контента
Собственный control plane	Базовый	Развитый	Полноценный
Сложность сети	Низкая–средняя	Средняя	Высокая
DDoS	Через провайдера	Через провайдера / партнеров	Гибридная / собственная
Биллинг	Простой	API/трафик/запросы	Трафик, регионы, SLA
Сложность реализации	Средняя	Высокая	Очень высокая

9.2. Что действительно дорого в CDN

Важнейшие статьи расходов — не лицензии open-source прокси.

Это сетевой трафик, аренда стоек или серверов, порты и транзит, географическое присутствие, защита от атак, поддержка 24/7, инженерная команда и постоянная эксплуатация.

С ростом CDN меняется структура затрат.

Условная структура расходов по мере масштабирования

Иллюстративная модель распределения бюджета, не рыночная статистика и не финансовый прогноз.

На ранней стадии преобладают разработка и интеграция. При росте объемов доставки контента значимость сети и трафика увеличивается.

Но конкретная экономика зависит от географии, условий пиринга, доли cache hits, профиля трафика и договоров с инфраструктурными поставщиками.

9.3. Экономика кэширования

Предположим, CDN обслуживает 100 ТБ пользовательского трафика в месяц.

Упрощенная модель по объему переданных байтов. В реальной CDN byte hit ratio отличается от request hit ratio; повторные загрузки, cache fill, revalidation и origin shield также влияют на трафик.

Кэширование уменьшает нагрузку на origin, но не устраняет расходы на доставку трафика конечным пользователям. Более того, неудачная cache policy может создавать дополнительную нагрузку, если большое число PoP одновременно запрашивает один и тот же объект.

Поэтому архитектура Origin Shield, управление TTL и предотвращение cache stampede могут иметь непосредственный экономический эффект.

10. Какой стек для собственной платформы?

Для новой CDN/WAF-платформы можно не выбирать один универсальный прокси на все роли.

Вместо этого — разделил бы систему на специализированные компоненты.

Слой	Предпочтительный вариант	Альтернатива
Edge L4/L7	HAProxy	Nginx / Envoy
TLS	HAProxy / Nginx	Caddy
WAF	Coraza + OWASP CRS	ModSecurity + CRS
HTTP Cache	Varnish	Apache Traffic Server
API Gateway	Apache APISIX / Kong	Envoy filters
Dynamic routing	Traefik / Envoy Gateway	Собственный control plane
DNS	PowerDNS / Knot DNS	Коммерческий DNS
Metrics	Prometheus	Совместимая TSDB
Logs / Analytics	ClickHouse	OpenSearch
Configuration	GitOps + Control Plane	API-driven management
Event Bus	NATS / Kafka	По требованиям нагрузки

Здесь выбор между Varnish и ATS, а также между Kong и APISIX я оставил бы открытым до испытаний.

Также нет необходимости устанавливать API Gateway на каждый путь доставки статического контента. API-политики следует применять там, где они действительно нужны.

10.1. Что должно быть собственным

Для коммерческой платформы собственная разработка наиболее оправдана в следующих областях:

Единая объектная модель клиентов, доменов, приложений, PoP и политик.
Control Plane.
Клиентский и операторский интерфейсы.
Система конфигураций и безопасного rollout.
Аналитика и биллинг.
Корреляция событий безопасности и производительности.
Автоматизация диагностики и устранения инцидентов.

Сетевые и кэширующие движки при этом разумно оставить заменяемыми.

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

11. Roadmap создания собственной CDN/WAF

Этап 1. Архитектурный прототип — 4–6 недель
Проверить две комбинации edge/cache/WAF. Поднять тестовый стенд, настроить TLS, кэширование, базовые правила WAF и собрать метрики производительности.
Этап 2. MVP — 8–12 недель
Создать управление доменами, сертификатами, cache rules, WAF policies, клиентский кабинет и минимальную аналитику. Развернуть 1–3 PoP.
Этап 3. Коммерческий пилот — 8–12 недель
Подключить первых клиентов, реализовать биллинг, аудит, SLA-метрики, безопасный rollout и процедуры восстановления.
Этап 4. Региональное масштабирование — 3–6 месяцев
Увеличить число PoP, внедрить Origin Shield, автоматизированную маршрутизацию, централизованный purge и расширенную защиту.
Этап 5. Интеллектуальная платформа — параллельно и далее
Развивать алгоритмический RCA, прогнозирование нагрузки, адаптивные политики, анализ атак и LLM-помощника для операторов.

Сроки ориентировочные. Они предполагают использование готовых open-source компонентов и команду, имеющую опыт сетевой инфраструктуры, backend-разработки и эксплуатации. Создание собственной DDoS-сети и глобального Anycast в эти сроки не входит.

12. Миграция между платформами

Выбор новой технологии — только половина задачи. Вторая половина — безопасный переход.

Сложность миграции зависит прежде всего от числа используемых функций.

12.1. Матрица типовых миграций

Переход	Сложность	Основной риск
Nginx → Caddy	Низкая	Rewrite и TLS
Nginx → Traefik	Средняя	Переход к providers
Nginx → HAProxy	Низкая–средняя	Cache, ACL, статика
Nginx → Envoy	Высокая	Новая модель конфигурации
Nginx → Apache HTTP	Средняя	Директивы и модули
Kong → APISIX	Средняя–высокая	Эквивалентность плагинов
Traefik → Envoy Gateway	Средняя–высокая	Gateway API и политики
Varnish → ATS	Высокая	Cache semantics и storage
Apache HTTP → Nginx	Средняя	Rewrite, модули, приложения
Ingress NGINX → Gateway API	Средняя–высокая	Аннотации и поведение маршрутов

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

12.2. Безопасный процесс миграции

Перед переключением необходимо проверить не только обычные запросы, но и таймауты, WebSocket, gRPC, большие заголовки, загрузку файлов, передачу клиентского IP, rate limits и поведение при отказах.

Для CDN дополнительно проверяются cache keys, TTL, purge, stale responses и корректность обработки приватного контента.

Для WAF — false positives, исключения, правила блокировки и влияние на задержки.

13. Итоговая матрица выбора

Экспертная оценка применимости: 1 — слабое соответствие, 5 — сильное. Не является рейтингом скорости, надежности или популярности.

Визуальное сравнение по сценарию

Обычный веб-сервер / VPS

Docker и динамические сервисы

Kubernetes

Партнерские API

Высоконагруженный proxy

Собственный CDN / WAF

Оценки учитывают пригодность продукта к сценарию, но не стоимость интеграции, имеющуюся компетенцию команды и конкретные требования.

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

Например, Varnish получает высокую оценку для CDN, но не предназначен для полноценного управления потребителями API. Envoy Gateway хорош в Kubernetes, но не является естественным выбором для одиночного VPS.

14. Заключение. Побеждает не прокси, а архитектура

В 2026 году инфраструктурный рынок предлагает зрелые решения практически для любой модели обработки трафика.

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

Caddy демонстрирует ценность эксплуатационной простоты. Автоматический HTTPS и минимальная конфигурация позволяют небольшим командам сосредоточиться на приложениях.

Traefik особенно полезен там, где сервисы постоянно появляются и исчезают. Его основное преимущество — динамическая интеграция с инфраструктурой.

HAProxy — один из наиболее сильных кандидатов для высоконагруженной балансировки, управления соединениями и сложных L4/L7-сценариев.

Envoy предоставляет глубокие возможности программируемого управления трафиком в распределенных системах. Его сложность оправданна при наличии соответствующих требований и control plane.

Kong и Apache APISIX переводят работу с API на уровень политик, потребителей и управления сервисами. Они особенно ценны, когда API становится коммерческим продуктом.

Apache HTTP Server остается зрелым и актуальным инструментом, особенно в существующих корпоративных инфраструктурах.

Envoy Gateway отражает развитие Kubernetes Gateway API и более современной модели управления сетевым доступом в кластерах.

Varnish и Apache Traffic Server заслуживают отдельного внимания при проектировании CDN. Именно специализированное кэширование, а не просто HTTP-маршрутизация, становится ключевым фактором эффективности сети доставки контента.

А что насчет собственного Cloudflare?

Создать собственную региональную CDN/WAF-платформу на open-source компонентах технически вполне возможно.

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

Но главный барьер находится не в выборе reverse proxy.

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

Поэтому наиболее разумная стратегия — использовать проверенные open-source движки как data plane, а собственную интеллектуальную платформу строить вокруг управления, наблюдаемости, автоматизации и клиентского опыта.

Именно там возникает долгосрочная продуктовая ценность.

15. Источники и документация

Основные официальные ресурсы для проверки конфигураций и возможностей:

Проект	Документация
Nginx	nginx.org
Caddy	caddyserver.com
Traefik	doc.traefik.io
HAProxy	docs.haproxy.org
Envoy	envoyproxy.io
Kong	developer.konghq.com
Apache HTTP Server	httpd.apache.org
Apache APISIX	apisix.apache.org
Envoy Gateway	gateway.envoyproxy.io
Varnish Cache	varnish-cache.org
Apache Traffic Server	trafficserver.apache.org
OWASP CRS	coreruleset.org
Coraza	coraza.io
Kubernetes Gateway API	gateway-api.sigs.k8s.io

Для анализа распространенности и развития экосистемы полезны Netcraft, CNCF Reports и официальные репозитории проектов.

Методологическая оговорка: численные графики архитектурной пригодности и эксплуатационных затрат в статье являются экспертными или иллюстративными моделями. Они не заменяют сравнительных нагрузочных испытаний. Конфигурации следует проверять на конкретных версиях продуктов перед использованием в production.