Capas proxy y enrutamiento reverse

Resumen breve

La capa proxy es el «bus frontal» de la plataforma: completa TLS, certifica clientes, distribuye tráfico, suaviza picos y hace que la liberación sea segura (canarios, azul-verde). Conjunto mínimo de madurez: estratificación clara de roles proxy, reglas de enrutamiento deterministas, control de temporizadores/retraídos, caché + rate-limit, observación de extremo a extremo y automatización.

Taxonomía proxy

Forward proxy - tráfico saliente de clientes/servicios hacia fuera (egress), filtros/espejado, DLP.
Reverse proxy - Acepta consultas externas y enruta a los backends (nuestro enfoque principal).

Capas en el esquema prod:

1. Edge/CDN/WAF (Anycast, filtros bot, caché)

2. L7 Ingress/API-gateway (enrutamiento, autenticación, políticas)

3. Capa de servicio/Mesh (sidecar) para east-west, mTLS y retraídas

4. Egress-gateway para integraciones salientes (PSP, partners)

Enrutamiento (L4/L7) y algoritmos

L4 (TCP/UDP, passthrough TLS): latencia mínima, sin comprensión HTTP.
L7 (HTTP/1. 1, HTTP/2, HTTP/3/gRPC): reglas de host/path/header/cookie, transformación, WAF, caché.

Algoritmos:

Round-robin/Least-connections/EWMA - casos comunes.
Consistent-hash (por cookie/ID) - sesiones de sticky y caché-localidad.
Header-/Geo-/Latency-based - orientación por región/proveedor, PoP rápidos.
Canary/Weighted es un rollout por etapas (5→25→50→100%).
Shadow/Mirroring: copia del tráfico al nuevo servicio sin afectar a las respuestas.

Transformación de consultas/respuestas

URL rewrite/redamb: unificación de rutas, versionamiento ('/v1/ →/svc/v1/').
Títulos: normalizar 'X-Forwarded-For/Proto/Host', añadir 'traceparent '/' x-request-id', filtrar el extra.
CORS/CSRF: centralice en gateway, no produzca ajustes en cada servicio.
Compression/Decompression: Brotli/gzip, control por tipo.
Body-limits y protección anti-slowloris/oversized headers.

Autenticación y seguridad

TLS 1. 3 + OCSP stapling + HSTS en los frentes exteriores.
mTLS: administradores, API operativas, canales de afiliados.
OAuth2/OIDC: autorización vía gateway (token introspection/JWT-verify) → prueba a claims en upstream.
Claves/Firmas de API (HMAC) para integraciones de partners e interservicios.
Filtros WAF/bot: firmas + reglas de comportamiento, greypass/capcha.
CSP/X-Frame-Options/Referrer-Policy - encabezados de seguridad en el borde.

Confiabilidad: retraídas/temporizadores/SV

Timeout: connect/read/write en L4/L7, una sola política (por ejemplo, 'connect 500ms', 'read 3-5s' para API).
Retraídas: sólo idempotentes ('GET/HEAD'), límite de tiempo/cantidad, 'retry-budget'.
Circuit-breaker: restricciones a solicitudes/errores simultáneos, fallo rápido y degradación.
Detección de Outlier: excluye las instancias «malas» de la agrupación.
Backoff + jitter: para no crear un «efecto de manada».

Caché y control de tráfico

Kash L7: estática/semidinámica (directorios, configuraciones), 's-maxage' + 'stale-while-revalidate'.
Rate-limit/Quota: por IP/ASN/device/cookie, contador distribuido (Redis/Rate-service).
Sesiones Sticky: cookies/consistent-hash; considere failover y «madera contrachapada».
Request collapsing (dedupe): protección de origen contra la «tormenta» de idénticos GET.

Protocolos y características

HTTP/2: multiplexación, prioridades; mantenga 'ALPN: h2'.
HTTP/3/QUIC: Resistencia a la pérdida/jitter; abra el UDP/443, siga MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; los proxy deben admitir 'grpc-status'.
WebSocket/SSE: conectores long-lived, idle-timeouts alfabetizados y límites.

Observabilidad y SLO

Métricas:

L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
TLS: versión/cifrado, p95 handshake, resumen.
Enrutamiento: acciones por route/cluster, outlier-ejections.
Rate-limit/WAF: activación/FP-rate.
Registros: acceso (sin PII), razones de enrutamiento, encabezados de seguimiento.
Tracks: 'traceparent '/B3, sampling.

