2026: OpenClaw в Slack на Linux VPS: токены бота, подписки на события, callback URL к шлюзу — воспроизводимая схема и поуровневый FAQ по 403 и повторам

У Event Subscriptions в Slack три жёстких ожидания: стабильный публичный HTTPS, проверяемые подписи и быстрый JSON-ответ. Когда шлюз OpenClaw сидит на небольшом Linux VPS, редко виноват «сам Slack» — чаще цепочка TLS, несовпадение пути между настройками приложения и обратным прокси или промежуточный слой, который отдаёт 403 ещё до того, как до проверки signing secret дойдёт ваш код. Сначала зафиксируйте воспроизводимый каркас сети (привязка процесса, loopback, TLS) по матрице из 2026 OpenClaw на Linux в облаке: минимальная поверхность атаки — шаблоны firewall, привязка Gateway к loopback, SSH-туннель для управления и публичный HTTPS (матрица и FAQ), затем выровняйте токены и callback так же дисциплинированно, как короткоживущие CI-секреты в Короткий цикл CI в 2026: всплеск сборок и новый облачный Mac — регистрация Runner, сеть и минимальные токены за 30–60 минут (чеклист и FAQ).

Что Slack ждёт «на проводе»

Создайте или переиспользуйте Slack-приложение, включите Event Subscriptions и укажите Request URL на ваш VPS по 443. Slack сначала шлёт url_verification; стек должен вернуть challenge в JSON за несколько секунд, не буферизуя тело дважды. После верификации приходят конверты с X-Slack-Signature и X-Slack-Request-Timestamp. Signing secret храните в SecretRef или файле с правами только у пользователя шлюза — не в Git и не в world-readable /etc. Токен бота (xoxb-) питает вызовы Web API; сужайте OAuth-скоупы до реально используемых каналов и методов, чтобы утечка не разошлась по воркспейсу.

Callback URL → TLS на границе → loopback Gateway

Поднимайте шлюз на 127.0.0.1 на том порту, который зафиксирован в конфигурации OpenClaw, терминируйте TLS на Nginx или Caddy и проксируйте обычные POST и при необходимости WebSocket. Публичный путь в Slack (например /slack/events) должен совпадать с блоком location — лишний слэш или двойной префикс (/openclaw/slack/slack/events) достаточен, чтобы Slack получил 403 от прокси, пока curl на loopback выглядит «зелёным». Логируйте статус upstream отдельно от процесса шлюза, чтобы видеть, вернул ли edge ответ до Node-воркера.

curl -sS -D- \
  -H 'Content-Type: application/json' \
  -d '{"type":"url_verification","challenge":"ping"}' \
  https://claw.example.com/slack/events

Слэш-команды, shortcuts и interactivity

Event Subscriptions — лишь один вход. У слэш-команд, shortcuts и Block Kit interactivity свои Request URL; каждый должен попадать на тот же TLS-край с той же дисциплиной путей. Если события идут в OpenClaw, а interactivity указывает на старый туннель, операторы видят «кнопки мертвы», пока DM ещё ходят — типичный раскол после миграции. Держите все callback на одном сертификате и одном конвейере логов, чтобы охота за 403 сводилась к одному запросу в журнал.

Чеклист воспроизводимой установки (Linux VPS)

Возьмите Ubuntu LTS или Debian 12, установите OpenClaw из того же канала пакетов, который закреплён в проде, и один раз пройдите онбординг из UTF-8 shell под отдельным UNIX-пользователем. Откройте 22/tcp только с админских IP, 80/443 — для ACME и callback Slack, порт шлюза не публикуйте на 0.0.0.0/0. После того как openclaw gateway status показывает слушатель на loopback, выпустите сертификаты, перезагрузите прокси и только потом включайте переключатель Event Subscriptions. Снимите tarball ~/.openclaw и workspace до смены signing secret — откат должен быть «распаковал — перезагрузил unit», а не раскопки.

Поуровневые 403, replay и повторы доставки

Разбирайте стек сверху вниз — у каждого уровня разные отпечатки в access- и application-логах.

Slack может ретраить доставку; обработчики должны быть идемпотентны по event_id или вашему детерминированному ключу. Если ответить «успех» до завершения побочных эффектов, повтор может дважды списать внешний API; если сначала доделать работу, но выйти за HTTP-таймаут Slack, тоже будет retry. Держите ACK коротким, тяжёлую работу — в очередь, логируйте X-Slack-Retry-Num, чтобы отличать первую доставку от повтора.

После ротации секретов перезапустите шлюз через unit, убедитесь, что процесс унаследовал новое окружение, и отправьте тестовое событие из Slack App Management. Если верификация прошла, а живые сообщения застряли, перепроверьте OAuth-скоупы и членство бота в канале — подписки срабатывают только там, где бот реально присутствует с нужными granular scopes.