ИИ для тестирования сайтов блокируется хостингом: как обойти лимит SSH за 30 минут

Материал основан на практическом кейсе команды, которая строит ИИ-агента поверх CMS MODX. В первой части проекта агент научился читать структуру сайта: ресурсы, чанки, TV-параметры и зависимости между ними. Во второй части ему дали право не только анализировать, но и записывать изменения, подключаться по SSH, читать логи и запускать проверки. Именно здесь начались проблемы с хостингом, и их решение полезно каждому, кто автоматизирует работу с сайтом через ИИ.

Почему хостинг блокирует ИИ-агента?

Человек подключается к серверу один раз и работает внутри сессии: посмотрел файл, подумал, выполнил команду. ИИ-агент действует иначе. Он дробит задачу на множество коротких операций: прочитал один файл, открыл второй, поискал строку по проекту, проверил лог, уточнил версию PHP, запустил проверку синтаксиса.

Когда на одном хостинг-аккаунте лежат несколько сайтов и агент работает с каждым, количество подключений растёт лавинообразно. На одном из российских хостингов это привело к трём блокировкам за трое суток. Каждая длилась около шести часов. Добавить IP в белый список не получилось: такой опции у провайдера просто не было.

Что понадобится

• Доступ к серверу по SSH с правами на чтение и запись файлов сайта.
• ИИ-агент с поддержкой вызова внешних инструментов (в описанном проекте используется ChatGPT через API, но подход работает с любым агентом, умеющим выполнять shell-команды).
• Bash и стандартные утилиты Linux: OpenSSH, flock (утилита блокировки файлов, не даёт двум процессам делать одно и то же одновременно), awk.
• CMS MODX (или другая CMS, к которой вы строите интерфейс агента).
• 30 минут на настройку обёртки SSH и проверку.

Пошаговая инструкция

1. Определите фактический адрес сервера перед каждым подключением. Три разных домена в SSH-конфигурации могут вести к одному серверу и одному пользователю. Хостеру нет дела до названий ваших проектов, он считает подключения по реальному адресу. Обёртка SSH запрашивает у OpenSSH итоговые параметры:

effective_config="$("$REAL_SSH" -G "$@" 2>/dev/null || true)"
resolved_host="$(printf '%s\n' "$effective_config" | awk '$1 == "hostname" {print $2; exit}')"
resolved_user="$(printf '%s\n' "$effective_config" | awk '$1 == "user" {print $2; exit}')"
resolved_port="$(printf '%s\n' "$effective_config" | awk '$1 == "port" {print $2; exit}')"

1. Сформируйте ключ пула соединений по фактическому адресу, а не по имени проекта. Это гарантирует, что лимит считается так же, как его считает хостер:

pool_key="$(printf '%s@%s:%s' \
  "$resolved_user" \
  "$resolved_host" \
  "$resolved_port" | tr -c 'A-Za-z0-9._@:-' '_')"

1. Включите ControlMaster, чтобы десять команд агента не превращались в десять авторизаций. Одно мастер-соединение обслуживает все последующие команды:

SSH_OPTS=(
  -o ControlMaster=auto
  -o ControlPath="$CONTROL_PATH_TEMPLATE"
  -o ControlPersist=1h
  -o ServerAliveInterval=60
  -o ServerAliveCountMax=3
)

ControlMaster (режим SSH, при котором первое подключение становится «главным», а все следующие идут через него без повторной авторизации) решает основную проблему: вместо десятков авторизаций хостинг видит одну.

1. Защитите момент создания мастер-соединения блокировкой. Без этого два параллельных процесса агента могут одновременно увидеть, что мастера ещё нет, и оба начнут его создавать. Используйте flock:

if ! master_alive; then
  exec {bootstrap_fd}>"$pool_root/master.lock"
  /usr/bin/flock "$bootstrap_fd"
  if ! master_alive; then
    acquire_slot
    "$REAL_SSH" "${SSH_OPTS[@]}" "$@" &
    ssh_pid=$!
    # ожидание готовности мастера (до 5 секунд)
  fi
fi

1. Ограничьте число параллельных команд на один аккаунт. В описанном проекте по умолчанию допускается восемь одновременных команд, но для проблемного хостинга лимит снижен до двух. Подберите значение под ваш хостинг опытным путём.

2. Проверьте под нагрузкой. Запустите одновременно больше команд, чем допускает лимит, при отсутствии готового мастер-соединения. В описанном кейсе 12 одновременных команд дали одну авторизацию и не более двух параллельно выполнявшихся операций.

3. Вынесите запись файлов в отдельный инструмент. SSH оставьте для диагностики: чтение логов, проверка синтаксиса командой php -l, запуск сборки. Боевые файлы меняйте через специальный инструмент записи (в проекте он называется site-file), а не через ssh, scp, rsync или случайный sed. Это даёт контроль: агент не может молча переписать файл через командную строку.

Что делать с этим прямо сейчас, по ролям

Веб-разработчику или владельцу сайта на MODX. Если вы уже используете или планируете использовать ИИ для тестирования сайтов и автоматической правки, начните с обёртки SSH из этой инструкции. Она не требует ничего кроме стандартных утилит Linux и решает самую частую проблему: блокировку со стороны хостинга.

Автору Дзена или контент-маркетологу. Вы можете не настраивать SSH сами, но если ваш сайт обслуживает разработчик, перешлите ему этот материал. Агент, который сам находит и чинит ошибки, экономит часы на каждом обращении в поддержку или к фрилансеру.

Предпринимателю с сайтом на российском хостинге. Описанный подход работает на любом хостинге, поддерживающем SSH: Beget, TimeWeb, REG.RU и других. Если ваш разработчик уже экспериментирует с ИИ-агентами, убедитесь, что он знает про ControlMaster и лимитирование параллельных команд, иначе первая же автоматическая проверка сайта может закончиться блокировкой.

Команда проекта показала главное: между «агент нашёл решение» и «агент сам исправил сайт» лежит инженерная работа, и большая её часть связана не с ИИ, а с инфраструктурой, на которой этот ИИ должен работать.