Эта страница поможет, если агент установлен и запущен, но не подключается к серверу Ринго или часто теряет соединение. Проверки одинаковы для macOS, Windows и Linux: они касаются сервера, прокси и сети между устройством и сервером. Как проверить сам агент на устройстве, см. страницу для вашей ОС: macOS, Windows, Linux.
Агент связывается с сервером двумя способами. Постоянное соединение websocket с https://<домен>/socket.io/ нужно, чтобы получать команды сразу и работал веб-терминал. Запросы HTTPS к https://<домен>/agent/ на Windows и Linux агент отправляет при регистрации, обновлении, получении команд и отправке результатов. На macOS по этим адресам пакет агента скачивает сама macOS по MDM-команде установки агента, а сам агент использует только /socket.io/. Подробнее см. Как устроен Ринго → агент.
/socket.io/ или /agent/ — см. шаг 1.Выполните на устройстве или на другом компьютере в той же сети. На Windows вводите curl.exe, а не curl: в PowerShell curl — это другая команда.
Проверьте адрес обновлений агента:
curl -s -o /dev/null -w '%{http_code}\n' https://<домен>/agent/manifest
Ожидаемый результат: 200.
Проверьте адрес соединения websocket:
curl -s "https://<домен>/socket.io/?EIO=4&transport=polling"
Ожидаемый результат начинается с 0{"sid":"…","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000.
| Результат | Причина |
|---|---|
200 и 0{"sid":…} |
Адреса доступны. Переходите к шагу 2. |
404 или 403 |
На прокси нет блока location /socket.io/ или /agent, либо на них распространяется ограничение allow/deny для веб-интерфейса. |
502 или 503 |
Прокси не может подключиться к backend. |
000 или таймаут |
Соединение блокирует межсетевой экран, DNS или VPN в сети устройства. |
Ошибка сертификата при запуске curl без -k |
См. шаг 3. |
Агенту недостаточно, чтобы /socket.io/ отвечал: соединение должно переключаться на websocket и долго оставаться открытым.
Проверьте переключение:
curl -s --max-time 5 --http1.1 -o /dev/null -w '%{http_code}\n' -H 'Connection: Upgrade' -H 'Upgrade: websocket' -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' "https://<домен>/socket.io/?EIO=4&transport=websocket"
Ожидаемый код — 101. После него соединение остаётся открытым, поэтому команда завершается через 5 с по ограничению --max-time. Значение Sec-WebSocket-Key — пример ключа из стандарта WebSocket (RFC 6455), подходит любое. Если код другой, добавьте на прокси (nginx, блок location /socket.io/):
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
Агент то подключается, то пропадает. Прокси, балансировщик или облачный балансировщик нагрузки разрывает соединение по таймауту бездействия. Сервер отправляет ping каждые 25 с, поэтому таймаут бездействия короче 25 с разрывает соединение постоянно. Признак в логе backend — Disconnected: <UDID>, reason: transport close и сразу за ним Agent connected. Признаки в логе агента см. на странице вашей ОС. Увеличьте таймауты на прокси:
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
Чтобы узнать, сколько раз агент переподключался за сутки, выполните на сервере:
docker logs roll-deploy-backend --since 24h 2>&1 | grep -i '<UDID>' | grep -cE 'Agent connected|Disconnected'
Десятки и сотни переподключений у устройства, которое не покидало сеть, указывают на таймаут на пути. Если интервалы между подключением и отключением одинаковые (30 с, 60 с, 300 с), это и есть значение таймаута прокси или балансировщика.
Прокси должен отдавать полную цепочку: сертификат сервера и промежуточный сертификат. Устройства и агенты не загружают недостающий промежуточный сертификат по ссылке из сертификата сервера, поэтому без него не доверяют серверу. Проверьте цепочку на Mac или компьютере с Linux в той же сети (в Windows нет openssl):
echo | openssl s_client -connect <домен>:443 -servername <домен> -showcerts 2>/dev/null | grep -E '^ *[0-9] s:|^ +i:'
В выводе должно быть не меньше двух сертификатов: сертификат сервера и промежуточный. Если сертификат один, укажите в ssl_certificate полную цепочку (fullchain: сначала сертификат сервера, затем промежуточный). Обновите сертификат на всех узлах: прокси, балансировщиках, CDN.
Затем проверьте, что устройство доверяет сертификату сервера. Выполните команду на устройстве, на котором не работает агент:
curl -sS -o /dev/null https://<домен>
Ожидаемый результат: команда ничего не выводит. Если выводится curl: (60) SSL certificate problem, устройство не доверяет сертификату сервера. Текст после этих слов указывает причину, например unable to get local issuer certificate или certificate has expired.
Другие причины недоверия к сертификату:
issuer в выводе выше: указан ваш удостоверяющий центр или прокси.Обратитесь в техническую поддержку (см. Обращение в поддержку). Приложите результаты проверок из шагов 1–3, выполненных из сети устройства, логи агента (где их найти, см. страницу вашей ОС) и записи лога backend по UDID устройства: Agent connected, Disconnected, Failed to decrypt agent auth message.
Проверено на Ринго 3.0.5, октябрь 2026. Тексты ошибок — Справочник ошибок, термины — Термины.