2026: трансграничная команда — APNs и push: куда ставить мультирегиональный физический удалённый Mac — к «пользовательской зоне», «сессии разработки» или «выходу push Apple»? Sandbox/production, Device Token и RTT: матрица CI/CD (openssl/curl + FAQ)

2. Матрица: куда «приближать» физический удалённый Mac

Ответ почти всегда комбинированный: один Mac не может одновременно быть в кармане пользователя и в дата-центре Apple. Используйте строки как чек-лист приоритетов.

Для вебхуков и обратного прокси в CI на удалённом Mac см. runbook по токенам и прокси — те же принципы доверенного egress применимы к сервисам рядом с APNs-клиентом.

3. Sandbox, production и Device Token — вторая матрица

Правило: endpoint и происхождение device token должны быть согласованы. Перенос Mac между странами не меняет это правило — меняет только удобство получения токена с нужной сборки и стабильность TLS из вашей сети.

4. Семь шагов: как зафиксировать решение в CI/CD

1. Опишите сценарий отказа — только доставка, только билд, только backend JWT, или связка; выберите доминирующую строку в первой матрице.
2. Разведите треки — отдельные job-лейблы для «интерактив Xcode» и «headless push smoke» с разными сетевыми профилями.
3. Зашейте секреты — .p8, Key ID, Team ID, topic (bundle id) в секрет-хранилище; запретите ротацию без версионирования.
4. Проверьте egress — белый список доменов Apple push, без TLS MITM на исходящем пути (см. openssl ниже).
5. Логируйте ответы APNs — apns-id, статус HTTP/2 и тело ошибки; коррелируйте с JWT iat/exp.
6. Добавьте синтетику RTT — ежедневный curl из CI к обоим host с порогами алерта (например p95 < 400 мс внутри региона дата-центра).
7. Документируйте «источник токена» — какая сборка на каком устройстве выдала token, привязка к ветке и номеру билда.

5. Приёмка openssl и curl (копирование)

Проверка цепочки TLS к production APNs (замените хост на development для sandbox):

openssl s_client -connect api.push.apple.com:443 -servername api.push.apple.com \
  -brief </dev/null 2>&1 | tail -n 5

Метрики времени установления соединения (HTTP/2, без полного push-payload):

curl -o /dev/null -sS --http2 -w \
'time_namelookup:%{time_namelookup}\n time_connect:%{time_connect}\n time_appconnect:%{time_appconnect}\n' \
https://api.push.apple.com/

Ожидайте Verify return code: 0 (ok) в openssl. Для curl без клиентского сертификата APNs вернёт ошибку уровня приложения — это нормально; важны time_appconnect и отсутствие обрыва на TLS.

6. Цифры и параметры для слайдов / постмортемов

• Порты: APNs клиентский канал — TLS на 443 к перечисленным host; отдельная «региональная» таблица портов на стороне Apple для вашего кода не публикуется как обязательная к маршрутизации Mac.
• JWT для APNs: типичный срок жизни токена авторизации — порядка 1 часа (настраивается; следите за рассинхроном часов NTP на раннере).
• RTT как SLO: закрепите для своего региона p95 200–500 мс до api.*.push.apple.com как внутренний коридор; трансграничный линк сверх 250 мс среднего RTT — сигнал пересмотреть egress, а не переносить Xcode «к Apple».

7. FAQ

Нужен ли отдельный Mac в каждой стране для push?

Нет, если backend и CI стабильно достают до APNs и вы можете воспроизводить полевые сети таргетированными тестами или бета-пользователями. Да, если комплаенс или физический доступ к SIM/роумингу обязателен.

Влияет ли VPN пользователя на APNs?

На путь уведомления до устройства — косвенно (радио, энергосбережение, задержки ОС). На ваш серверный вызов APNs — нет; VPN сидит на клиенте.

Стоит ли гнать push-трафик через тот же reverse proxy, что и вебхуки?

Обычно нет: держите long-lived HTTP/2 к APNs на отдельном исходящем пути без лишних L7-плагинов. Иначе вы получите те же классы ошибок, что при проксировании произвольного TLS.