GH GambleHub

Proxy inversi e instradamento

1) Ruolo proxy reverse

Reverse proxy - Linea frontale della piattaforma: accetta TLS, distribuisce il traffico tra gli upstream, applica criteri di sicurezza e prestazioni. Obiettivo: minimo latitanza, routing prevedibile e isolamento rapido delle istanze/zone degradate.

2) Livelli e protocolli

L4: TCP/UDP proxy (SNI-based TLS passthrough, QUIC). Prezzo basso, senza la comprensione di HTTP.
L7: HTTP/1. 1–2–3, gRPC, WebSocket. Routing ricco (host, path, headers, cookies), trasformazioni e cache.

Modello TLS - Terminare nel perimetro (NGINX/Avvoy) e mTLS/mesh all'interno. SNI consente host virtuali su un unico IP.

3) Strategie di instradamento (L7)

1. Host-based: per dominio ('api. brand. com "→ cluster" brand-api ").
2. Path-based: `/v1/payments` → `payments-svc`, `/v1/wallets` → `wallets-svc`.
3. Header-based: `X-Region: eu-central`, `X-Tenant: 42`, `User-Agent`/`Accept`.
4. Cookie-based: test A/B, sessioni «appiccicose».
5. Weighted/Canary: percentuale di traffico per la nuova versione (1-5% → 100%).
6. GEO/ASN: Per paese/ASN viene inviato al RR/regione più vicina.
7. Consistent hasing - Aggancia la chiave (user _ id/tenant _ id) all'istanza del localitetto cache/appiccicoso.
8. Shadow/Mirroring - Copiare il traffico su un upstream shadow senza influire sulla risposta (per i test di regress).

4) Bilanciamento e tolleranza

Algoritmi: round-robin, least-sollest, random, ring-hash (consistent).
Health-checks: attivi (HTTP/TCP) + passivi (codici/timeout).
Outler ejection: «estrarre» temporaneamente un host con maggiore errore/latenza.
Retries: limitato, con per-try timeout e jitter; non ritrarre metodi non sicuri senza idepotenza.
Connection pooling - Mantenere i pool warm agli upstream, limitare i massimi.

5) Prestazioni del perimetro

Cache: per chiave (method + host + path + Vary), condizioni «ETag/If-None-Match», TTL e stale-while-revalidate.
Compressione: brotli/gzip per le risposte testuali.
HTTP/2/3: multiplexing, header-composition; assicurarsi che WAF/IDS sia compatibile.
Richiest coalescing - Contrarre richieste parallele per la stessa chiave cache.

6) Protezione proxy

TLS: 1. 2 + (meglio 1. 3), OCSP stapling, HSTS.
Filtri WAF/bot - Prima di essere instradati.
KORS/CSP/Fetch-Metadata: secondo le regole.
Header-гигиена: `X-Forwarded-For/Proto`, `Forwarded`, `traceparent`; protezione da header-ingection e oversize.
Body/headers limits: primi 413/431 per pattern DoS.
mTLS per partnership e API interne.

7) Schemi di deposito: canary/blue-green/versione

Weighted routing на level-7 (1%, 5%, 25%, 50%, 100%).
Header-gate - Abilita il file per flag/intestazione (internal/testing).
Blue-green: failover DNS/route, rollback veloce.
Shadow: prova parallela di una nuova versione con un record di metriche/logi.

8) Sessioni sticky e instradamento hash

