GH GambleHub

Camadas proxy e rotação reversa

Resumo curto

A camada proxy é um «pneu de frente» da plataforma: completa o TLS, certifica os clientes, distribui tráfego, suaviza picos e torna o lançamento seguro (azul-green). O conjunto mínimo de maturidade é a stratação clara dos papéis proxy, regras de rotação definidas, controle de temporizações/retrações, kesh + rate-limit, observabilidade e automação.

Taxonomia proxy

Forward proxy - saída de clientes/serviços para fora (egress), filtros/espelhamento, DLP.
Reverse proxy - Aceita solicitações externas e roda para backends (nosso foco principal).

Camadas no circuito de prod:

1. Edge/CDN/WAF (Anycast, bot filtrs, kesh)

2. L7 Ingress/API-gateway (Rotação, Autenticação, Políticas)

3. Camada de serviço/Mesh (sidecar) para east-west, mTLS e retrações

4. Egress-gateway para integrações de saída (PSP, parceiros)

Rotação (L4/L7) e algoritmos

L4 (TCP/UDP, passthrough TLS): atraso mínimo, sem a noção HTTP.
L7 (HTTP/1. 1, HTTP/2, HTTP/3/gRPC): regras sobre host/path/header/cookie, transformação, WAF, kesh.

Algoritmos:
  • Round-robin/Least-conntions/EWMA - casos comuns.
  • Consent-hash (por cookie/ID) - sticky sessões e local em dinheiro.
  • Header-/Geo-/Latency-based - meta por região/provedor, PoP rápidos.
  • Canary/Weighted - rolout gradual (5→25→50→100%).
  • Shadow/Mirroring é uma cópia do tráfego para o novo serviço sem impacto nas respostas.

Transformar pedidos/respostas

URL rewrite/redirect: unificação dos caminhos, versionização ('/v1/ →/svc/v1/').
Em cabeçalho: Normalize 'X-Forwarded-For/Proto/Host', adicione 'traceparent '/' x-request-id' e filtre-o.
CORS/CSRF: Centralize em gateway, não produza configurações em cada serviço.
Composto/Decompressão: Brotli/gzip, controle de tipos.
Body-limits e proteção contra slowloris/oversized headers.

Autenticação e segurança

TLS 1. 3 + OCSP stapling + HSTS nas frentes externas.
mTLS: Admins, API operacional, canais de parceria.
OAUTh2/OIDC: permissão por gateway (tocen introspation/JWT-verify) → espaço para claims em upstream.
Chaves/assinaturas API (HMAC) para integrações entre servidores e parcerias.
Filtros WAF/bot: assinaturas + regras comportamentais, greypass/kupcha.
CSP/X-Frame-Opções/Referrer-Policy - Títulos seguros na borda.

Confiabilidade: retais/temporizadores/ST

Temporizações: connect/read/write em L4/L7, uma única política (por exemplo, «connect 500ms», «read 3-5s» para API).
Retrai: somente Idempotentes ('GET/HEAD'), limite de tempo/quantidade, 'retry-boodget'.
Circuito-breaker: restrições a solicitações simultâneas/erros, falha rápida e degradação.
Outlier detation: exclui as cópias «ruins» do pool.
Backoff + jitter: para não criar «efeito rebanho».

Kesh e controle de tráfego

Kesh L7: estática/seminâmica (diretórios, configs), 's-maxage' + 'stale-while-revalidate'.
Rate-limit/Quota: por IP/ASN/device/cookie, contador distribuído (Redis/Rate-service).
Sessões Sticky: cookies/consent-hash; Leve em consideração o failover e o «regravador».
Request collapsing (dedupe): proteja origin contra «tempestade» idêntica ao GET.

Protocolos e características

HTTP/2: multiplexação, prioridades; mantenha 'ALPN: h2'.
HTTP/3/QUIC: resistência à perda/jitter; abra o UDP/443, siga o MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; proxy deve suportar 'grpc-status'.
WebSocket/SSE: long-lived conectors, idle-timouts e limites.

Observabilidade e SLO

Métricas:
  • L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
  • TLS: versão/cifra, p95 handshake, resumpção.
  • Rotação: participações de rota/cluster, outlier-ejtions.
  • Rate-limit/WAF: activação/FP-rate.
  • Logi: acesso (sem PII), razões do roteiro, cabeçalhos de rastreamento.
  • Trailers: 'traceparent '/B3, samplicação.
