EasyAppointments на сервере: частые ошибки и решения

MAATRIX

EasyAppointments — простая и удобная система онлайн-записи для мастеров, клиник, салонов и любых услуг, где нужен календарь с бронированием. Она легко ставится на LAMP-стек или в Docker, но именно из-за этой простоты владельцы часто спотыкаются на одних и тех же граблях: белый экран после установки, не приходят письма клиентам, cron не шлёт напоминания, «battery-запись» ломается после смены часового пояса. Разберём по шагам, откуда растут эти проблемы и как их закрыть на своём сервере — без танцев с бубном.

Белый экран или 500-я ошибка после установки

Самая частая жалоба — после composer install и настройки .env открывается пустая страница или голая ошибка 500 без деталей. Почти всегда причина в правах на директории и в отключённом отображении ошибок PHP.

Проверьте права на storage и логи:

sudo chown -R www-data:www-data /var/www/easyappointments/storage
sudo find /var/www/easyappointments/storage -type d -exec chmod 755 {} \;
sudo find /var/www/easyappointments/storage -type f -exec chmod 644 {} \;

Если приложение и веб-сервер работают от другого пользователя (например, nginx в CentOS-подобных дистрибутивах или deploy при деплое через CI), подставьте нужное имя вместо www-data.

Чтобы увидеть реальную ошибку, временно включите вывод в PHP:

; /etc/php/8.2/fpm/php.ini
display_errors = On
error_reporting = E_ALL

и перезапустите PHP-FPM:

sudo systemctl restart php8.2-fpm

После диагностики обязательно верните display_errors = Off — показывать трейсы ошибок в проде публично небезопасно. Смотрите также лог самого приложения — он обычно пишется в storage/logs/ — там часто видна конкретная строка с исключением, которую не покажет общий 500-й экран nginx.

Ошибка подключения к базе данных

Если после установки видите SQLSTATE[HY000] [1045] Access denied или Unknown database, проблема в несовпадении данных из .env и реальных настроек MySQL. Проверьте файл конфигурации:

cat /var/www/easyappointments/.env | grep DB_

Убедитесь, что пользователь и база реально существуют и права выданы:

CREATE DATABASE easyappointments CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'ea_user'@'localhost' IDENTIFIED BY 'СложныйПароль';
GRANT ALL PRIVILEGES ON easyappointments.* TO 'ea_user'@'localhost';
FLUSH PRIVILEGES;

Отдельно частая ловушка — DB_HOST=localhost в контейнерном окружении. Если MySQL запущен в соседнем Docker-контейнере, localhost внутри контейнера с EasyAppointments указывает сам на себя, а не на базу. Нужно имя сервиса из docker-compose.yml, например DB_HOST=mysql. Общие проблемы с самим MySQL — включая too many connections и вопросы прав — разобраны в статье про частые ошибки MySQL на сервере.

Не приходят письма — клиенту и мастеру

EasyAppointments отправляет подтверждения записи и напоминания по email, и это узкое место номер один в реальной эксплуатации. Если письма не уходят вообще, начните с проверки SMTP-настроек в .env:

EMAIL_HOST=smtp.yourdomain.com
EMAIL_PORT=587
EMAIL_USERNAME=noreply@yourdomain.com
EMAIL_PASSWORD=...
EMAIL_REPLY_TO=noreply@yourdomain.com

Проверить соединение с почтовым сервером можно прямо с сервера:

telnet smtp.yourdomain.com 587

Если порт закрыт — почти всегда виноват провайдер: многие хостинги блокируют исходящий SMTP по умолчанию из-за спама, и его нужно отдельно разблокировать в панели или у поддержки. Если вы настраиваете собственный почтовый сервер на этой же машине, стоит заранее прочитать про настройку Postfix и типичные проблемы с исходящей почтой — там разобраны SPF, DKIM и репутация IP, без которых письма улетают в спам даже при технически рабочей отправке.

