Сообщение «Ошибочный ответ сервера. Не удалось завершить тестирование» означает, что проверка системы не получила ожидаемый результат. Оно не указывает автоматически на повреждение таблицы MySQL. Причина может находиться в ответе приложения, авторизации, reverse proxy, PHP-FPM или ограничениях окружения.
Разберём порядок диагностики коробочной CMS «1С-Битрикс: Управление сайтом». Старый совет менять install.sql и уменьшать длину индексов относится к отдельным историческим ошибкам установки. Он не является универсальным исправлением работающего сайта и не должен применяться до получения конкретного сообщения базы.
1. Зафиксируйте, какой тест действительно упал
Откройте административный раздел проверки системы через поиск меню своей версии CMS. В штатном интерфейсе он находится среди инструментов настроек; название и доступность отдельных тестов зависят от продукта и версии. Официальное назначение инструмента описано в руководстве проверки системы.
Запишите название теста, время с часовым поясом, URL сайта, версию главного модуля и наблюдаемое сообщение. Уточните, воспроизводится ли отказ постоянно, только после долгого ожидания или только из одной сети. Не запускайте одновременно несколько полных проверок: это усложняет сопоставление запросов и журналов.
Сначала убедитесь, что обычные страницы и вход администратора работают. Если недоступен весь сайт, начинайте с его общего состояния, а не с изменения внутреннего теста.
2. Найдите запрос в инструментах браузера
Откройте Developer Tools, вкладку Network, включите сохранение списка запросов и повторите один тест. Найдите запрос, который завершился ошибкой или непосредственно предшествовал сообщению. Изучите метод, адрес, статус, время, Content-Type и тело ответа.
Не предполагается единый неизменный endpoint для всех релизов: используйте адрес из реального запроса. HTML-страница входа вместо ожидаемого служебного ответа указывает на авторизацию или редирект. PHP warning перед структурированными данными может ломать разбор даже при статусе HTTP 200.
При передаче диагностических данных удалите Cookie, Authorization, sessid, токены и персональные сведения. HAR и команда Copy as cURL могут включать действующую авторизацию. В заявке обычно достаточно обезличенного пути, метода, статуса, времени и небольшого фрагмента ошибки.
3. Как читать HTTP-статус без поспешных выводов
HTTP 401 или 403 требует проверки авторизации, WAF и ограничений доступа. HTTP 404 — фактического пути, маршрутизации и расположения сайта. HTTP 502 или 504 часто появляется на границе прокси и backend, но источник нужно подтвердить журналом, а не только кодом.
HTTP 500 может быть сформирован приложением или веб-сервером. HTTP 200 означает успешную передачу HTTP-ответа, но не гарантирует, что содержимое соответствует формату проверки. Редирект 301/302 способен перенести служебный запрос на другой hostname или форму входа.
Сопоставьте тело ответа с его ожидаемым назначением. Не «лечите JSON» включением вывода ошибок PHP на экран: это добавит служебные сведения в ответ и может раскрыть внутренние пути. Для диагностики нужны контролируемые журналы.
4. Проверьте прокси, HTTPS и соединение с backend
Определите точку TLS и цепочку обработки: CDN, Nginx, Apache, PHP-FPM. Сравните внешний URL с конфигурацией виртуального хоста. Проверьте, не меняет ли редирект протокол, host и путь служебного запроса.
Пример чтения заголовков публичной страницы без авторизации:
curl --max-time 15 -sS -D - -o /dev/null https://site.example/
curl --max-time 15 -sS -L -D - -o /dev/null https://site.example/Замените домен на свой. Второй запрос показывает цепочку редиректов; он не воспроизводит авторизованный POST проверки. Если используется WAF, найдите совпавшее событие по времени и пути. Корректное исключение делают для подтверждённого запроса, а не отключают защиту всего сайта.
В Nginx proxy_read_timeout относится к ожиданию между чтениями ответа проксируемого сервера, а не к единому таймеру всей операции. Для FastCGI используются другие директивы. Различия описаны в документации proxy module и FastCGI module. Увеличение таймаута без поиска зависания может только продлить ожидание.
5. Сопоставьте журналы по времени и запросу
Найдите access/error log выбранного virtual host, журнал PHP-FPM и доступный журнал CMS. Для systemd сначала определите реальные имена служб:
systemctl list-units --type=service --all | grep -E 'nginx|apache|httpd|php.*fpm'
# Пример для системы с указанными службами
sudo journalctl -u nginx --since '10 minutes ago' --no-pager
sudo journalctl -u php8.3-fpm --since '10 minutes ago' --no-pagerПоследнее имя — пример, а не обязательная версия PHP. Используйте найденную службу; отдельные установки пишут ошибки в файл, а не journal. Отсутствие сообщения в journal не доказывает отсутствия ошибки.
Сохраните связку: время, метод, путь, HTTP-статус, upstream-статус и текст ошибки. Разные часы серверов создают ложные несоответствия. Не переносите в общую заявку полный журнал с чужими запросами и сессионными данными.
6. Разделите PHP CLI и PHP веб-приложения
Команды ниже описывают CLI, который запускается из вашей оболочки:
php -v
php --ini
php -mОни не подтверждают версию, php.ini, модули и ограничения FPM-пула, обслуживающего сайт. У нескольких сайтов могут быть разные PHP и пользователи процесса. Параметры веб-окружения сверяйте через штатную диагностику CMS и конфигурацию конкретного пула.
Для рабочего окружения ошибки записывают в контролируемый журнал, а не выводят посетителю. Назначение log_errors, error_log и display_errors описано в документации PHP. Отдельно учитывайте request_terminate_timeout пула FPM и его журнал медленных запросов из настроек FPM.
Не оставляйте публичный phpinfo.php после диагностики. Его вывод может раскрывать окружение и конфигурацию, а удаление файла нужно включить в завершение работы.
7. Проверьте права, место и ограничения окружения
Прочитайте точный путь из ошибки. Определите пользователя PHP-процесса и проверьте доступ именно к этому объекту. Исправление всех каталогов командой chmod 777 скрывает причину и расширяет доступ другим процессам.
df -h
df -i
# Замените путь на объект из подтверждённой ошибки
namei -l /srv/www/example-site/bitrix/cacheСвободные гигабайты не означают наличие свободных inode. В отдельном tmp-каталоге, контейнере или квоте может закончиться ресурс независимо от общего диска. Проверьте владельца, ACL, SELinux/AppArmor и параметры open_basedir при их использовании.
Если тест обращается по сети, проверьте DNS и исходящее соединение из того же окружения. Успех curl от администратора на хосте не доказывает доступность из контейнера или ограниченного FPM-пула.
8. Когда нужно разбирать ошибку MySQL или MariaDB
Переходите к базе после конкретного сообщения: имя таблицы, операция, код SQLSTATE или описание индекса. Для версии используйте подключение с утверждённым способом хранения учётных данных, не вводя пароль в аргумент команды.
SELECT VERSION(), @@version_comment;Для подтверждённой проблемной таблицы сравните её структуру с поддерживаемой схемой установленного релиза. SHOW CREATE TABLE — операция чтения, но вывод может содержать внутренние имена; анализируйте его в контролируемом контуре. Ошибки длины индекса зависят от версии СУБД, кодировки, формата таблицы и схемы.
Редактирование install.sql меняет исходник установщика, а не обязательно структуру уже существующей таблицы. Уменьшение индекса может изменить семантику поиска или уникальности. Исправление схемы выполняют по подтверждённой процедуре поставщика после резервной копии и проверки на отдельном контуре.
9. Внесите одно изменение и повторите тот же тест
Сформулируйте подтверждённую причину и минимальную правку: корректный маршрут, восстановленный модуль PHP, разрешение нужного каталога или исправление конфигурации backend. Запишите состояние до изменения и способ возврата.
Проверяйте синтаксис изменённой конфигурации штатным средством, затем применяйте reload только соответствующей службы. Не совмещайте диагностику с массовым обновлением CMS, сменой PHP и изменением базы: результат будет трудно объяснить и откатить.
После исправления повторите именно исходный тест с тем же методом и контекстом авторизации. Проверьте обычные страницы, административный вход и затронутые фоновые задачи. Если проверка прошла только один раз, а причина не найдена, статус проблемы следует оставить наблюдаемым, а не объявлять окончательно устранённой.
10. Что приложить к итоговой заявке
Достаточный отчёт содержит версию CMS и веб-PHP, название теста, обезличенный запрос, HTTP-ответ, связанную ошибку журнала, подтверждённую причину и результат повторения. Для изменения указывают точный файл или настройку и место резервной копии.
Общий текст «не удалось завершить тестирование» — начало диагностики. Переход от него к конкретному запросу и ошибке позволяет исправить нужный уровень системы. Универсальная правка install.sql, открытие всех прав или отключение защиты не дают такого доказательства.
Удалите временные диагностические файлы, верните пилотные настройки логирования к принятому режиму и убедитесь, что технические сведения не показываются посетителям. Только после этого работу можно считать завершённой.