Proxy-шари та reverse-маршрутизація

Коротке резюме

Проксі-шар - «фронтова шина» платформи: він завершує TLS, засвідчує клієнтів, розподіляє трафік, згладжує піки і робить випуск безпечним (канарки, blue-green). Мінімальний набір зрілості: чітка стратифікація проксі-ролей, детерміновані правила маршрутизації, контроль таймаутів/ретраїв, кеш + rate-limit, наскрізна спостережуваність і автоматизація.

Таксономія проксі

Forward proxy - вихідний трафік клієнтів/сервісів назовні (egress), фільтри/дзеркалювання, DLP.
Reverse proxy - приймає зовнішні запити і маршрутизує до бекендів (наш основний фокус).

Шари в прод-контурі:

1. Edge/CDN/WAF (Anycast, бот-фільтри, кеш)

2. L7 Ingress/API-gateway (маршрутизація, автентифікація, політики)

3. Сервісний шар/Mesh (sidecar) для east-west, mTLS і ретраїв

4. Egress-gateway для вихідних інтеграцій (PSP, партнери)

Маршрутизація (L4/L7) та алгоритми

L4 (TCP/UDP, passthrough TLS): мінімальна затримка, без розуміння HTTP.
L7 (HTTP/1. 1, HTTP/2, HTTP/3/gRPC): правила по host/path/header/cookie, трансформація, WAF, кеш.

Алгоритми:

Round-robin/Least-connections/EWMA - загальні випадки.
Consistent-hash (за cookie/ідентифікатором) - sticky-сесії і кеш-локальність.
Header-/Geo-/Latency-based - таргетинг по регіонах/провайдерам, швидкі PoP.
Canary/Weighted - поетапний rollout (5→25→50→100%).
Shadow/Mirroring - копія трафіку на новий сервіс без впливу на відповіді.

Трансформація запитів/відповідей

URL rewrite/redirect: уніфікація шляхів, версіонування ('/v1/ →/svc/v1/').
Заголовки: нормалізуйте'X-Forwarded-For/Proto/Host', додавайте'traceparent '/' x-request-id', фільтруйте зайве.
CORS/CSRF: централізуйте в gateway, не плодіть налаштування в кожному сервісі.
Compression/Decompression: Brotli/gzip, контроль за типами.
Body-limits і захист від slowloris/oversized headers.

Автентифікація та безпека

TLS 1. 3 + OCSP stapling + HSTS на зовнішніх фронтах.
mTLS: адмінки, операційні API, партнерські канали.
OAuth2/OIDC: авторизація через gateway (token introspection/JWT-verify) → прокидання до claims в upstream.
API-ключі/підписи (HMAC) для міжсервісних і партнерських інтеграцій.
WAF/бот-фільтри: сигнатури + поведінкові правила, greypass/капча.
CSP/X-Frame-Options/Referrer-Policy - security-заголовки на краю.

Надійність: ретраї/таймаути/СВ

Таймаути: connect/read/write на L4/L7, єдина політика (наприклад,'connect 500ms','read 3-5s'для API).
Ретраї: тільки ідемпотентні ('GET/HEAD'), ліміт за часом/кількістю,'retry-budget'.
Circuit-breaker: обмеження на одночасні запити/помилки, швидка відмова і деградація.
Outlier detection: виключення «поганих» екземплярів з пулу.
Backoff + jitter: щоб не створити «стадний ефект».

Кеш і управління трафіком

Кеш L7: статика/напівдинаміка (каталоги, конфіги),'s-maxage'+'stale-while-revalidate'.
Rate-limit/Quota: за IP/ASN/device/cookie, розподілений лічильник (Redis/Rate-service).
Sticky-сесії: cookie/consistent-hash; враховуйте failover і «переклейку».
Request collapsing (dedupe): захист origin від «шторму» ідентичних GET.

Протоколи та особливості

HTTP/2: мультиплексування, пріоритети; тримайте'ALPN: h2`.
HTTP/3/QUIC: стійкість до втрати/джиттеру; відкрийте UDP/443, слідкуйте за MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; проксі повинні підтримувати'grpc-status'.
WebSocket/SSE: long-lived коннекти, грамотні idle-таймаути і ліміти.

Спостережуваність і SLO

Метрики:

L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
TLS: версія/шифри, p95 handshake, resumption.
Маршрутизація: частки по route/cluster, outlier-ejections.
Rate-limit/WAF: спрацьовування/FP-rate.
Логи: доступ (без PII), причини маршрутизації, заголовки трасування.
Трейси: 'traceparent '/B3, семплювання.

SLO (приклади):

p95 TTFB API ≤ 250-300 мс; помилка L7 ≤ 0. 5%.
Успіх канарок (без деградації метрик) ≥ 99% запусків.
FP-rate WAF ≤ 0. 1%.

Типові конфіги

Nginx (reverse proxy, HTTP/2, канарка, стиснення)

nginx map $http_x_canary $upstream_pool {
default "stable";
~^1$ "canary";
}

upstream api_stable { zone zst 64k; server 10. 0. 1. 10:8443; server 10. 0. 1. 11:8443; keepalive 256; }
upstream api_canary { zone zcn 64k; server 10. 0. 2. 10:8443; keepalive 64; }

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

ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000" always;

basic limits/protection client_max_body_size 10m;
sendfile on; brotli on; gzip on;

location / {
proxy_http_version 1. 1;
proxy_set_header Host $host;
proxy_set_header X-Request-Id $request_id;
proxy_set_header X-Forwarded-Proto https;
proxy_connect_timeout 500ms;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 1; # Retrays are limited to proxy_pass https://api_$upstream_pool;
}
}