Отдельно проверьте, что письма не блокируются самим приложением: в админке EasyAppointments в разделе Settings → Business есть флаг подтверждения email-уведомлений, а часть сообщений отправляется только если у услуги/специалиста в профиле указан email.

Cron не отправляет напоминания о записи

Функция напоминаний за N часов до визита работает только если настроен cron, который дёргает специальный скрипт приложения. Без него сама запись создаётся нормально, но письмо-напоминание клиент никогда не получит — и это заметят не сразу, а через недели, когда накопятся жалобы.

Добавьте задачу в crontab пользователя, от которого работает приложение:

crontab -e

*/5 * * * * curl -s https://yourdomain.com/index.php/console/reminders >/dev/null 2>&1

Проверить, что задача реально выполняется, можно логированием вывода во временный файл вместо /dev/null на пару дней — и потом посмотреть, накопились ли там ошибки. Если cron в принципе не срабатывает ни для одной задачи на сервере, а не только для EasyAppointments, — это отдельная и более общая проблема; она разобрана в статье про типичные ошибки cron на сервере: там и про переменные окружения, которых нет в cron-сессии, и про правильные пути к бинарникам.

Проблемы с часовым поясом и расписанием

Записи «съезжают» на час или два — классика для серверов, где часовой пояс операционной системы не совпадает с часовым поясом, который приложение ожидает от MySQL. EasyAppointments хранит время бронирования и сверяет его с рабочими часами специалиста, поэтому рассинхрон между PHP, MySQL и браузером клиента даёт видимые артефакты: свободный слот показывается занятым, или наоборот.

Выставьте единый часовой пояс на трёх уровнях:

sudo timedatectl set-timezone Europe/Moscow

; php.ini
date.timezone = Europe/Moscow

SET GLOBAL time_zone = '+03:00';

И в .env приложения задайте DEFAULT_LANGUAGE и региональные настройки согласно бизнес-логике — часть логики отображения времени в EasyAppointments опирается именно на них, а не только на системный TZ.

Медленная загрузка календаря и таймауты при высокой нагрузке

Если у вас несколько специалистов и активное расписание, а страница календаря начинает грузиться по 5-10 секунд или отдаёт 504 при пиковой нагрузке — обычно дело в связке nginx как обратного прокси перед PHP-FPM с заниженными таймаутами и недостаточным пулом воркеров.

Проверьте базовые параметры PHP-FPM пула:

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8

и таймаут в конфиге nginx для этого сайта:

proxy_read_timeout 60s;
fastcgi_read_timeout 60s;

Если проблема системная — nginx часто отдаёт 504 при перегрузке апстрима, а не только у EasyAppointments, и это отдельная тема диагностики. Отдельно проверьте медленные SQL-запросы через EXPLAIN — на большой базе клиентов и записей без индексов на полях даты и специалиста запросы календаря могут упираться в полное сканирование таблицы.

SSL, домен и безопасность публичной формы записи

Форма бронирования обычно открыта публично — её вставляют на сайт клиники или салона через iframe или прямую ссылку. Это значит, что HTTPS обязателен: без него браузеры блокируют встраивание в iframe на HTTPS-страницах, а часть клиентов будет получать предупреждение о небезопасном сайте.

Быстрый выпуск сертификата через certbot:

sudo certbot --nginx -d booking.yourdomain.com

Если сертификат уже был выпущен, но nginx продолжает отдавать старый или вообще не подхватывает HTTPS-конфиг — не спешите переустанавливать certbot, обычно причина проще и описана в статье nginx не применяет SSL: причины и решение. А если сертификат вовсе перестал продлеваться сам — чаще всего дело в остановленном cron/systemd-таймере certbot, а не в самом домене.

Дополнительно закройте админ-панель EasyAppointments (/index.php/backend) от перебора паролей: ограничьте доступ по IP через nginx, если админ заходит с фиксированного адреса, или хотя бы поставьте fail2ban на форму логина.

Частые вопросы