SLO (ejemplos):

p95 TTFB API ≤ 250-300 ms; error L7 ≤ 0. 5%.
El éxito de los canarios (sin la degradación de las métricas) ≥ el 99% de los lanzamientos.
FP-rate WAF ≤ 0. 1%.

Configuraciones típicas

Nginx (reverse proxy, HTTP/2, canario, compresión)

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 al backend + 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 (rutas rule-based, concepto)

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"

Rendimiento del proxy

Conexión pooling y keepalive a los backends, límite de los connects a las instancias.
Reuseport, pin CPU/IRQ, suficientes búferes de socket.
TLS: ECDSA + cadenas cortas, resumen ≥ 70%, HTTP/2/3 incluidas.
Caché en el proxy para respuestas «calientes» (incluida la validación 304).
Warm-up: calentamiento de DNS/TLS/connects antes de los picos.

DR y tolerancia a fallas

Autovía de nodos degradados ('outlier-ejection').
Health-checks L4/L7 (versión del marcador del cuerpo HTTP).
Fail-open/Fail-closed - elija conscientemente para las rutas de pago/críticas.
Modo de exposición antes de cambiar el tráfico a un nuevo servicio.
Runbooks: "colapso del racimo", "bucle de redirecciones", "fugas de connects'," tormenta de retraídas ".

Lista de comprobación de implementación

Estratificación: Edge → Ingress/API-GW → Mesh/Egress, roles y límites de responsabilidad.
Políticas de enrutamiento: host/path/header/weight, canary/blue-green, shadow.
Seguridad: TLS 1. 3, mTLS para rutas sensibles, JWT/OAuth2, WAF.
Taimaouts/retraes/SV: valores unificados, idempotencia, retry-budget.
Kash/Rate-limit/Request-collapsing donde corresponda.
Observabilidad: métricas/registros/tracks, identificadores de correlación.
SLO: p95/errores/recursos; alertas a fallas perimetrales.
IaC/GitOps: configuraciones proxy en el repositorio, lanzamientos canarios, rollback rápido.
Pruebas: rutas e2e, escenarios chaos, carga antes de los eventos.

Errores

El procesador de proxy «mágico» sin separación de roles → un RCA complejo y un radio blast alto.
Retrés para solicitudes no idempotentes → transacciones duplicadas.
No hay normalización de encabezados/URL → cache-poisoning y claves incorrectas.
Sesiones de sticky sin planes failover → relleno en una instancia degradada.
La falta de 'traceparent '/' x-request-id' → es imposible corear los problemas.
Rígido 301/302 a nivel proxy → «bucles» y pérdida de control de las versiones de la API.

Características específicas para iGaming/Fintech

Pagos/PSP: egress-gateway dedicado con mTLS, tiempos de espera estrictos, claves idempotentes, listas blancas IP/ASN.
Piques (partidos/torneos): canario/weighted, rutas grises para bots, caché agresivo GET, protección de origin contra la «tormenta».
Regulación/lógica: capture las versiones de las políticas y las razones de la ruta en los logs de auditoría; minimice el PII.
Proveedores de contenido: consistent-hash por clave de proveedor para la localización en caché y la distribución uniforme.

Minibuses

1) Lanzamiento canario de la API

1. Incluir 5% de peso en 'api-canary'; 2) monitoreo de p95/errores; 3) ampliar la proporción; 4) autocontrol en degradación.

2) Eliminación de emergencia del nodo degradado

1. Outlier-ejection o manual 'drain'; 2) comprobar la piscina y el éxito del kash; 3) RCA post-incidente.

3) Función de espejado

1. Habilitar shadow sin afectar a las respuestas; 2) comparar métricas/diff de respuestas; 3) Decidir cambiar.

4) Tormenta de retraídas

1. Reducir los límites de tiempo/retry-budget; 2) habilitar request-collapsing; 3) enchufes/caché locales; 4) estabilizar el origin.

Resultado

Una capa proxy bien diseñada es la separación de roles, enrutamiento determinista, políticas confiables (temporizadores/retraídos/SV), seguridad (mTLS/JWT/WAF) y observabilidad. Ancla configuraciones en IaC, usa canarios y sombras, mide SLO, y tu plataforma será escalable, predecible y segura incluso en las horas pico más calientes.