Когда шлюз OpenClaw слушает loopback, а агент или оператор стучится с «внешней» стороны, легко получить два несовместимых мира аутентификации: один путь проходит с заголовком Authorization, другой — без него, потому что локальный клиент «доверяет» Unix-сокету или 127.0.0.1. Добавьте к этому неверно выставленный блок gateway.auth в конфигурации, серию рестартов и автоматическое переподключение — и вы увидите «зелёный» health снаружи при красных внутренних RPC, token_missing при самозвоне и внезапные провалы operator.read. Ниже — один воспроизводимый прогон, который сводит симптомы к одной таблице фактов: сначала doctor, затем машиночитаемый status, затем внешний probe с теми же параметрами, что и у реального клиента. Для смежной линии «секреты и doctor при смешанной установке» см.
руководство по SecretRef, backup и doctor;
про выделение нод в пуле CI — пул ресурсов Mac CI в 2026 году.
1. Три опоры: doctor, status и probe не взаимозаменяемы
doctor отвечает на вопрос «согласованы ли версии, пути, плагины и переменные окружения». status — на «что думает сам процесс шлюза прямо сейчас»: привязки портов, фактический режим аутентификации, последние ошибки инициализации. probe — на «видит ли сеть тот же TLS, SNI и токен, что и ваш агент». Если вы закрываете инцидент, не сравнив эти три среза на одной и той же минутной метке времени, следующий рестарт снова разведёт картину. Зафиксируйте артефакты трёх команд в тикете и только потом меняйте конфигурацию.
2. Ошибочный gateway.auth и loopback: где ломается контракт
Типичная ошибка — включить строгую проверку токена для внешних вызовов, но оставить внутренние RPC на loopback без явного заголовка. Шлюз честно требует секрет, внутренний клиент его не подставляет, и вы получаете череду отказов, которые лечат «перезапуском», потому что кэш соединения или порядок инициализации временно маскирует проблему. Исправление: один контракт — либо все вызовы несут токен, либо вы явно описываете доверенный интерфейс и отключаете двусмысленность в gateway.auth. Не смешивайте «иногда Bearer, иногда нет» на одном и том же маршруте.
3. «Буря» переподключений после рестарта
Агенты с экспоненциальной задержкой, health-check балансировщика и cron-задачи могут одновременно обрушить шлюз после деплоя. Если при этом токен ротируется медленнее, чем переподключаются клиенты, вы увидите всплеск 401 и ложное ощущение «битого» релиза. Остановите бурю: временный circuit breaker на входе, затем рестарт по одному классу клиентов, затем снова status. Не увеличивайте параллелизм, пока не подтверждена стабильная выдача токена.
4. RPC-самозвон и token_missing
Когда модуль шлюза вызывает собственный HTTP/RPC endpoint без прокидывания того же контекста безопасности, серверная сторона видит анонимный запрос и возвращает token_missing, хотя «снаружи» всё выглядит исправно. Лечится не новым секретом, а прокидыванием заголовка или внутреннего IPC, минуя публичный контур. Проверьте трассу: если исходный и целевой адрес совпадают по host/port, это почти наверняка самозвон.
5. operator.read и «тихие» провалы цепочки
Операторские чтения метаданных и состояний часто идут отдельным путём с более коротким тайм-аутом. При перегруженном event-loop или блокировке на диске вы получите не полный traceback, а обрыв на operator.read, который выглядит как «пропала связь с кластером», хотя шлюз жив. Сверяйте latency status с p95 probe и смотрите на загрузку CPU/RAM до того, как переписывать политику токенов.
6. Один прогон: чеклист, который можно вложить в runbook
Сохраните снимок конфигурации. Выполните doctor и приложите вывод. Снимите status в JSON и отметьте фактические поля auth/bind. Запустите probe с трёх точек: localhost на хосте шлюза, внутренняя сеть CI и внешний мониторинг. Сравните токены и отпечатки сертификатов. Только после зелёной триады меняйте gateway.auth или ротируйте секреты. Если после изменения снова появляется token_missing — сначала ищите самозвон, а не утечку секрета.
- Одинаковый путь к CLI и к демону в unit
launchdили Compose. - Одинаковый набор переменных, влияющих на токен, в интерактиве и в сервисе.
- Probe использует тот же SNI/Host, что и реальный агент.
- Ротация секретов отражена в артефакте CI до включения прод-трафика.
7. Высокопамятный удалённый Mac: всплеск памяти при длинном выводе агента
На ноде с большим объёмом ОЗУ команды иногда запускают «тяжёлый» агент с длинными цепочками рассуждения и буферизацией полного ответа. Шлюз держит соединение, оператор агрегирует логи, и при пике вы получаете рост рабочего набора процесса не из-за модели как таковой, а из-за накопления текста и вспомогательных структур в памяти. Симптом снаружи похож на деградацию auth: тайм-ауты на read, обрывы operator.read, повторные попытки с новым токеном. Лечится лимитами потокового вывода, отдельной нодой под длинные сессии и отключением бессмысленного логирования полного контекста на шлюзе. Имеет смысл вынести такой контур на выделенный Mac с запасом RAM и оставить шлюзу только сетевой и RPC-слой.
Почему macOS и Mac mini помогают держать шлюз предсказуемым
Для постоянного шлюза и сопутствующих демонов важнее стабильная память, предсказуемый NVMe и низкое энергопотребление в простое, чем гонка за максимальным числом ядер в шумной виртуальной среде. Mac mini на Apple Silicon даёт унифицированную память и высокую пропускную способность для параллельных HTTP и RPC-обработчиков, а macOS обеспечивает привычную модель launchd, подпись кода и предсказуемое энергопотребление — удобно для круглосуточного сервиса. Gatekeeper, SIP и FileVault снижают поверхность атаки по сравнению с разрозненными ПК, а компактный корпус и тихая работа упрощают размещение рядом с командой или в периметре малого дата-центра. Если вы выносите длинные сессии агента на высокопамятную удалённую ноду и хотите закрепить шлюз на надёжном «тихом» железе, Mac mini M4 — разумная стартовая точка по совокупной стоимости владения. Чтобы подобрать выделенную облачную машину в нужном регионе и объёме ОЗУ, откройте главную страницу Macstripe и согласуйте конфигурацию с профилем OpenClaw.
