Симптом: vpnbot-xray-release-alert.service падал на каждой попытке
доставки (раз в RETRY_SECONDS=900): 20 с таймаута на заблокированном
149.154.166.110:443, затем ENETUNREACH на IPv6. Ни авария, ни сообщение
о восстановлении не доходили.
Первопричина: монитор слал sendMessage прямым urllib.urlopen на
api.telegram.org, в обход сетевого контракта, которым пользуются все
процессы бота: VPNBOT_TELEGRAM_IP_FAMILY=ipv4, резервные
VPNBOT_TELEGRAM_API_FALLBACK_IPV4S и relay-туннели node manager из
/run/vpnbot-node-manager/telegram-egress.json.
Исправление: контракт читается из того же root-only runtime-env бота,
откуда уже берётся токен (без копии в /etc и без импорта кода бота).
Маршруты как у бота: свежая проекция со здоровыми портами api.telegram.org
- только loopback-relay; иначе резервные IPv4, затем DNS выбранного
семейства. Меняется лишь TCP-адрес, TLS держит SNI и проверку сертификата
api.telegram.org.
Инвариант: следующий маршрут пробуется только если соединение не
установилось и запрос не ушёл; ушедший запрос без ответа -
telegram_delivery_ambiguous без повтора в этом запуске. Каждый отказ
несёт typed-код (telegram_egress_config_invalid, telegram_no_route,
telegram_connect_failed, telegram_delivery_ambiguous,
telegram_http_status, telegram_response_invalid, telegram_rejected).
Проверка: unittest discover - 44 теста, включая TLS-сервер с SNI
api.telegram.org за loopback-портом; живой запрос getMe с заведомо
неверным токеном через relay 18443/18444 и резервный 149.154.167.220
получил 401 от Telegram.
Claude-Session: local_e733a8c5-58d7-482a-bce7-150abdb901db
loop-uh
28b36ad535