SLO (exemplos):
  • p95 TTFB API ≤ 250-300 ms; erro L7 ≤ 0. 5%.
  • O sucesso dos canarinhos (sem a degradação das métricas) ≥ 99% dos lançamentos.
  • FP-rate WAF ≤ 0. 1%.

Configs típicos

Nginx (reverse proxy, HTTP/2, canário, compactação)

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 para 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 (rotas rule-based, conceito)

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"

Desempenho do proxy

Connation pooling e keepalive para backends, limite de conexões por instância.
Reuseport, pin CPU/IRQ, tampões de socket suficientes.
TLS: ECDSA + cadeias curtas, resumpção ≥ 70%, HTTP/2/3 incluído.
A caixa em proxy para respostas «quentes» (incluindo 304-validação).
Warm-up: Aquecimento DNS/TLS/conectórios antes dos picos.

DR. e resistência a falhas

Suporte automático de nós degradados ('outlier-ejation').
Health-checks L4/L7 (HTTP body).
Fail-open/Fail-closed - Escolha conscientemente para os caminhos de pagamento/crítica.
Modo Shadow antes de mudar o tráfego para o novo serviço.
Runbooks: «Colapso do cluster», «loop de rediretos», «fuga de conectórios», «tempestade de retrações».

Folha de cheque de implementação

  • Rateio: Edge → Ingress/API-GW → Mesh/Egress, papéis e limites de responsabilidade.
  • Políticas de rotação: host/path/header/weight, canary/blue-green, shadow.
  • Segurança: TLS 1. 3, mTLS para vias sensíveis, JWT/OAuth2, WAF.
  • Timouts/retais/ST: valores unificados, idempotidade, retry-budget.
  • Kesh/Rate-limit/Request-collapsing onde for apropriado.
  • Observabilidade: métricas/logs/trailers, identificadores de correlação.
  • SLO: p95/erros/recursos; alertas para falhas perimetrais.
  • IaC/GitOps: configs proxy no repositório, lançamentos de canário, rollback rápido.
  • Testes: rotas e2e, chaos-cenários, carga de trabalho antes dos iventes.

Erros típicos

O proxy mágico sem separação de papéis → um RCA complexo e um raio blast alto.
Retraias para solicitações não ideferentes → duplicados de transações.
Não há normalização de cabeçalhos/URL, cache-poisoning e chaves inválidas.
Sessões de sticky sem planos de failover → derrapagem em instância degradada.
Falta de 'traceparent '/' x-request-id' → não é possível coibir problemas.
Rígidos 301/302 no nível proxy → «loops» e perda de controle da API.

Especificidades para iGaming/Fintech

Pagamentos/PSP: egress-gateway dedicado com mTLS, temporizações rigorosas, chaves idumpotentes, listas de IP/ASN brancas.
Picos (jogos/torneios): canary/weighted, rotas cinzentas para bots, agressivo kesh GET, proteção contra «tempestade».
Regulação/loging: identifique as versões das políticas e as razões da rota nos logs de auditoria; minimize o PII.
Provedores de conteúdo: consent-hash por chave de provedor para localização e distribuição em dinheiro.

Mini-playbooks

1) Lançamento de canário API

1. Incluir 5% de peso em 'api-canary'; 2) Monitoramento de p95/erros; 3) ampliar a participação; 4) regresso automático à degradação.

2) Remoção emergencial de nódulo degradado

1. Outler-ejation ou manual 'drain'; 2) verificar o pulo e o êxito de cajá; 3) RCA pós-incidente.

3) Espelhar função

1. Ativar shadow sem afetar respostas; 2) comparar métricas/diff de respostas; 3) decidir sobre a mudança.

4) Tempestade de retrações

1. Reduzir retry-boodget/limite de tempo; 2) incluir request-collapsing; 3) braços/dinheiro locais; 4) estabilizar origin.

Resultado

Camada proxy bem projetada - separação de papéis, rotação definida, políticas confiáveis (timeouts/retais/ST), segurança (mTLS/JWT/WAF) e observabilidade. Configure as configurações em IaC, use canários e shadow, mede o SLO - e sua plataforma será escalável, previsível e protegida mesmo nos horários de pico mais quente.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.