HAProxy (JWT-verify + mTLS до бекенду + rate-limit)

haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1. 1 http-request set-header X-Request-Id %[unique-id]
http-request lua. jwt_verify # external verification script JWT stick-table type ip size 1m expire 10m store http_req_rate (10s)
http-request deny if { src_http_req_rate(10s) gt 100 }

default_backend be_api

backend be_api balance roundrobin option httpchk GET /healthz server s1 10. 0. 1. 10:8443 check ssl verify required ca-file /etc/haproxy/ca. pem server s2 10. 0. 1. 11:8443 check ssl verify required ca-file /etc/haproxy/ca. pem

Envoy (JWT + weighted routes + outlier detection)

yaml static_resources:
listeners:
- name: https 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: ["api. example. com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- { name: api-stable, weight: 95 }
- { name: api-canary, weight: 5 }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config: { "@type": type. googleapis. com/envoy. extensions. filters. http. jwt_authn. v3. JwtAuthentication }
- name: envoy. filters. http. router clusters:
- name: api-stable connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN outlier_detection: { consecutive_5xx: 3, interval: 2s, base_ejection_time: 30s }
transport_socket:
name: envoy. transport_sockets. tls
- name: api-canary connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN transport_socket:
name: envoy. transport_sockets. tls

Traefik (rule-based маршрути, концепт)

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1/`)"
service: api-svc tls: { certResolver: letsencrypt }
services:
api-svc:
loadBalancer:
servers:
- url: "https://10. 0. 1. 10:8443"
- url: "https://10. 0. 1. 11:8443"

Продуктивність проксі

Connection pooling і keepalive до бекендів, ліміт конектів на інстанс.
Reuseport, pin CPU/IRQ, достатні буфери сокетів.
TLS: ECDSA + короткі ланцюжки, resumption ≥ 70%, HTTP/2/3 включені.
Кеш в проксі для «гарячих» відповідей (в т.ч. 304-валідації).
Warm-up: прогрів DNS/TLS/конектів перед піками.

DR і відмовостійкість

Автовивід деградних вузлів ('outlier-ejection').
Health-checks L4/L7 (HTTP body-маркер версії).
Fail-open/Fail-closed - вибирайте усвідомлено для платіжних/критичних шляхів.
Shadow-режим перед перемиканням трафіку на новий сервіс.
Runbooks: «обвал кластера», «петля редиректів», «витоки конектів», «шторм ретраїв».

Чек-лист впровадження

Стратифікація: Edge → Ingress/API-GW → Mesh/Egress, ролі та межі відповідальності.
Політики маршрутизації: host/path/header/weight, canary/blue-green, shadow.
Безпека: TLS 1. 3, mTLS для чутливих шляхів, JWT/OAuth2, WAF.
Таймаути/ретраї/СВ: єдині значення, ідемпотентність, retry-budget.
Кеш/Rate-limit/Request-collapsing там, де доречно.
Спостережуваність: метрики/логи/трейси, correlation-ідентифікатори.
SLO: р95/помилки/ресурси; алерти на периметрові збої.
IaC/GitOps: конфіги проксі в репозиторії, канарні релізи, швидкий rollback.
Тести: e2e-маршрути, chaos-сценарії, навантажувальне перед івентами.

Типові помилки

«Магічний» проксі-комбайн без поділу ролей → складний RCA і високий blast-радіус.
Ретраї для неідемпотентних запитів → дублікати транзакцій.
Немає нормалізації заголовків/URL → cache-poisoning і невірні ключі.
Sticky-сесії без планів failover → залипання на деградному інстансі.
Відсутність'traceparent '/' x-request-id'→ неможливо корелювати проблеми.
Жорсткі 301/302 на рівні проксі → «петлі» і втрата контролю версій API.

Специфіка для iGaming/фінтех

Платежі/PSP: виділений egress-gateway з mTLS, строгі таймаути, ідемпотентні ключі, білі списки IP/ASN.
Піки (матчі/турніри): canary/weighted, сірі маршрути для ботів, агресивний кеш GET, захист origin від «шторму».
Регуляторика/логування: фіксуйте версії політик і причини маршруту в аудит-логах; мінімізуйте PII.
Провайдери контенту: consistent-hash за провайдерським ключем для кеш-локальності та рівного розподілу.

Міні-плейбуки

1) Канарний реліз API

1. Включити 5% ваги на'api-canary'; 2) моніторинг р95/помилок; 3) розширювати частку; 4) автовідкат при деградації.

2) Екстрене зняття деградного вузла

1. Outlier-ejection або ручний'drain'; 2) перевірка пулу і хіта кеша; 3) пост-інцидентний RCA.

3) Дзеркалювання функції

1. Увімкнути shadow без впливу на відповіді; 2) порівняти метрики/дифф відповідей; 3) прийняти рішення про перемикання.

4) Шторм ретраїв

1. Знизити retry-budget/тимчасові ліміти; 2) включити request-collapsing; 3) локальні заглушки/кеш; 4) стабілізувати origin.

Підсумок

Добре спроектований проксі-шар - це поділ ролей, детермінована маршрутизація, надійні політики (таймаути/ретраї/СВ), безпека (mTLS/JWT/WAF) і спостережуваність. Закріпіть конфігурації в IaC, використовуйте канарки і shadow, вимірюйте SLO - і ваша платформа буде масштабованою, передбачуваною і захищеною навіть в найгарячіші пікові годинники.