Mehrregion-Halo-Ingress scheitert selten an fehlenden Zertifikaten, sondern an DNS-HTTPS-Records, ECH-Rotation und falsch gemischten p95-Histogrammen. Diese Checkliste bündelt SVCB-Sonden, kontrollierten Klartext-SNI-Fallback, GeoDNS-Stickiness und getrennte H2-Handshake-Ketten für Japan, Korea, Hongkong, Singapur und US-Westen—inklusive Schwellen und Review-FAQ.

Architekten, die Steuer-HTTPS und Artefakt-H2 parallel betreiben, brauchen eine signierte Matrix statt Bauchgefühl. Kontext aus der GeoDNS-SSH-Entscheidungsmatrix, ergänzt durch MSS, BBR und SSH-p95, Happy Eyeballs und QUIC sowie den operativen Loopback-SSH-Tunnel. Tariftransparenz: Preise. Struktur: Schmerzpunkte, zwei Parametertabellen, regionale p95-Ziele, Routing-Sticky-Regeln, sechs Rollout-Schritte, FAQ.

1) Ohne feste Resolver-Views misst ihr Resolver-Rauschen statt Edge-Regression. 2) Fehlt ein separater Bucket für Klartext-SNI, wirken ECH-Wechsel wie TLS-Regressionen. 3) Zu kurze TTL plus aggressiver Geo-Failover erzeugt Stürme, bevor der HTTP/2-SETTINGS-Pfad stabil bleibt.

Pfad DNS-Signal TLS-Profil p95-Fokus
Steuer-API HTTPS-RR bevorzugt, A/AAAA Fallback ECH aktiv, Klartext parallel messen Handshake plus erste SETTINGS
Artefakt-H2 Eigener SVCB-Stack oder dedizierte Namen ALPN h2 strikt, keine Vermischung Upload-Window, keine API-Latenz mischen
Admin-SSH Split-Horizon, keine öffentlichen SVCB mTLS oder Bastion-only Siehe SSH-Leitfaden, nicht HTTP-p95
Failover TTL-Obergrenze dokumentiert Zertifikatsrotation synchron zu ECH Gewichtung vor Zonenfile-Flip
Parameter Empfohlene Schwelle Begründung Review-Hinweis
SVCB-Priorität Monoton fallend, keine Duplikate Verhindert Client-Würfeln zwischen gleichwertigen Zielen SAN-Abgleich pro Zielpflicht
ECH-Overlap ≥ 72 h Doppelpublish Alte Clients überleben ConfigList-Wechsel Alarm wenn Overlap < 48 h
Klartext-SNI Eigene Messreihe, min. 1 k Sample/Region Isoliert Middlebox-Verhalten Nicht mit ECH-Bucket mergen
GeoDNS-TTL ≥ 300 s außerhalb Hotfix Reduziert Resolver-Stürme Hotfix nur mit Capacity-Gate
H2-Handshake p95 Siehe Regionstabelle Steuer vs. Artefakt strikt trennen Dashboard-Filter erzwingen

HTTP/2 inklusive TLS-Handshake: p95-Abnahme je Region

Erfasst für jede Messperiode getrennt ClientHello bis ServerHelloDone, dann SETTINGS-Ack. Artefakt-Pfade mit großen Fenstern dürfen nicht in dieselbe Zeitreihe wie API-Steuerkanäle; sonst verschwinden Singapur-Spitzen in US-West-Mittelwerten. Nutzt identische Cipher-Suites je Lane, damit Vergleiche fair bleiben.

Region Steuer-API p95 (ms) Artefakt-H2 p95 (ms) Eskalation
JP > 185 > 420 Carrier plus SVCB-Pfad prüfen
KR > 175 > 400 ECH-Rotation und OCSP
HK > 195 > 450 Geo-Sticky vs. Peering
SG > 165 > 380 Artefakt-Parallelität erhöhen
US-West > 155 > 360 Last auf sekundären Edge verlagern

Regionales Routing und GeoDNS-Stickiness

