2026 · entrée globale type Halo
Worker Cloudflare, santé & SSH p95 US Ouest / HK–SG

La fraîcheur du cache des noms publics et l’atteignabilité de l’origine suivent des horloges différentes. Dans un Worker, corrélez les indices Request.cf avec les journaux d’origine et des audits hebdomadaires pour vérifier que les réponses GeoDNS correspondent encore à l’endroit où les utilisateurs atterrissent réellement. Pour les compromis DNS de principe (GeoDNS vs Anycast, matrices régionales), voir l’article 2026 · matrice d’entrée globale : GeoDNS, latence SSH et nœuds. Pour catalogues split-horizon, collant des résolveurs et p95 des artefacts sur le plan de données, lire split-horizon vs GeoDNS, TTL, caches et SSH inter-régions. Ici, on cible les seuils au niveau Worker, le collant de session à l’origine et une grille d’acceptation US Ouest face à Hong Kong / Singapour lorsque le plan de contrôle est le SSH vers une flotte de Mac distants.

Pourquoi ajouter des Workers quand le DNS managé propose déjà des sondes ? La santé « côté DNS » déplace les réponses à l’échelle du TTL ; un Worker peut orienter chaque requête en secondes, poser cookies ou en-têtes signés pour des sessions affinitaires, et conditionner les origines avec des prédicats composites (par exemple HTTPS 200 sur un chemin canari et ouverture TCP légère vers un port d’administration). Cela ne remplace pas le DNS : cela réduit l’écart entre « le résolveur croit que c’est sain » et « cet onglet ne doit pas changer de continent en pleine session ». Croisez le tableau ci-dessous avec les notes publiques du centre d’aide pour qu’astreinte et développeurs partagent le même vocabulaire.

DNS / routage Worker

Le DNS décide vers quel jeu de bords pointe un nom ; les Workers décident, requête par requête, quel pool d’origine répond lorsque ces bords sont déjà « chauds ». Ramener le TTL à soixante secondes partout augmente en général le bruit des résolveurs sans améliorer le SSH — car SSH contourne souvent le même hostname que le site marketing. Validez plutôt une clé d’affinité au Worker (cookie ou en-tête stable) et gardez l’ensemble d’origines admissibles étroit pour que les équipes distribuées ne changent pas de continent en pleine session lorsqu’un pool oscille.

Journalisez assez pour trancher les litiges : colo edge, identifiant d’origine choisi, version du snapshot de santé, et (outils internes) la réponse DNS qu’aurait vue un résolveur d’entreprise. Chaque semaine, comparez la géographie choisie par le Worker à l’intention GeoDNS ; si de larges écarts apparaissent, corrigez les données avant de « chasser la latence mystérieuse ». Pour HTTPS, préférez des clés de cache explicites et des URL signées de courte durée en périphérie ; pour l’automatisation, publiez des hostnames SSH régionaux déterministes même lorsque la marque reste unifiée.

Chemin d’origine : HTTPS vs SSH

Traitez le chemin d’origine comme deux voies. Voie un : HTTPS (tableaux de bord, webhooks, téléchargements d’artefacts via CDN ou Worker). Voie deux : SSH (bastions, git par SSH, shells sur vos builders Mac distants). L’Anycast séduit pour HTTPS ; c’est un piètre substitut à un SSH prévisible tant que vous n’avez pas validé le chemin TCP réellement utilisé par les ingénieurs. Conservez un alias fixe par PoP pour SSH et documentez le hostname promis par le marketing face à celui que la CI doit employer.

Le collant de session est plus simple à raisonner au Worker qu’en martelant le DNS : vérifiez le jeton d’affinité, plafonnez les connexions concurrentes vers l’origine, et basculez la charge vers un secondaire déjà chaud avant de dégrader la confiance par des sauts de continent aléatoires. Côté origine, alignez limites de connexion et concurrence Worker pour éviter le troupeau au moment où la santé bascule. Pour les artefacts, colocalisez répliques de registre et caches pull-through avec la région des runners — sinon une acceptation SSH verte masque des docker pull médiocres et des builds toujours lents.

Collaboration inter-régions & poignée SSH p95

Les équipes à cheval sur US Ouest et Hong Kong / Singapour doivent échantillonner chaque semaine le premier établissement SSH complet (TCP + échange de clés jusqu’au premier canal authentifié) et suivre le p95 contre une ligne de base écrite. Si le p95 dépasse la baseline d’environ quarante pour cent pendant quinze minutes, traitez-le comme incident réseau jusqu’à ce que traceroute et NOTAM câbles sous-marins disent le contraire — pas comme un « SSH lent aujourd’hui ». Enregistrez aussi le TTFB p95 de petits HEAD/GET d’artefacts sur le même tableau : si seul le SSH se dégrade, suspectez auth, MTU ou saturation du bastion ; si les deux se dégradent, suspectez la perte sur le WAN.

Industrialisez la collaboration : une fenêtre de recouvrement « golden hour » unique, gel des changements DNS non urgents hors de cette fenêtre, et deux observateurs indépendants (par exemple synthétique edge + sonde VLAN bureau) avant tout bascule automatique transpacifique. L’accusé humain pour les retournements océaniques reste préférable aux poursuites de flap BGP que les utilisateurs vivent comme déconnexions inexpliquées.

# Sonde scriptée de poignée SSH (compte lecture seule ; pas de secrets dans les tickets)
time ssh -o BatchMode=yes -o StrictHostKeyChecking=accept-new \
  -o ConnectTimeout=12 user@ssh.sg.example 'echo ok'

Lorsque la matrice est verte, figez PoP et hostnames pour le trimestre et laissez l’exploitation quotidienne ne toucher qu’à la santé synthétique et aux sondes SSH batch — moins coûteux que de renégocier le DNS à chaque sprint. Pour transformer la checklist en matériel, provisionnez ou étendez la capacité Mac tôt : validez régions et facturation sur la page tarifs, passez par achat lorsque vous êtes prêts à vous engager, et poursuivez les mesures deux semaines après la bascule pour garder Workers, DNS et lignes de base SSH alignés. La page accueil résume l’offre Mac cloud multirégion si vous devez la partager en interne avant commande.