Сначала определите, что именно не сохраняется

Одинаковый симптом может появиться на разных этапах. Нажмите «Сохранить», откройте DevTools → Network и найдите POST/AJAX-запрос. Самая полезная информация — URL запроса, HTTP-код и тело ответа.

Быстрый ориентир: 403 — чаще права/WAF/сессия, 413 — слишком большой запрос, 422 — валидация, 500 — PHP/CMS, 200 с ошибкой в JSON — приложение само отклонило сохранение.

Симптом → куда смотреть

СимптомПервая проверкаЧастая причина
Кнопка не реагируетConsole и NetworkJavaScript-ошибка, перекрывающий элемент, сломанный обработчик
403Network Response + WAF logModSecurity/WAF, ACL, истёкшая сессия
413Размер запросаpost_max_size, upload_max_filesize, лимит web-сервера
500PHP/CMS error logFatal error, несовместимый модуль, исключение
200, но данные старыеResponse + база + кэшВалидация, запись не прошла, кэш/реплика
Часть полей пропадаетmax_input_varsСлишком много полей формы

Проверить PHP-лимиты, влияющие на сохранение

BASH
php -r '
foreach (["max_input_vars","post_max_size","upload_max_filesize","memory_limit","max_execution_time"] as $k) {
    echo $k."=".ini_get($k).PHP_EOL;
}
'

Если пропадает только часть большой формы

Особенно часто это проявляется в каталогах, конструкторах форм и страницах с десятками опций. Проверьте max_input_vars: PHP может отбросить параметры после достижения лимита. После изменения лимита обязательно убедитесь, что менялась конфигурация именно того PHP handler, который обслуживает сайт, а не только CLI.

403 после нажатия «Сохранить»

Не отключайте WAF целиком. Сначала сравните URL, payload и время запроса с журналом ModSecurity/WAF. Если блокируется конкретное поле, ищите правило и причину срабатывания. Дополнительно проверьте сессию пользователя и права его роли.

500 при сохранении

Сразу воспроизведите ошибку ещё раз и откройте свежие строки PHP/web-server log. Не очищайте журнал до фиксации причины. На ISPmanager журнал домена удобно смотреть в панели; на сервере часто используется каталог /var/www/httpd-logs/.

Быстро проверить последние серверные ошибки

BASH
sudo tail -n 100 /var/www/httpd-logs/example.com.error.log
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

Если запрос успешный, но запись в базе не меняется

  • проверьте, нет ли сообщения в JSON-ответе Network;
  • проверьте подключение к нужной базе и окружению;
  • убедитесь, что запись не откатывается транзакцией;
  • проверьте валидацию приложения и уникальные ограничения;
  • сравните время изменения записи в базе с моментом запроса.

Проверка после исправления

  1. измените одно тестовое поле;
  2. убедитесь, что запрос вернул нормальный ответ;
  3. перезагрузите страницу без кэша;
  4. войдите заново и проверьте значение;
  5. повторите с другой ролью пользователя, если проблема зависела от ACL.

Скачать набор диагностики

RuJul Site Diagnostics — один ZIP

Связанные инструкции