Definiert Sticky-Maps, welche ASN oder EDNS-Subnet einer Region zuordnen, dokumentiert Ausnahmen für Roaming-Clients und haltet Views versioniert. Jede Änderung an SVCB oder HTTPS-RR muss im gleichen Change-Ticket wie Ingress-Gewichte stehen, damit Observability dieselbe Release-ID sieht wie DNS.

Bei Split-Horizon niemals interne Namen in öffentliche SVCB-Records spiegeln; verweist stattdessen auf die Split-Horizon-Latenz-Analyse. Für reine SSH-Verwaltungspfad bleibt die Bastion-Topologie führend—diese Matrix adressiert nur HTTPS-Artefakte und Steuer-APIs.

Stabilität und Sicherheit: Dokumentiert, welche Teams Klartext-SNI triggern dürfen, rotiert ECHConfigList nur mit doppeltem Monitoring und haltet mTLS für interne Sonderpfade bereit. Ohne diese Disziplin liefern perfekte Zertifikate dennoch false positive p95-Sprünge.

Failover-FAQ für DNS, ECH und Ingress

ECH grün, p95 rot—erster Check? Vergleicht Klartext-SNI und ECH in getrennten Buckets, prüft OCSP-Stapling und ob H2-SETTINGS nach dem Handshake blockieren.

SVCB und A-Record widersprechen sich? Stoppt Canary, dokumentiert Client-Implementierung, priorisiert konsistente HTTPS-RR; keine parallele Änderung ohne Messfenster.

Wann DNS statt nur Traffic-Shift? Nur nach doppelt bestätigtem Edge-Ausfall und freigegebenem TTL-Plan; andernfalls verschärft ihr Resolver-Stürme.

Sechs Rollout-Schritte mit Dokumentationspflicht

  • Schritt 1: Resolver-Baseline je Region fixieren, ECS und Cache-Hierarchie in einem Architekturrepository versionieren.
  • Schritt 2: HTTPS/SVCB-Sonden automatisieren, SAN- und ALPN-Drift täglich vergleichen, Fallback-Pfade markieren.
  • Schritt 3: ECH-Rotation mit Überlappungsfenster fahren, Klartext-SNI parallel messen und Alarme entkoppeln.
  • Schritt 4: H2-Handshake-Histogramme nach Steuer- und Artefakt-Lane splitten, Dashboard-Filter policy-seitig erzwingen.
  • Schritt 5: GeoDNS-Sticky-Maps und TTL-Obergrenzen mit Netzteam abstimmen, Tischübung für Doppel-PoP-Ausfall planen.
  • Schritt 6: Runbook mit Links zu Preise, Hilfe und Konsole veröffentlichen, damit On-Call dieselben Knotenwahlregeln wie das Produktteam nutzt.

Drei zitierfähige Leitplanken

  • DNS-Regel: HTTPS-RR-Änderungen nur mit SVCB-SONDE-GRÜN und SAN-Match im gleichen Fenster.
  • ECH-Regel: Keine ConfigList ohne 72h-Overlap und parallelen Klartext-Pfad.
  • p95-Regel: Steuer-API und Artefakt-H2 niemals im selben Histogramm-Bucket.
Hinweis: Zahlen sind interne Richtwerte für Abnahmen, keine öffentliche Latenz-Garantie. Passt Schwellen an eure Carrier- und Hardwaregeneration der vpshalo-Mac-Builder an.

Remote-Mac-Knoten bleiben Referenz für reproduzierbare Builds; korreliert DNS-Änderungen mit Inventar-IDs, nicht nur mit Hostnamen, damit Hardwaretausch die Messketten nicht bricht.

Knotenwahl, Hilfe und Halo-Serie

Region wählen, Ingress messen, Support einbinden

Regionales Paket und Preise für kapazitätsgleiche Mac-Builder. Technische Begleitung: Hilfe-Center sowie Konsole für Zugriff und Status. Vertiefung: GeoDNS-Matrix, MSS/BBR, SSH-Tunnel.

Direktlinks: Tokio · Seoul · Hongkong · Singapur · USA Westen

Knotenregion auswählen Tarife ansehen Hilfe-Center Weitere Halo-Artikel