Свежесть ответа публичного имени и свежесть проверки до origin — разные вещи. В Worker сверяйте подсказки вроде Request.cf с фактическими логами и раз в неделю сверяйте ответы GeoDNS с тем, куда реально уходит трафик. Сводную таблицу только по GeoDNS и SSH см. в матрице глобального входа Halo (GeoDNS и узлы); split-horizon, TTL и линию артефактов — в гайде по split-horizon и p95. Здесь — пороги именно для уровня Worker и приёмка SSH между US-West и Гонконгом / Сингапуром. Публичные шаги подключения — в разделе помощи.
| Режим | TTL публичного DNS (A/AAAA) | Интервал health-проб | Порог failover (ориентир) |
|---|---|---|---|
| Норма (публичные записи) | 300–900 с | Синтетика в Worker 5–15 с | 3 подряд неуспеха или в окне 30 с > 50% неуспешных проб |
| Перед обслуживанием | 60–120 с (за одно «старое» TTL до работ) | как в норме | ручное одобрение + в тикет — подписанный фрагмент dig |
| Прямая доступность origin | — | 10–30 с | 5 мин подряд недоступности → вторичный origin или деградация UI |
| Пакетные замеры SSH | — | 1–5 мин | p95 выше недельной базы на +40% дольше 15 мин → разбор с dig/traceroute |
time ssh … exit в batch-режиме, чтобы не смешивать сетевой обрыв и отказ аутентификации.Имена метрик в дашборде лучше привязать к решению: например worker_route_decision_total, origin_pool_unhealthy, ssh_handshake_ms_bucket — тогда при срабатывании порога из таблицы дежурный видит не абстрактный «красный», а конкретный рычаг (смена пула, откат TTL, ручной drain). Для команд с несколькими средами заведите один шаблон тикета: ссылка на график, вырезка конфигурации Worker (без секретов), два traceroute из US-West и из SG, и строка из ssh -G с финальным хостом — через два месяца такой runbook окупается одним ночным инцидентом меньше.
DNS и маршрутизация Worker
DNS задаёт, на какой набор edge «вешается» имя; Worker решает за секунды, в какой пул origin отдать конкретный запрос. Вместо постоянного TTL в 60 с чаще выгоднее узкий набор допустимых origin и ключ липкости (cookie или согласованный заголовок), который Worker проверяет перед проксированием: так команды по разным океанам реже ловят «прыжок» хоста посредине сессии. Согласуйте политику TTL с таблицей выше и не подменяйте измерения SSH одной лишь синтетикой на 443.
Путь к origin: HTTPS и SSH раздельно
Публичный HTTPS удобно вести через Worker или CDN с ветвлением по пути; крупные артефакты и реестры держите в том же экономическом и сетевом контуре, что и основной CI, чтобы не платить океаном на каждой чистой сборке. Для SSH не рассчитывайте на «магию» anycast без замеров: публикуйте региональные CNAME для бастиона и отдельно — черновиковый обход, если нужен изолированный путь. Липкость сессии смотрите связкой: проверка в Worker + лимиты соединений на origin — это устойчивее к флапу BGP, чем только укороченный DNS TTL.
Кросс-регион и чеклист p95 для SSH
Между западом США и хабами HK/SG измеряйте еженедельно p95 времени до готовности SSH (TCP и криптодо первого приглашения). Если p95 держится выше базы более чем на 40% дольше 15 минут — оформляйте инцидент с выводом dig и traceroute. В ту же строку отчёта кладите TTFB p95 для лёгкого HEAD/GET к артефактному зеркалу: ухудшился только SSH — смотрите маршрут и фильтры; просели оба — подозревайте трансокеанский участок или перегрузку общего транзита. Не смешивайте в одной выборке ноутбуки за корпоративным split-tunnel VPN и голый домашний интернет — иначе p95 «размазывается» и маскирует реальную боль удалённых разработчиков.
| Пункт приёмки | US-West ↔ HK/SG (ориентир) | Заметки эксплуатации |
|---|---|---|
| Первое установление SSH, p95 | Недельная база по среде; допуск до ×1,4 к базе | Фиксируйте тип ключей, MTU, цепочку ProxyJump для сравнимости |
| Артефакты HEAD/GET | TTFB p95 на одном листе с SSH | Один показатель «красный» → DNS/кэш; оба → транзит/перегрузка |
Когда таблицы зелёные, в начале квартала зафиксируйте PoP и имена хостов в операционном реестре и дальше меняйте в основном только синтетику и SSH-батчи — это дешевле хаотичных правок DNS. Реальные лимиты и оплату смотрите на публичных страницах vpshalo; закрепив регион за командой, вы переводите эту матрицу из слайда в ежедневный runbook. Для выбора площадки под RTT и биллинг начните с тарифов, затем оформите хост на странице покупки — так строки чеклиста останутся привязаны к одному заказу и одному тикету.
От матрицы к рабочему Mac в нужном регионе
На главной — обзор сервиса; тарифы — регион и ёмкость; помощь — подключение и предпосылки. Оформление — через страницу покупки. Связанные материалы — в блоге: так DNS, Worker и SSH остаются на одной операционной плоскости.