Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.

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

HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

Итак, начинаем. Рассматриваем самые свежие релизы на дату публикации.

План разбора:

1. Цель и версии (только open source, последние доступные stable-ветки)

2. Архитектура (Модель потоков/процессов, event-loop, статическая vs динамическая конфигурация (xDS, Data Plane API).

3. Поддерживаемые протоколы L4/L7 (HTTP/1.1, HTTP/2, HTTP/3/QUIC, gRPC, WebSocket, TCP/UDP)

4. Балансировка и маршрутизация (Алгоритмы round-robin, least-conn, hash, L7-маршруты, аффинити)

5. Надежность и отказоустойчивость (Health-check, retries, circuit-breaking, rate-limiting)

6. Наблюдаемость (Метрики Prometheus/StatsD, логи, OpenTelemetry/Jaeger, трассировка)

7. Безопасность (TLS 1.3, mTLS, RBAC, OAuth/JWT)

8. Переменные (Область видимости, встроенные, динамические)

9. Таймауты (виды, где\как применять, принцип работы)

10. Kubernetes-интеграция (gateway, ingress, service mesh)

Архитектура

HAProxy. Высокопроизводительный L4/L7-прокси с моделью master–worker и неблокирующим event-loop. Мастер руководит процессами, воркеры обрабатывают трафик — как шеф-повар, который не трогает еду, но следит, чтобы повара не спали. Поддерживает TCP/HTTP, TLS-терминацию, health-checks и продвинутые алгоритмы балансировки. Конфигурация статична, но есть Runtime API для живых правок; полный reconfigure делается через бесшовный reload. Типовой кейс: frontend принимает HTTPS, терминирует TLS, выбирает backend по leastconn и отправляет запрос — pipeline прозрачнее, чем бюджет в стартапе.

NGINX. Архитектура «master + workers». Воркеры принимают TLS/HTTP, парсят протокол, применяют фильтры, кеш и проксируют на upstream. Хорошо подходит для статических и программируемых конфигураций, если «динамика» нужна только на уровне переменных и Lua. Перезагрузка конфигурации обычно бесшовная: старые воркеры завершают запросы, новые уже готовы — никакой драмы, кроме как у админа в 3 ночи. Типовой кейс: server с proxy_pass на пул API, с кешем и ограничениями скорости по ключу. JWT/OAuth? Или Plus, или Lua — выбирайте, что меньше ломает мозг.

Envoy. Динамический L4/L7-прокси с фильтровой архитектурой и управлением через xDS. Конфигурация подтягивается из контрольной плоскости в реальном времени, маршрутизация гибкая до абсурда: можно отправить трафик хоть на кофемашину, если она объявилась в EDS. Поддерживает HTTP/1.1, HTTP/2, HTTP/3, gRPC, ретраи, метрики и обновляется через hot-restart без обрыва сокетов — хоть разворачивайся каждую минуту. Типовой кейс: listener с TLS, далее цепочка фильтров (ALPN → HTTP/2 → router) маршрутизирует gRPC-потоки по кластерам, которые сами приходят и уходят, как разработчики после демо.

Итого по архитектуре:

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

• NGINX — стабильность и зрелая экосистема, но с ограниченной гибкостью.

• Envoy — динамика и API-центричность, но сложнее в эксплуатации.

Поддерживаемые протоколы

HAProxy работает как TCP/UDP-прокси и полнофункциональный HTTP-прокси. Поддерживает HTTP/1.1, HTTP/2 и HTTP/3 (QUIC), включая ALPN (Application-Layer Protocol Negotiation) и SNI (Server Name Indication). Может терминировать TLS или проксировать TLS passthrough. gRPC работает в режиме HTTP/2 без сторонних плагинов.

frontend fe
  mode http
  bind :80
  bind :443  ssl crt /etc/haproxy/certs/foo.com/cert.crt alpn h2
  bind quic4@:443 ssl crt /mycert.pem alpn h3
  http-request redirect scheme https unless { ssl_fc }
  http-after-response add-header alt-svc 'h3=":443"; ma=60'

backend be_api
    mode http
    option httpchk GET /health
    server s1 10.0.0.31:443 ssl verify none sni str(api.example.com) alpn h2 check
    server s2 10.0.0.32:443 ssl verify none sni str(api.example.com) alpn h2 check

Входящий TLS-трафик принимается на порту 443, ALPN выбирает HTTP/2 или HTTP/3, затем HAProxy терминирует соединение, балансирует по серверам с поддержкой h2 и шифрует трафик заново. Плюсы: высокая производительность на L4 и L7, зрелая поддержка HTTP/2. Минусы: настройка HTTP/3/QUIC требует проверки и ручной конфигурации; для сложных L7-правил доступны только ACL и Lua. Downstream/Upstream: HAProxy может принимать HTTP/1.1, HTTP/2 или HTTP/3 от клиентов (downstream) и независимо использовать любой протокол при подключении к бэкенду (upstream). Возможны сценарии h1→h2, h2→h1, h2→h2, h3→h1 и т.д., что позволяет менять протокол между клиентом и сервером без ограничений.

NGINX работает как TCP-stream прокси и как HTTP-прокси. Поддерживает HTTP/1.1 и HTTP/2 из коробки. HTTP/3/QUIC доступен с версии 1.25+ через директивы quic и http3. gRPC поддерживается через отдельный модуль grpc_pass, который работает поверх HTTP/2.

server {
    listen 443 ssl http2;
    ssl_certificate     /etc/nginx/certs/site.pem;
    ssl_certificate_key /etc/nginx/certs/site.key;

    location / {
        proxy_pass https://backend_pool;
        proxy_http_version 1.1;
    }
}

server {
    listen 8443 quic reuseport;
    listen 8443 ssl;
    ssl_certificate     /etc/nginx/certs/site.pem;
    ssl_certificate_key /etc/nginx/certs/site.key;

    location /api {
        add_header Alt-Svc 'h3=":8443"; ma=86400';
        proxy_pass https://backend_pool;
        proxy_http_version 1.1;
    }
}

upstream backend_pool {
    least_conn;
    server 10.0.0.31:443;
    server 10.0.0.32:443;
}

NGINX принимает TLS-соединения и включает HTTP/2 или HTTP/3 для клиентов, но к backend всё равно ходит по HTTP/1.1 (кроме gRPC). Плюсы: стабильный HTTP/2, простой конфиг. Минусы: HTTP/3 менее зрелый и требует ручного включения; stream-режим TCP не даёт детальной L7-логики; расширенные функции доступны только в Plus-версии. Downstream/Upstream: клиенты могут подключаться по HTTP/1.1, HTTP/2 или HTTP/3, но к backend соединение будет по HTTP/1.1 (кроме gRPC-location).

Envoy изначально построен как L4/L7-прокси с поддержкой TCP/UDP HTTP/1.1, HTTP/2, HTTP/3 и gRPC. Протоколы выбираются автоматически через ALPN, а фильтры позволяют обрабатывать как TCP, так и полный HTTP-поток. Для upstream на TLS/443 необходимо включить http2_protocol_options и настроить transport_socket для TLS.

admin:
  address:
    socket_address:
      address: 127.0.0.1
      port_value: 9901

static_resources:
  listeners:
  - name: main_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 443
    # TLS конфигурация для HTTPS
    listener_filters:
    - name: envoy.filters.listener.tls_inspector
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.listener.tls_inspector.v3.TlsInspector

    filter_chains:
    - filter_chain_match:
        application_protocols: ["h2", "http/1.1"]
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsConfig
          common_tls_context:
            tls_certificates:
            - certificate_chain: {filename: "/etc/envoy/cert.pem"}
              private_key: {filename: "/etc/envoy/privkey.pem"}
          require_client_certificate: false
      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
          http2_protocol_options: {}
          http_protocol_options: {}
          codec_type: AUTO

          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: {prefix: "/"}
                route: {cluster: backend_cluster}

          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

    # Отдельный filter chain для HTTP/3
    - filter_chain_match:
        transport_protocol: "quic"
      transport_socket:
        name: envoy.transport_sockets.quic
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransportConfig
          downstream_tls_context:
            common_tls_context:
              tls_certificates:
              - certificate_chain: {filename: "/etc/envoy/cert.pem"}
                private_key: {filename: "/etc/envoy/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_quic
          http2_protocol_options: {}
          http_protocol_options: {}
          codec_type: HTTP3

          route_config:
            name: local_route_quic
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: {prefix: "/"}
                route: {cluster: backend_cluster}

          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

    # UDP listener для QUIC
    udp_listener_config:
      quic_options: {}

  clusters:
  - name: backend_cluster
    connect_timeout: 5s
    type: STATIC
    lb_policy: ROUND_ROBIN
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    load_assignment:
      cluster_name: backend_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8080

Envoy listener принимает соединения на 443, сам определяет протокол (h1/h2/h3), маршрутизирует поток на пул с тем же протоколом или переводит его в нужный режим. gRPC обрабатывается нативно через HTTP/2. Плюсы: полная поддержка современных протоколов, гибкость через фильтры, без перезапуска можно менять маршруты. Минусы: выше потребление ресурсов, сложнее конфигурация для простых TCP-сценариев. Downstream/Upstream: Envoy автоматически конвертирует любые протоколы — h1↔h2↔h3 в любых комбинациях. Можно принимать h3 downstream и ходить к бэкенду по h1, или наоборот.

HAProxy — чемпион по скорости, будто с допингом. Глотает TCP, HTTP/1.1, HTTP/2, HTTP/3 и даже gRPC без костылей. Протокол downstream/upstream можно миксовать как коктейли на корпоративе — хоть h3→h1, хоть h1→h2. Минус: для QUIC придётся повозиться с ручной настройкой, а за сложные L7-правила — только ACL и Lua, никакой встроенной магии. Но зато latency минимальная, как у хорошего эспрессо.

NGINX — надёжен как дедовский жигуль: HTTP/2 держит стабильно, HTTP/3 прикручен «на синюю изоленту», а сложной L7-логики не жди. TCP через stream идёт, но апгрейд backend до h2 не завезут — хочешь комфорта, смотри NGINX Plus.

Envoy — как инженер с немецким дипломом: жонглирует h1/h2/h3 фильтрами, не потея и не перезапускаясь. Downstream хоть HTTP/3, backend хоть HTTP/1.1 — всё под контролем. Но ресурсы ест как браузер с сотней вкладок и требует знаний на уровне DevOps-соревнований.

Вывод:

• HAProxy — брать, если нужна минимальная задержка и зрелый HTTP/1/2 без плясок.

• NGINX — выбрать для стабильного HTTP/1/2 и простого конфига, но помнить про слабый upstream-функционал.

• Envoy — король gRPC и любых протокольных миксов, но для банального L4-прокси это как на Porsche картошку возить.

Балансировка и маршрутизация

HAProxy поддерживает алгоритмы балансировки: roundrobin, leastconn, source, uri, hdr, consistent-hash. Маршрутизация уровня L7 реализуется через ACL: можно матчить по URI, заголовкам, TLS-отпечаткам (JA3/JA4) с использованием Lua.

frontend fe_api
    bind :443 ssl crt /etc/haproxy/certs/api.pem
    acl v1 path_beg /v1/
    use_backend be_v1 if v1
    default_backend be_v2

backend be_v1
    balance leastconn
    server s1 10.0.0.41:443 ssl verify none check
    server s2 10.0.0.42:443 ssl verify none check

backend be_v2
    balance uri
    hash-type consistent
    server s3 10.0.0.43:443 ssl verify none check
    server s4 10.0.0.44:443 ssl verify none check

Фронтенд принимает HTTPS-запросы, проверяет путь /v1/ и отправляет их в пул be_v1 с балансировкой по наименьшему числу активных подключений. Остальные запросы попадают в пул be_v2 с консистентным хешированием URI.

NGINX поддерживаемые алгоритмы: round_robin (по умолчанию), least_conn, ip_hash, hash с опцией consistent. Маршруты уровня L7 задаются через location. Конфигурация обновляется только через reload.

upstream api_v1 {
    least_conn;
    server api1.local:443;
    server api2.local:443;
}
upstream api_v2 {
    hash $request_uri consistent;
    server api3.local:443;
    server api4.local:443;
}
server {
    listen 443 ssl http2;
    ssl_certificate     /etc/nginx/certs/api.pem;
    ssl_certificate_key /etc/nginx/certs/api.key;
    proxy_ssl_server_name on;
    location /v1/ { proxy_pass https://api_v1; }
    location /    { proxy_pass https://api_v2; }
}

Запросы к /v1/ перенаправляются на пул api_v1 с алгоритмом least_conn. Остальные — на api_v2 с консистентным хешированием URI.

Envoy поддерживает алгоритмы: round_robin, least_request, maglev, ring_hash, а также веса, канареечные релизы, shadow-трафик. Управление и маршрутизация меняются динамически через xDS.

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/envoy/tls/api.crt" }
              private_key:       { filename: "/etc/envoy/tls/api.key" }
      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
          route_config:
            virtual_hosts:
            - name: api
              domains: ["*"]
              routes:
              - match: { prefix: "/v1/" }
                route: { cluster: api_v1 }
              - match: { prefix: "/" }
                route: { cluster: api_v2 }
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: api_v1
    lb_policy: LEAST_REQUEST
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: "api.internal"
    load_assignment:
      cluster_name: api_v1
      endpoints:
      - lb_endpoints:
        - endpoint: { address: { socket_address: { address: api1.local, port_value: 443 }}}
  - name: api_v2
    lb_policy: MAGLEV
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: "api.internal"
    load_assignment:
      cluster_name: api_v2
      endpoints:
      - lb_endpoints:
        - endpoint: { address: { socket_address: { address: api3.local, port_value: 443 }}}

Envoy слушает HTTPS-трафик на порту 443, маршрутизирует запросы по префиксу URI: /v1/ → кластер api_v1 (least_request), / → кластер api_v2 (Maglev). Все соединения к апстримам идут по TLS с проверкой SNI.

HAProxy — работает как швейцарский механизм: поддерживает roundrobin, leastconn, source, uri, hdr, consistent-hash — всё стабильно и предсказуемо. L7-маршруты через ACL: можно матчить по URI, заголовкам, даже по TLS-отпечаткам (JA3/JA4). Конфигурация статична, но понятна и прозрачна.

NGINX — минимализм без сюрпризов: доступны только round_robin, least_conn, ip_hash. HTTP-маршруты задаются через location, но без динамических алгоритмов или ring_hash. Sticky-сессии — только через ip_hash, API для внешнего управления нет, расширенные возможности балансировки есть только в NGINX Plus. Хорош, если конфиг «разложил и забыл», а трафик стабилен.

Envoy — тяжёлая артиллерия: поддерживает round_robin, least_request, maglev, ring_hash, веса, канареечные релизы, shadow-трафик. Всё управляется динамически через xDS — можно менять маршруты хоть каждую секунду. Но YAML-схемы перегружены и требуют опыта, иначе будет больно. Для сложной продакшен-динамики — это лучший выбор, но придётся вложиться в автоматизацию и обучение.

Выводы:

• HAProxy — низкая задержка и предсказуемый контроль L4/L7. Настроил ACL — и работает.

• NGINX — статические маршруты без динамических требований. Конфиг «разложил и забыл».

• Envoy — динамическое управление, канареечные релизы и сложные политики, но конфигурация громоздкая и требует автоматизации.

Надежность и отказоустойчивость

HAProxy обеспечивает встроенные механизмы отказоустойчивости на L4 и L7: активные health-check, повторные попытки при ошибках, circuit breaker через лимиты соединений, а также защиту от перегрузки через stick-tables.

global
  maxconn 20000 # верхний предел соединений на процесс HAProxy

defaults
  maxconn 10000 # лимит для фронтендов/бэкендов по умолчанию

backend be_api
  mode http
  option httpchk GET /health
  retry-on all-retryable-errors
  retries 3
  http-request disable-l7-retry if METH_POST METH_PUT METH_DELETE
  default-server inter 2s fall 3 rise 2
  server s1 10.0.0.51:443 ssl verify none maxconn 500
  server s2 10.0.0.52:443 ssl verify none maxconn 500
  stick-table type ip size 1m expire 10m store conn_rate(10s)
  tcp-request connection track-sc0 src
  tcp-request connection reject if { sc0_conn_rate gt 100 }

Серверы проверяются каждые две секунды по пути /health. Они исключаются из пула после трёх неудачных ответов и возвращаются обратно после двух успешных. Если лимит подключений к серверу (500 соединений) превышен, лишние запросы становятся в очередь и ожидают timeout queue (по умолчанию — от timeout connect), после чего возвращается 503. Параметр retries 3 выполняет до трёх попыток соединения (исходная + до двух повторов), а опция retry-on all-retryable-errors и директива http-request disable-l7-retry гарантируют, что HAProxy будет повторять только идемпотентные методы и не будет ретраить POST, PUT, DELETE. Параметры global maxconn и server maxconn задают верхние пределы соединений на процесс и на каждый backend. Практический предел зависит также от лимита файловых дескрипторов (ulimit -n), поскольку одно проксируемое соединение обычно требует два FD(≈1–2 FD на сессию). Дополнительно stick-tables отслеживают частоту подключений и блокируют источник при превышении порога, например 100 соединений за 10 секунд.

NGINX использует пассивные health-check (max_fails/fail_timeout) и proxy_next_upstream для fallback. Важно понимать нюанс подсчёта повторов: proxy_next_upstream_tries N считается на всю upstream-группу, то есть при proxy_next_upstream_tries 3 реально получается исходный запрос + до 2 повторов по остальным серверам (итого 1 + 2), а не 1 + 3 для каждого backend.

worker_processes auto;
worker_rlimit_nofile 4096; # максимальное количество файловых дескрипторов, которые может использовать один worker-процесс 

events {
  worker_connections 2048; # максимальное число одновременных соединений, которые может обработать один worker-процесс 
  multi_accept on;
}

http {
  upstream api_pool {
    least_conn;
    server 10.0.0.51 max_fails=3 fail_timeout=5s;
    server 10.0.0.52 max_fails=3 fail_timeout=5s;
  }

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

  server {
    listen 443 ssl;
    limit_req zone=req_limit burst=50;
    proxy_pass https://api_pool;
    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_next_upstream_tries 3;
  }
}

При трёх ошибках подряд сервер исключается из пула на пять секунд. Для ограничения нагрузки используются limit_req и limit_conn, которые регулируют частоту и количество запросов на клиента или глобально. Максимальное число соединений на процесс определяется как минимум из worker_connections и worker_rlimit_nofile, а реальный предел для всех воркеров равен произведению числа процессов на лимит воркера, с учётом того, что одно проксируемое соединение использует около двух файловых дескрипторов. В Open-Source NGINX нет per-backend лимитов, аналогичных server maxconn; эти возможности (max_conns и очередь на апстриме) есть только в NGINX Plus.

Envoy предоставляет полный набор инструментов: активные health-check (HTTP/TCP/gRPC), circuit breaking с лимитами по соединениям, запросам и ошибкам, retries с гибкой политикой, outlier detection для автоматического исключения проблемных узлов и фильтры для ограничения входящих соединений

static_resources:
  listeners:
  - name: https_listener
    address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
    filter_chains:
    - filters:
      - name: envoy.filters.network.connection_limit
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.connection_limit.v3.ConnectionLimit
          stat_prefix: conn_limit
          max_connections: 10000
          delay: 0s
      - 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
          route_config: { ... }
          http_filters: [ { name: envoy.filters.http.router } ]

  clusters:
  - name: api_pool
    lb_policy: LEAST_REQUEST
    circuit_breakers:
      thresholds:
      - max_connections: 500
        max_requests: 1000      
    health_checks:
    - timeout: 1s
      interval: 2s
      unhealthy_threshold: 3
      healthy_threshold: 2
      http_health_check: { path: /health }
    outlier_detection:
      consecutive_5xx: 5
      interval: 5s
      base_ejection_time: 30s

Фильтр connection_limit ограничивает входящие соединения на listener, а circuit breakers задают пределы подключений и одновременных запросов к каждому кластеру. Механизм retries настраивается в retry_policy: параметр num_retries определяет только повторные попытки, всего выполняется исходный запрос + num_retries, а условия повтора можно задавать детально (например, только при отказе соединения или только при ответах 503) с использованием экспоненциального backoff. Количество файловых дескрипторов управляется на уровне ОС через ulimit -n, а перегрузка отдельных серверов контролируется с помощью outlier detection, автоматически исключающего узлы с избыточными ошибками 5xx.

HAProxy — как строгий охранник у клуба: лишние соединения не пустит, пьяных клиентов выгонит (stick-tables), сердцебиение проверяет каждую секунду. Circuit breaker настраивается вручную, но работает чётко. Минус: сложные сценарии придётся писать на Lua или подключать внешнюю автоматику — без этого всё руками, как в старой школе DevOps.

NGINX — охранник без рации: может заметить, что клиент упал, но только если он реально свалился на пол. Активных health-check нет (оставили для платной версии), circuit breaker в зачатке. Зато лимиты соединений и запросов задаются парой директив, без магии и Lua. Хорош для стабильных пулов, где никто не бегает и свет не мигает.

Envoy — охранник с камерой, тепловизором и аналитикой на ИИ: активные проверки, circuit breaker на всё подряд, outlier detection, retries с умной задержкой. Встроенный или внешний rate limiting — на выбор. Минус: он просит больше зарплату (CPU/memory) и инструктаж посложнее, иначе случайно закроет дверь даже перед хозяином.

Вывод:

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

• NGINX — подойдёт, если достаточно пассивных проверок и простых лимитов без динамики.

• Envoy — подходит для живых систем с автоскейлом и централизованным контролем трафика, но требует аккуратного обращения.

Наблюдаемость

HAProxy выводит подробные логи через syslog (RFC5424/3164), поддерживает structured logging (JSON) через log-format и экспорт метрик в Prometheus через встроенный prometheus-exporter или stats socket. Встроенный веб-статус (stats uri) есть, но распределённой трассировки нет — требуются внешние агенты (Jaeger, Zipkin).

global
    log stdout format raw local0
    stats socket /var/run/haproxy.sock mode 600 level admin
    stats timeout 30s

defaults
    log global
    option httplog
    log-format { "time":"%t", "frontend":"%f", "backend":"%b", "srv":"%s", "status":%ST, "bytes":%B }

frontend prometheus
    bind *:8405
    mode http
    http-request use-service prometheus-exporter if { path /metrics }
    no log

Логи пишутся в stdout, метрики публикуются по http://<host>:8405/metrics. Плюсы: минимальные накладные расходы, детальные логи. Минусы: нет встроенной трассировки запросов, приходится интегрировать вручную.

NGINX поддерживает access/error логи, может логировать в JSON для экспорта в ELK/Graylog. Метрики — только через сторонние модули (nginx-module-vts, nginx-prometheus-exporter). Встроенной распределённой трассировки нет (в отличие от NGINX Plus, где есть OpenTelemetry).

http {
    log_format json_combined escape=json
        '{ "time":"$time_iso8601",'
        '"remote":"$remote_addr",'
        '"host":"$host",'
        '"request":"$request",'
        '"status":$status,'
        '"bytes":$body_bytes_sent }';

    access_log /var/log/nginx/access.json json_combined;

    server {
        listen 80;
        location / {
            proxy_pass http://10.0.0.52:8080;
        }
    }
}

Трафик логируется в JSON, готов для парсинга внешними системами. Плюсы: гибкий формат логов, легко подключать ELK. Минусы: нет нативных метрик и трассировки, нужен внешний экспортер.

Envoy из коробки поддерживает structured logging, метрики в Prometheus, а также OpenTelemetry для распределённой трассировки (Jaeger, Zipkin, Datadog). Каждый фильтр может генерировать собственные статистики.

admin:
  access_log_path: /dev/stdout
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }

tracing:
  http:
    name: envoy.tracers.opentelemetry
    typed_config:
      "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
      grpc_service:
        envoy_grpc:
          cluster_name: otel_collector

Envoy пишет логи и метрики напрямую(http://<host>:9901/stats/prometheus), трассировка передается в OpenTelemetry Collector. Плюсы: нативная поддержка Prometheus и трассировки, детализированные метрики L4/L7.

HAProxy — пишет логи быстро и честно, как будто ведёт дневник без цензуры. Легко отдаёт метрики Prometheus через экспортер, а встроенный веб-статус даёт картинку без лишних зависимостей. Но трассировку придётся прикручивать самому — Lua, агенты, шаманский бубен.

NGINX — логи делает удобоваримыми в JSON и сразу готовыми для ELK, но метрики и трассировка — только через сторонние модули или экспортеры. Конфигурация простая, но никакой нативной магии для L7-метрик или распределённого следа. То есть видно, кто зашёл, но не куда он потом пошёл.

Envoy — наблюдает за всем, как параноидальный сосед с биноклем на пенсии. Логи структурированы, метрики идут прямо в Prometheus, а OpenTelemetry встроен из коробки: можно смотреть трассировку запроса от клиента до базы без внешних костылей. Минус: съедает больше ресурсов и требует аккуратной настройки, иначе легко утонуть в собственных графиках.

Вывод:

• HAProxy — лёгкий и быстрый, но наблюдаемость только базовая.

• NGINX — нормальные логи, но за метрики и трассировку придётся платить сторонними модулями и временем.

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

Безопасность

HAProxy — поддерживает TLS 1.3 и mTLS прямо на фронтендах, с версии 2.5 умеет проверять JWT и OAuth2 без внешних сервисов (http_auth_bearer, jwt_verify, jwt_payload), а для RBAC применяют ACL и переменные. Zero Trust-сценарии реализуемы через SPIFFE/SPIRE, но требуют дополнительного glue-кода для ротации ключей.

frontend https_in
  bind :443 ssl crt /etc/haproxy/certs.pem ca-file /etc/haproxy/ca.pem verify required
  http-request set-var(txn.jwt)       http_auth_bearer
  http-request set-var(txn.verified)  var(txn.jwt),jwt_verify(alg=RS256,key=/etc/haproxy/jwks.json)
  http-request deny if { var(txn.verified) -m int 0 }
  http-request set-var(txn.role)      var(txn.jwt),jwt_payload,query(role)
  acl role_admin var(txn.role) -m str admin
  http-request deny unless role_admin
  default_backend web

Производительность высокая, функционал политик менее гибкий, чем в Envoy, но достаточно для edge-защиты. За подробностями можно глянуть здесь. В OSS нативного WAF нет. Обычно используют ModSecurity через SPOE-агент или выносят проверку во внешний сервис с правилами OWASP CRS. Это добавляет операционную сложность и накладные расходы.

NGINX — прост в эксплуатации, но без встроенной проверки JWT в OSS-версии. TLS 1.3 и mTLS поддерживаются через стандартный ssl-модуль. JWT, OIDC и сложные RBAC-сценарии реализуют через внешний авторизатор (чаще всего oauth2-proxy) с auth_request или через Lua/OpenResty. Zero Trust возможен, но интеграция со SPIFFE/SPIRE полностью ручная

server {
  listen 443 ssl;
  ssl_certificate     /etc/nginx/ssl/server.crt;
  ssl_certificate_key /etc/nginx/ssl/server.key;
  ssl_client_certificate /etc/nginx/ssl/ca.pem;
  ssl_verify_client on;

  location / {
    auth_request /oauth2/auth;
    error_page 401 = /oauth2/sign_in;
    proxy_set_header X-Auth-Request-User  $upstream_http_x_auth_request_user;
    proxy_set_header X-Auth-Request-Email $upstream_http_x_auth_request_email;
    proxy_pass http://backend;
  }
  location = /oauth2/auth { internal; proxy_pass http://oauth2-proxy; }
  location /oauth2/       {           proxy_pass http://oauth2-proxy; }
}

Прост в эксплуатации, надёжен, но без внешнего авторизатора сложные политики реализовать трудно. В OSS встроенного WAF нет. Чаще всего применяют libmodsecurity + модуль ModSecurity-nginx с профилем OWASP CRS. Всё настраивается вручную, нужно следить за обновлением правил и тюнинговать под нагрузку.

Envoy — оптимален для Zero Trust. Поддерживает TLS 1.3, mTLS, динамическую загрузку сертификатов через SDS, встроенные фильтры JWT, RBAC и OAuth2. Интеграция со SPIFFE/SPIRE нативная, сертификаты обновляются автоматически. OAuth2/OIDC решают через внешний IdP совместно с jwt_authn или ext_authz

static_resources:
  listeners:
  - name: main_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - 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: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: service_cluster

          http_filters:
          - name: envoy.filters.http.jwt_authn
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
              providers:
                example_provider:
                  issuer: https://example.com
                  audiences:
                  - api.example.com
                  remote_jwks:
                    http_uri:
                      uri: https://example.com/.well-known/jwks.json
                      cluster: jwks_cluster
                      timeout: 1s
                    cache_duration:
                      seconds: 300

          - name: envoy.filters.http.rbac
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
              rules:
                policies:
                  "require-valid-jwt":
                    permissions:
                      - any: true
                    principals:
                      - metadata:
                          filter: envoy.filters.http.jwt_authn
                          path:
                            - key: example_provider
                          value:
                            string_match:
                              exact: verified

          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: service_cluster
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

  - name: jwks_cluster
    connect_timeout: 5s
    type: LOGICAL_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: jwks_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: example.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: example.com

JWT проверяется через jwt_authn filter с поддержкой локальных и удалённых JWKS, а RBAC-фильтр позволяет описывать allow/deny-политику прямо в конфигурации. WAF: встроенного решения нет. Используют WASM-фильтры на базе Coraza (правила совместимы с OWASP CRS) или интегрируют Curiefense как Envoy-фильтр. Подход открытый, но требует тестов под прод-нагрузкой и ручной настройки правил.

HAProxy — шифрует быстро, JWT/OAuth2 проверяет нативно с версии 2.5 без лишних зависимостей. TLS 1.3 и mTLS на фронтендах, ACL и переменные для RBAC. Zero Trust через SPIFFE/SPIRE возможен, но придётся дописывать собственный «клей» для ротации ключей и распределения SVID. Хорош, когда важны скорость и простые политики без лишней магии.

NGINX — настраивается так же легко, как добавить новый upstream. TLS 1.3 и mTLS встроены, но JWT и OIDC в OSS нет — всё решается через внешний авторизатор (чаще oauth2-proxy). Сложный RBAC потребует вынесенной логики. Zero Trust сценарии возможны, но интеграция полностью ручная. Конфиг прост, но возможностей меньше, чем у HAProxy и Envoy.

Envoy — Zero Trust в чистом виде. TLS 1.3, mTLS, SDS для динамики ключей, встроенные фильтры JWT, RBAC, OAuth2. SPIFFE/SPIRE подключается нативно, сертификаты обновляются сами. Можно строить политику хоть под микроскопом, без лишних костылей.

Вывод:

• HAProxy — быстрый минимализм: простые ACL и встроенная JWT/OAuth2-проверка.

• NGINX — надёжен и понятен, но для сложных политик нужны внешние сервисы.

• Envoy — всё для Zero Trust из коробки: TLS, mTLS, JWT, RBAC, OAuth2, SDS и SPIFFE.

Переменные

HAProxy — переменные бывают как коты в коробке Шрёдингера: живут то в транзакции (txn.*), то в сессии (sess.*), то в запросе (req.*) или ответе (res.*). Можно хранить что угодно: IP, токены, промежуточные флаги. Эти переменные легко помещать в ACL, логи или Lua.

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/site.pem alpn h2,http/1.1
    mode http
    http-request set-var(txn.client_ip) src
    http-request set-header X-Client-IP %[var(txn.client_ip)]
    default_backend be_api

backend be_api
    mode http
    http-request set-var(sess.backend_name) be_api
    server s1 10.0.0.31:443 ssl verify none
    server s2 10.0.0.32:443 ssl verify none

Здесь IP клиента записывается в переменную транзакции и сразу же уезжает в заголовок. Переменная sess.backend_name живёт дольше — пока TCP-сессия не умрёт. Плюсы: быстрые ACL, всё можно хранить прямо в прокси. Минусы: сложные сценарии часто требуют Lua — готовься писать код прямо в конфиге, как в 2000-х.

NGINX — переменные как студенты на паре: появляются только на время запроса, потом испаряются. Есть встроенные ($host, $remote_addr) и те, что задаёшь руками через set. Между запросами память не держат — хочешь что-то протащить дальше, прокидывай заголовки или ставь cookie.

server {
    listen 443 ssl http2;
    ssl_certificate     /etc/nginx/certs/site.pem;
    ssl_certificate_key /etc/nginx/certs/site.key;

    set $client_ip $remote_addr;

    location / {
        proxy_set_header X-Client-IP $client_ip;
        proxy_pass https://backend_pool;
    }
}

upstream backend_pool {
    least_conn;
    server 10.0.0.31:443;
    server 10.0.0.32:443;
}

Переменная $client_ip живёт ровно один запрос, как батарейка в китайском фонарике. Плюсы: просто, стабильно, никаких утечек состояния. Минусы: никакой «долгой памяти», всё руками через заголовки.

Envoy — вместо переменных тут подстановки и метаданные. %DOWNSTREAM_REMOTE_ADDRESS%, %REQ(:authority)%, %UPSTREAM_HOST% и десятки других. Можно хранить временные данные прямо внутри фильтров — хочешь память на уровень TCP, хочешь на уровень HTTP-запроса.

static_resources:
  listeners:
  - name: https_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - 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
          route_config:
            virtual_hosts:
            - name: api
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: 
                  cluster: api_pool
                  request_headers_to_add:
                  - header:
                      key: X-Client-IP
                      value: "%DOWNSTREAM_REMOTE_ADDRESS%"
          http_filters:
          - name: envoy.filters.http.router

Envoy сам добавляет X-Client-IP из встроенной подстановки. А если захочешь хранить ещё что-то — используй Dynamic Metadata, и у тебя будет «карманная база данных внутри прокси». Плюсы: гибкость и фильтры как LEGO. Минусы: сложность конфига, настраивать без кофе опасно.

Вывод:

• HAProxy — переменные на любой вкус и срок жизни, но Lua придётся учить.

• NGINX — переменные как одноразовые стаканчики: удобно, но без повторного использования.

• Envoy — это как владение магией: невероятная мощь, но один неверный символ в метаданных или переменной и ты уже не повелеваешь трафиком, а тушишь фаервол.

Таймауты

HAProxy таймаутов столько, что можно потеряться. Таймауты обычно указывают в секциях defaults/frontend/backend. Главные параметры: timeout connect (тайм-аут на установку TCP), timeout client (неактивность со стороны клиента), timeout server (неактивность со стороны бэкенда), timeout http-request (время ожидания заголовков запроса), timeout http-keep-alive и timeout tunnel для туннелей/вебсокетов. Таймауты часто задаются явно в defaults; без корректных значений соединения могут «залипать» или падать. Каждый отвечает за свой этап: соединение, запрос, очередь, туннель. Можно гибко настроить поведение и на L4, и на L7.

defaults
  timeout connect 5s
  timeout client 1m
  timeout server 1m
  timeout http-request 10s
  timeout queue 15s
  timeout http-keep-alive 15s
  timeout tunnel 1h

Соединение к backend ждём 5 секунд, клиентский запрос и ответ сервера — по 1 минуте, запросы на уровне HTTP проверяем 10 секунд, очередь не держим дольше 15 секунд. Плюсы: полный контроль, можно «настроить до болтика». Минусы: легко запутаться, если лепить всё подряд, конфиг превращается в «таймаутное болото».

NGINX даёт набор директив для клиента и прокси. Ключевые: client_header_timeout, client_body_timeout — время чтения заголовков/тела от клиента; keepalive_timeout — время удержания keep-alive; proxy_connect_timeout, proxy_read_timeout, proxy_send_timeout — поведение при proxy_pass: подключение, чтение ответа и отправка запроса учитываются между последовательными операциями, а не за весь ответ. То есть proxy_read_timeout измеряет паузу между чтениями, а не общий срок передачи.

http {
  client_header_timeout 60s;
  client_body_timeout   60s;
  keepalive_timeout     75s;
  proxy_connect_timeout 10s;
  proxy_read_timeout    300s;  # увеличить для долгих ответов/streaming
  proxy_send_timeout    300s;
}

Для потоковых gRPC/HTTP2 соединений нужно поднять proxy_*_timeout и следить за http2_recv_timeout/настройками upstream. Минусы: меньше гранулярности, чем у HAProxy, например, нет отдельного таймаута очереди или туннеля — всё «оптом».

Envoy оперирует таймаутами на уровне connection manager, route и cluster. Важные пункты: route timeout по умолчанию 15s (это время ожидания полного upstream-ответа; стартует после получения всего downstream-запроса), stream_idle_timeout у HTTP connection manager по умолчанию 5 минут (закрывает бездействующие стримы), cluster.connect_timeout/transport_socket_connect_timeout по умолчанию ~5s. Таймауты можно задавать глобально и на уровне маршрута; per-route timeout: 0s отключает таймаут маршрута. Для стриминговых API нужно отключать/увеличивать route/stream таймауты.

http_connection_manager:
  stream_idle_timeout: 300s   # обычно 5m по умолчанию
route_config:
  virtual_hosts:
  - name: default
    domains: ["*"]
    routes:
    - match: { prefix: "/" }
      route:
        cluster: service_a
        timeout: 0s         # отключить route timeout для стриминга
        idle_timeout: 0s    # отключить per-route idle

В Envoy поведение таймаутов сложнее из-за retry/retry-timeout и взаимодействия connection-manager ↔ route ↔ cluster. Тестируйте сценарии с retry и streaming. Плюсы: гибкость, можно делать очень тонкие сценарии. Минусы: конфиг превращается в «головоломку на скорость», без документации самому себе — через неделю не разберёшься.

HAProxy — с таймаутами как со швейцарскими часами. Всё задаётся явно: connect, client, server, http-request, keep-alive, tunnel. Хочешь стриминг — поставь timeout tunnel и забудь. Минимум магии, максимум контроля. Если соединение зависло — это твоя вина, а не сюрприз в дефолтах.

NGINX — таймауты как бытовая техника. Client, proxy, keepalive — всё просто и понятно, но надо помнить, что proxy_read_timeout меряет паузы между байтами, а не всю загрузку. Для долгих gRPC или стриминга таймауты придётся крутить руками. Работает надёжно, если не забыть про все ручки.

Envoy — таймауты как корпоративные дедлайны. По умолчанию route timeout 15 секунд, stream_idle_timeout 5 минут — и Envoy безжалостно разрывает стриминг, если не объяснить, что проект ещё не готов. Гибкости море: можно отключить таймауты, настроить idle отдельно на route и cluster, но придётся думать, что именно отключать.

Вывод:

• HAProxy — максимальная детализация: можно настроить всё, даже «таймаут на таймаут». Но легко перестараться.

• NGINX — базовый набор: быстро, понятно, но без редких «спецрежимов».

• Envoy — конструктор с любыми таймаутами на любой уровень, но нужно помнить, что гибкость требует мозгов и кофе.

Kubernetes-интеграция

HAProxy. Есть два OSS-варианта:

• haproxytech/kubernetes-ingress — классический Ingress с аннотациями, поддержка Gateway API флагом. Метрики для Prometheus из коробки. Плавная миграция на новые API.

• jcmoraisjr/haproxy-ingress — тоже Ingress v1, частичная поддержка Gateway API (HTTPRoute/Gateway в v0.14). Подойдёт, если ближе его модель конфигурации.

Минимум магии, максимум контроля. Если что-то не работает — виноваты не «умные дефолты», а конкретные настройки.

NGINX Ingress Controller — фокус на Ingress v1. TLS/mTLS через аннотации (auth-tls-*), внешняя авторизация (auth-url), глобальные параметры через ConfigMap. Всё просто, но за сложные сценарии придётся платить количеством аннотаций. Работает стабильно, но «особые режимы» придётся включать руками.

Envoy Gateway (OSS) — нативный Gateway API, расширения SecurityPolicy для mTLS/JWT и авторизации по клеймам, метрики Prometheus.

Contour — управляет Envoy, поддерживает Gateway API и свои CRD для HTTP/gRPC/TCP. Гибкости море: route, cluster, policy — всё настраивается. Но за каждую опцию придётся думать.

Istio — mesh как отдельный отдел. Envoy выполняет роль data plane, политика и телеметрия централизуются через контроль-плейн. Если mesh уже есть или планируется — Ingress лучше строить на Istio или Gateway API с Envoy Gateway, чтобы не плодить зоопарк контроллеров.

Кратко:

• Хотите «всё под контролем» и минимум сюрпризов — HAProxy.

• Хотите «просто работает» — NGINX.

• Хотите «тонкая политика и современные API» — Envoy Gateway или Contour.

• Хотите «единая политика на весь трафик» — Istio.

Вывод

• HAProxy — максимальная детализация, можно настроить всё. Но легко утонуть в параметрах.

• NGINX — базовый и понятный путь. Быстро стартовать, без редких «сюрпризов».

• Envoy/Contour — гибкость и глубокая интеграция с Gateway API. Требует продуманной конфигурации.

• Istio — если mesh уже в планах, Ingress лучше сразу строить на нём.

Выводы и рекомендации

Когда брать:

• Edge TLS-терминация с высокими SLA по latency.

• Большие объёмы TCP/HTTP трафика, где нужна малая задержка.

• Нужен контроль на уровне соединений и простая схема автозамены бэкендов (seamless reload).

Операционные ограничения и подводные камни:

• Сложные L7-политики требуют Lua или внешней логики.

• HTTP/3 требует тестов и знаний о QUIC.

• Нет встроенной «из коробки» распределённой трассировки — нужно подключать OTEL/агрегаторы.

Когда брать:

• Статический контент, reverse-proxy с кешем, rate-limiting на уровне edge.

• Быстрый rollout и простая конфигурация без control-plane.

• Нужен модульный моддинг (lua, njs) для лёгкого расширения.

Операционные ограничения и подводные камни:

• Активные health-checks, advanced LB и enterprise-функции в основном в Plus.

• Метрики и трассировка требуют внешних экспортеров/модулей.

Когда брать:

• Service mesh или централизованное управление L7-политиками.

• gRPC-first архитектуры и обширная трассировка/OTel.

• Нужно гибкое управление канареями, retry/circuit-breaker, rate-limit через внешние сервисы.

Операционные ограничения и подводные камни:

• Высокая сложность конфигурации и поддержания YAML-политик.

• Больше CPU/RAM на экземплах по сравнению с NGINX/HAProxy.

• Требует CI/CD для xDS/контроль-плейна и хорошей наблюдаемости.

Итого по синтетическому разбору:

• Низкая латентность и грубая производительность L4/L7 → HAProxy

• Простой веб-фронт, кеш, статический контент, минимум динамики → NGINX

• Динамичная среда, gRPC, mesh, канареи/трафик-менеджмент → Envoy

Практические советы по внедрению

• Test-first: для HTTP/3 и QUIC задействуйте этап нагрузочного теста и SLO-валидацию

• Observability: если выбираете Envoy — проектируйте OTEL-пайплайн сразу. Для HAProxy/NGINX готовьте Prometheus → OTEL/Jaeger интеграцию

• K8s: для простого ingress — ingress-nginx или haproxy-ingress; для политики и mesh — Envoy Gateway/Contour/Istio. Планируйте единый control-plane, чтобы не плодить контроллеров.

• Ресурсы: закладывайте больше CPU/RAM под Envoy и автоматизацию для его конфигураций.

NGINX — как велосипед с корзинкой: завёл и забыл, но далеко не уедешь. HAProxy — как надёжный жигуль: предсказуемо, стабильно, но без наворотов. Envoy — как BMW: летит быстро и уверенно, но вечно приходится ковыряться под капотом. Всё едет, вопрос только — куда и с какой скоростью.

Кто победил?

По сумме плюсов — Envoy, остаётся лучшим выбором для динамических, telemetry-heavy и gRPC-проектов. HAProxy держит первенство по сырой производительности и простоте L4/L7 в высоких нагрузках. NGINX остаётся лучшим выбором для традиционных web/edge сценариев с простым управлением и кешированием.

P.S. Если я в процессе написания статьи где-то что-то упустил, ошибся в конфиге или описании — присылайте исправления в личку, чтобы я мог внести их в статью.