Адрес Битрикс24 сменили, сотрудники уже заходят на новый домен, а ночной обмен отвечает ошибкой. Не начинайте с пересоздания всех интеграций. Сначала докажите, куда уходит один реальный запрос.
Webhook URL включает host портала, служебный путь, ID владельца и секрет. После переезда старый URL нельзя считать постоянным API-адресом. Секретную часть не вставляйте в тикет и не печатайте в общий лог.
Зафиксируйте два адреса
Запишите старый и новый host без пути /rest/.... Затем найдите старое значение в конфигурации приложения, переменных окружения, secret storage, callback URL и настройках фоновых заданий.
# Проверяем только публичный host, без webhook secret
curl.exe -sS -o NUL -w "%{http_code} %{url_effective}
" https://new-portal.example.ru/
# Поиск старого host в отслеживаемых файлах проекта
git grep -n "old-portal.example.ru" -- .
# Пример проверки runtime-переменной без печати секрета
if ($env:B24_WEBHOOK_URL -like '*new-portal.example.ru*') { 'host ok' } else { 'old host' }В production не выводите значение переменной целиком. Проверяйте только совпадение host. Если URL лежит в менеджере секретов, обновляйте его там, а не в repository.
Карта зависимостей после смены домена
| Компонент | Что искать | Контроль |
|---|---|---|
| Входящий webhook | Старый host и секрет | Новый безопасный REST-вызов |
| Локальное приложение | Callback и redirect URI | Повторная авторизация, если требуется |
| Worker обмена | Runtime environment | Процесс перечитал конфигурацию |
| Сайт | Виджеты, CRM-формы, callback | Одна тестовая заявка |
Порядок восстановления
- Остановите только отправителя проблемной очереди, а не весь сайт.
- В Битрикс24 откройте Разработчикам → Интеграции и найдите webhook по владельцу и назначению.
- Создайте новый webhook либо пересоздайте требуемый по актуальным правилам. Выдайте минимальные права.
- Сохраните URL в secret storage и перезапустите только нужный worker.
- Выполните один метод чтения. Проверяйте JSON-поле
resultи отсутствиеerror. - Запустите одну тестовую бизнес-операцию с отдельным ID и сверьте журнал.
- Верните очередь небольшими порциями, наблюдая ошибки и дубли.
PASS и FAIL
- PASS: runtime-процесс обращается к новому host, а секрет не виден в логах.
- PASS: контрольный REST-метод возвращает JSON с result.
- PASS: одна тестовая операция создаёт одно ожидаемое изменение.
- FAIL: браузер открывает новый портал, но worker всё ещё вызывает старый домен.
- FAIL: ответ 200 содержит HTML страницы входа вместо REST JSON.
Четыре типичных ошибки
Меняют только .env в release. PM2 или другой worker продолжает работать со старым окружением. Проверьте effective host после reload, не печатая URL целиком.
Сохраняют новый URL в Git. Вместе с ним уезжает секрет. В repository допустимо хранить только имя переменной и пример без credentials.
Забывают исходящие связи. Входящий webhook уже работает, но callback приложения, открытые линии или виджет сайта продолжают ссылаться на старый адрес.
Сразу включают backlog. Если обработчик не идемпотентен, повтор старых заданий создаёт дубли. Начните с одного ID.
Приёмочный чек-лист
- Старый host найден во всех конфигурационных слоях.
- Новый webhook имеет только нужные права.
- Секрет маскируется в логах и мониторинге.
- Worker перечитал environment.
- Контрольный метод чтения и одна запись прошли.
- Очередь включена постепенно.
Проверьте, где приложение взяло effective URL
Файл конфигурации и работающий процесс могут расходиться. В контейнере остался старый environment, systemd читает другой EnvironmentFile, а PM2 хранит прежнее значение до reload. Добавьте диагностическую строку, которая печатает только host и имя профиля. Путь и секрет маскируйте полностью. После перезапуска ищите именно эту строку, а не полагайтесь на дату файла.
Если интеграция использует несколько порталов, не делайте глобальную замену строки. Таблица соответствий должна хранить tenant или portal ID и отдельный endpoint. Иначе исправление одного клиента может перенаправить запросы другого. Контрольный тест отправляйте с ID тестовой сделки, которую легко найти и безопасно удалить по штатной процедуре.
Что записать в журнал переключения
- компонент и владелец интеграции;
- старый и новый host без секретного пути;
- время reload процесса;
- проверенный REST-метод и HTTP-код;
- ID одной тестовой операции;
- число элементов backlog до и после запуска.
Отдельно проверьте outbound webhook и callback приложения. Они работают в обратном направлении и могут храниться не там, где входящий REST URL. Если один контур уже зелёный, это не доказывает исправность второго.
После возврата очереди сравните скорость обработки и число ошибок за короткое окно. Резкий рост 401 или 403 означает, что часть worker всё ещё использует старые credentials либо другой пользователь не имеет нужного scope.
Что делать, если не помогло
Соберите таблицу: компонент, effective host, HTTP-код, тип ответа, владелец webhook. Если curl с нового адреса работает, а worker нет, проблема уже не в Битрикс24: смотрите env процесса, proxy и кэш конфигурации. Если ответ даёт 403, используйте диагностику scope и прав. Выбор между REST и webhook разобран в отдельной инструкции. Мы можем проверить и доработать интеграцию Битрикс24 с безопасным повторным запуском.
