GH GambleHub

Proxy-Layer und Reverse-Routing

Kurze Zusammenfassung

Die Proxy-Schicht ist der „Frontbus“ der Plattform: Sie vervollständigt das TLS, bescheinigt Kunden, verteilt den Verkehr, glättet Spitzen und macht die Freigabe sicher (Kanarienvögel, blau-grün). Mindestreifegrad: klare Stratifizierung von Proxy-Rollen, deterministische Routing-Regeln, Timeout-/Retraysteuerung, Cache + Rate-Limit, End-to-End-Überwachung und Automatisierung.

Proxy-Taxonomie

Forward Proxy - ausgehender Verkehr von Kunden/Diensten nach außen (egress), Filter/Spiegelung, DLP.
Reverse Proxy - akzeptiert externe Anfragen und leitet zu Backends (unser Hauptaugenmerk).

Schichten im Prod-Loop:

1. Edge/CDN/WAF (Anycast, Bot-Filter, Cache)

2. L7 Ingress/API-Gateway (Routing, Authentifizierung, Richtlinien)

3. Service Layer/Mesh (Seitenwagen) für Ost-West, mTLS und Retrays

4. Egress-Gateway für ausgehende Integrationen (PSP, Partner)

Routing (L4/L7) und Algorithmen

L4 (TCP/UDP, passthrough TLS): minimale Latenz, ohne HTTP zu verstehen.
L7 (HTTP/1. 1, HTTP/2, HTTP/3/gRPC): Regeln für Host/Path/Header/Cookie, Transformation, WAF, Cache.

Algorithmen:
  • Round-robin/Least-connections/EWMA sind häufige Fälle.
  • Consistent-hash (per Cookie/ID) - Sticky-Sitzungen und Cache-Lokalität.
  • Header-/Geo-/Latency-based - Targeting nach Region/Anbieter, schnelle PoP.
  • Canary/Weighted ist ein stufenweiser Rollout (5→25→50→100%).
  • Shadow/Mirroring - eine Kopie des Verkehrs auf den neuen Dienst ohne Auswirkungen auf die Antworten.

Umwandlung von Anfragen/Antworten

URL rewrite/redirect: Pfad-Vereinheitlichung, Versionierung ('/v1/ →/svc/v1/').
Überschriften: Normalisieren Sie' X-Forwarded-For/Proto/Host', fügen Sie' traceparent '/' x-request-id 'hinzu, filtern Sie den Überschuss.
CORS/CSRF: zentralisieren Sie im Gateway, produzieren Sie nicht die Einstellungen in jedem Dienst.
Kompression/Decompression: Brotli/gzip, Steuerung nach Typ.
Body-Limits und Schutz vor Slowloris/Oversized-Köpfen.

Authentifizierung und Sicherheit

TLS 1. 3 + OCSP Stapeln + HSTS an den Außenfronten.
mTLS: Admins, operative APIs, Partnerkanäle.
OAuth2/OIDC: Autorisierung über Gateway (Token-Introspektion/JWT-verify) → Durchlauf zu Claims im Upstream.
API-Schlüssel/Signaturen (HMAC) für service- und partnerübergreifende Integrationen.
WAF/Bot-Filter: Signaturen + Verhaltensregeln, Greypass/Captcha.
CSP/X-Frame-Options/Referrer-Policy - Sicherheitsüberschriften am Rand.

Zuverlässigkeit: Retrays/Timeouts/SV

Timeouts: connect/read/write auf L4/L7, einheitliche Richtlinie (z.B. 'connect 500ms', 'read 3-5s' für APIs).
Retrays: nur idempotent („GET/HEAD“), Zeit-/Mengenlimit, „retry-budget“.
Circuit-Breaker: Einschränkungen bei gleichzeitigen Anfragen/Fehlern, schnellem Ausfall und Degradation.
Outlier-Erkennung: Schließt „schlechte“ Instanzen aus dem Pool aus.
Backoff + jitter: Um keinen „Herdeneffekt“ zu erzeugen.

Cache und Verkehrssteuerung

L7 Cache: Statik/Halbdynamik (Kataloge, Configs), 's-maxage' + 'stale-while-revalidate'.
Rate-Limit/Quota: per IP/ASN/Device/Cookie, verteilter Zähler (Redis/Rate-Service).
Sticky-Sitzungen: Cookie/consistent-hash; Berücksichtigen Sie Failover und „Sperrholz“.
Request collapsing (dedupe): Schutz der Herkunft vor dem „Sturm“ identischer GETs.

Protokolle und Funktionen

HTTP/2: Multiplexing, Prioritäten; halten Sie „ALPN: h2“.
HTTP/3/QUIC: Widerstand gegen Verlust/Jitter; Öffnen Sie UDP/443, folgen Sie MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; Proxies müssen „grpc-status“ unterstützen.
WebSocket/SSE: langlebige Anschlüsse, kompetente Idle-Timeouts und Limits.

Beobachtbarkeit und SLO

Metriken:
  • L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
  • TLS: Version/Chiffren, p95 handshake, resumption.
  • Routing: Anteile nach route/cluster, outlier-ejections.
  • Rate-Limit/WAF: Betätigungen/FP-Rate.
  • Protokolle: Zugriff (ohne PII), Routing-Gründe, Trace-Header.
  • Traces: 'traceparent '/B3, Sampling.