Cookie-stickiness (`Set-Cookie: SRV=shard-a; Path=/; HttpOnly ') per i carichi di lavoro stateful.
Ring-hash/consistent in'user _ id/tenant _ id '- riduce le disabilità della cache.
Avvertenza: evitare la fissione «eterna» per carichi di lavoro write hot-spot; Utilizzare il per-tenante della quota.

9) Regionale e geo-routing

Anycast + geo-DNS per selezionare il POP più vicino.
Header-override (ad esempio X-Region) per test e debug.
Concordare con la localizzazione dei dati richiesta per legge (route per regione/giurisdizione).

10) Osservabilità e controllo

Metriche RED: RPS, errante-rate (per classe), latency p95/p99 per-route/cluster.
Outler/health: numero di edget/riattivazioni, slow-call-rate.
Loghi: strutturati, senza PII; core'trace _ id '/' span _ id '.
Tracing (OTEL) - span ingress→router→upstream; explars nei grafici p99.

11) Esempi di configurazione

11. 1 NGINX: host/path/weighted + кэш

nginx map $http_x_canary $canary { default 0; "1" 1; }
upstream app_v1 { least_conn; server 10. 0. 0. 1:8080 max_fails=3 fail_timeout=10s; }
upstream app_v2 { least_conn; server 10. 0. 0. 2:8080; }

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

Кэш proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=apicache:256m max_size=10g inactive=10m use_temp_path=off;

location /v1/ {
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Request-ID $request_id;
proxy_read_timeout 300ms; proxy_connect_timeout 100ms;

Weighted: 5% on v2 if canary = 1, otherwise 0%
set $backend app_v1;
if ($canary) { set $backend app_v2; }
proxy_pass http://$backend;
}

Static with cache location/assets/{
proxy_cache apicache;
proxy_cache_valid 200 10m;
add_header Cache-Control "public, max-age=600";
proxy_pass http://static_cluster;
}
}

11. 2 Envoy: header-routing, canary, outlier-ejection, mirroring

yaml static_resources:
clusters:
- name: svc_v1 type: STRICT_DNS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
- name: svc_v2 type: STRICT_DNS lb_policy: LEAST_REQUEST
- name: mirror_svc type: STRICT_DNS

listeners:
- name: https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match:
prefix: "/v1"
headers:
- name: "X-Region"
exact_match: "eu"
route:
cluster: svc_v1 timeout: 350ms retry_policy:
retry_on: connect-failure,reset,5xx num_retries: 1 per_try_timeout: 200ms request_mirror_policies:
- cluster: mirror_svc runtime_key: mirror. enabled
- match: { prefix: "/v1" }
route:
weighted_clusters:
clusters:
- name: svc_v1 weight: 95
- name: svc_v2 weight: 5

11. 3 Traefik: rules + middleware

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc middlewares: [hsts, compress]
middlewares:
hsts:
headers:
stsSeconds: 31536000 stsIncludeSubdomains: true compress:
compress: {}
services:
svc:
weighted:
services:
- name: v1 weight: 95
- name: v2 weight: 5

11. 4 Kubernets: Ingress + manifesto per canary (NGINX Ingress)

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api annotations:
nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "5"
spec:
rules:
- host: api. example. com http:
paths:
- path: /v1 pathType: Prefix backend:
service:
name: svc-v1 port: { number: 8080 }

12) Trasformazioni e compatibilità

Regolazione intestazione/percorso, censimento, controllo Cache-Control.
HTTP/JSON tramite trasmettitori (grpc-json-trascoder).
WebSocket/HTTP2 upgrades - Assicurarsi che il proxy salti Upgrade/Connection.

13) Test e script di caos

Carichi di lavoro: burst, platea lunga, corpi «lunghi» (slow-POST).
Iniezione di ritardi/perdite agli upstream è un controllo retries/timeout/outlier.
Metriche Canary: p95/p99, errato-rate nuova versione vs vecchia; rollback automatico SLO.
Shadow: confronto tra le risposte (sempilamento) e la logica side-by-side.

14) Antipattern

I retrai globali, senza considerare l'idampotenza e la deadline, le prese e la tempesta.
Sessioni sticky senza controllo hot-shard per distorsione di carico.
L'assenza di health-checks/outlier-ejection si traduce in istanze «marce» nel pool.
Titoli/corpi illimitati, il più semplice dei .
La combinazione di trasformazioni e sicurezza senza la versione dei circuiti può essere una regressione inaspettata.
Un'unica chiave globale di cache senza «Vary» non è valida.

15) Specificità iGaming/finanza

Regionalità: routing sulla giurisdizione del giocatore/marchio; isolamento delle aree di pagamento.
Itinerari critici (depositi/conclusioni): brevi timeout, una ripetizione, idampotenza; singoli cluster.
PSP/KYC: pool upstream dedicati, rigidi criteri retry/timeout, circuito-breaker, geo-pin.
Canali AB: esperimenti sicuri con pagamenti/limiti solo per il read-road; write - attraverso bandiere e piccole percentuali.

16) Assegno-foglio prod-pronto

  • TLS 1. 2+/1. 3, OCSP stapling, HSTS; corretti «X-Forwarded».
  • Regole di instradamento chiare: host/path/header/cookie; documentazione.
  • Health-checks, outlier-ejection, per-try timeout, retrai limitati.
  • Weighted/canary + shadow; auto-rollback SLO/alert.
  • Cache/compressione/ETag; limiti body/headers; request coalescing.
  • Logi/roulotte con'trace _ id '; metriche RED + outlier/health dashboard per-route/cluster.
  • filtri WAF/bot/CORS; protezione da oversize e slow-POST.
  • Sticky/consistent hasing dove si desidera; Controllo hot-shard.
  • Confighi sono versionati, le migrazioni sono sicure, i segreti in KMS/Vault.

17) TL; DR

Timbrare TLS sul perimetro e instradare L7 su host/path/header/cookie. Per le release - weighted canary e shadow; per la stabilità - health-checks, outlier-ejection, retries limitati con per-try timeout. Utilizzare la cache, la compressione e il consistent hasing dove questo migliora il p95. Misurare i segnali RED e lo stato dei cluster, mantenere WAF e limiti di dimensione. Per i percorsi di pagamento critici, i cluster separati, le SLA brevi e la gestione rigorosa dei retrai e dell'idipotenza.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.