SLO (Beispiele):
  • p95 TTFB API ≤ 250-300 ms Fehler L7 ≤ 0 5%.
  • Der Erfolg der Kanarienvögel (ohne Abbau der Metriken) ≥ 99% der Starts.
  • FP-rate WAF ≤ 0. 1%.

Typische Configs

Nginx (Reverse Proxy, HTTP/2, Kanarienvogel, Kompression)

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 to 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 (regelbasierte Routen, Konzept)

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"

Proxy-Leistung

Konnektivitäts-Pooling und Keepalive zu Backends, Konnektivitätslimit pro Instance.
Reuseport, CPU/IRQ-Pin, ausreichende Socket-Puffer.
TLS: ECDSA + kurze Ketten, resumption ≥ 70%, HTTP/2/3 enthalten.
Cache im Proxy für „heiße“ Antworten (einschließlich 304-Validierung).
Warm-up: Aufwärmen von DNS/TLS/Konnekten vor Peaks.

DR und Fehlertoleranz

Automatische Ausgabe von degradierten Knoten ('outlier-ejection').
Health-checks L4/L7 (HTTP-Body-Token-Version).
Fail-open/Fail-closed - Wählen Sie bewusst für zahlungskritische Wege.
Shadow-Modus vor dem Umschalten des Datenverkehrs auf den neuen Dienst.
Runbooks: „Cluster-Zusammenbruch“, „Umleitungsschleife“, „Verbindungslecks“, „Sturm der Rückschritte“.

Checkliste für die Implementierung

  • Stratifizierung: Edge → Ingress/API-GW → Mesh/Egress, Rollen und Verantwortungsgrenzen.
  • Routing-Richtlinien: host/path/header/weight, canary/blue-green, shadow.
  • Sicherheit: TLS 1. 3, mTLS für empfindliche Wege, JWT/OAuth2, WAF.
  • Timeouts/Retrays/SV: Unified Values, Idempotence, Retry-Budget.
  • Cache/Rate-limit/Request-collapsing, wo angemessen.
  • Beobachtbarkeit: Metriken/Logs/Traces, Korrelations-IDs.
  • SLO: p95/Fehler/Ressourcen; Warnungen für Perimeterausfälle.
  • IaC/GitOps: Proxy-Configs im Repository, kanarische Releases, schnelles Rollback.
  • Tests: e2e-Routen, Chaos-Szenarien, Last vor Veranstaltungen.

Typische Fehler

Ein „magischer“ Proxy-Harvester ohne Rollenteilung → ein komplexer RCA und ein hoher Blast-Radius.
Retrays für nicht-identische Anfragen → doppelte Transaktionen.
Keine Normalisierung von Headern/URLs → Cache-Poisoning und falsche Schlüssel.
Sticky-Sessions ohne Failover-Pläne → Kleben an einer degradierten Instanz.
Das Fehlen von 'traceparent '/' x-request-id' ist → unmöglich, Probleme zu korrelieren.
Harte 301/302 auf Proxy-Ebene → „Schleifen“ und Verlust der API-Versionskontrolle.

Spezifität für iGaming/Fintech

Zahlungen/PSP: dediziertes Egress-Gateway mit mTLS, strikte Timeouts, idempotente Schlüssel, IP/ASN-Whitelists.
Peaks (Matches/Turniere): kanarisch/gewichtet, graue Routen für Bots, aggressiver GET-Cache, Ursprungsschutz vor „Sturm“.
Regulatory/Logging: Erfassen Sie die Versionen der Richtlinien und die Gründe für die Route in Audit-Logs; Minimierung der PII.
Inhaltsanbieter: consistent-hash nach Anbieterschlüssel für Cache-Lokalität und gleichmäßige Verteilung.

Mini-Playbooks

1) Kanarische API-Freigabe

1. 5% des Gewichts auf „api-canary“; 2) p95/Fehlerüberwachung; 3) den Anteil zu erweitern; 4) Auto-Otcat beim Abbau.

2) Notfallentfernung des degradierten Knotens

1. Outlier-ejection oder manuell 'drain'; 2) Überprüfung des Pools und des Cache-Hits; 3) Post-Incident RCA.

3) Spiegelung der Funktion

1. Shadow aktivieren, ohne die Antworten zu beeinflussen; 2) vergleichen Sie die Metriken/diff der Antworten; 3) Entscheiden Sie sich für den Wechsel.

4) Sturm der Retrays

1. Retry-Budget/Zeitlimits senken; 2) Request-Collapsing aktivieren; 3) lokale Stubs/Cache; 4) Stabilisierung der Herkunft.

Ergebnis

Eine gut konzipierte Proxy-Schicht besteht aus Rollenteilung, deterministischem Routing, robusten Richtlinien (Timeouts/Retrays/CBs), Sicherheit (mTLS/JWT/WAF) und Beobachtbarkeit. Verankern Sie Konfigurationen in IaC, verwenden Sie Kanarienvögel und Schatten, messen Sie SLO - und Ihre Plattform ist skalierbar, vorhersagbar und sicher, selbst während der heißesten Stoßzeiten.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.