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

MAATRIX

Commento — движок комментариев без рекламы, трекеров и слежки за читателями, который многие ставят как замену Disqus на статичный блог или Hugo-сайт. Проблема в том, что проект в основном заброшен, документация местами устарела, а типичные ошибки — от падающего при старте контейнера до немых комментариев — гуглятся с трудом. Ниже — рабочие решения по каждой из них и честный разговор о том, стоит ли вообще ставить Commento в 2026 году.

Контейнер Commento не стартует или сразу падает

Самая частая ситуация: docker compose up поднимает контейнер, он живёт пару секунд и уходит в Restarting. Смотрите логи первым делом:

docker compose logs commento --tail=50

Почти всегда там одна из двух причин. Первая — не задана или неверно оформлена переменная COMMENTO_POSTGRES. Commento ждёт строку подключения в формате libpq, а не разрозненные host/user/pass:

COMMENTO_POSTGRES=postgres://commento:пароль@db:5432/commento?sslmode=disable

Если вы скопировали переменные из старого мануала, где COMMENTO_POSTGRES_HOST и COMMENTO_POSTGRES_PORT заданы отдельными ключами — это формат древних версий, актуальный образ его не понимает и просто падает без внятного сообщения.

Вторая причина — Commento стартует раньше, чем PostgreSQL успел поднять кластер и принять соединения. Если в docker-compose.yml есть только depends_on: - db без healthcheck, Docker считает зависимость выполненной в момент, когда контейнер базы запущен, а не когда PostgreSQL реально готов принимать TCP-соединения. Добавьте healthcheck и условие:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: commento
      POSTGRES_USER: commento
      POSTGRES_PASSWORD: пароль
    volumes:
      - commento_pg:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U commento"]
      interval: 5s
      timeout: 5s
      retries: 10

  commento:
    image: registry.gitlab.com/commento/commento:latest
    depends_on:
      db:
        condition: service_healthy
    environment:
      COMMENTO_ORIGIN: https://comments.example.com
      COMMENTO_PORT: 8080
      COMMENTO_POSTGRES: postgres://commento:пароль@db:5432/commento?sslmode=disable
    ports:
      - "127.0.0.1:8080:8080"
    restart: unless-stopped

volumes:
  commento_pg:

Обратите внимание на порт — публиковать его наружу не нужно, доступ в интернет даёт nginx поверх. Если общая структура docker-compose для вас в новинку или падают другие контейнеры рядом, разбор смежных проблем есть в статье про docker-compose для продакшена.

Виджет комментариев не отображается на сайте

Контейнер работает, curl http://127.0.0.1:8080 отвечает, а на странице сайта под статьёй пусто вместо формы комментариев. Откройте консоль браузера (F12) — там почти всегда одна из трёх ошибок.

Первая — виджет всё ещё грузится с cdn.commento.io, а не с вашего домена. Многие копируют сниппет из старой документации Commento, где путь ведёт на облачный SaaS:

<!-- неверно для self-hosted -->
<script src="https://cdn.commento.io/js/commento.js" data-timestamp="ISO_TIMESTAMP" defer></script>

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

<div id="commento"></div>
<script src="https://comments.example.com/js/commento.js" data-timestamp="ISO_TIMESTAMP" defer></script>

Вторая частая причина — несовпадение COMMENTO_ORIGIN с реальным адресом, по которому открыт Commento. Если в переменной указано http://comments.example.com, а сайт открывается по https://, браузер блокирует запросы виджета как mixed content, а сам Commento может отклонять запросы как пришедшие не с того origin. Значение COMMENTO_ORIGIN должно быть ровно тем URL, который видит браузер — с протоколом, доменом и без завершающего слэша.

Третья — блокировщики рекламы и приватности (uBlock Origin, Brave Shields) иногда режут скрипты с именем commento.js по эвристике «похоже на трекер комментариев». Это ирония, учитывая, что Commento создавался как раз против трекинга, но фильтры такие фильтры. Проверьте страницу в режиме инкогнито без расширений, прежде чем тратить время на сервер.

Комментарии не сохраняются, ошибка при отправке

Форма показывается, но при отправке комментария появляется ошибка вида unknown-error или not-authorized, а в логах контейнера что-то про базу данных.

docker compose logs commento | grep -i error

Если там permission denied for schema public — роль commento создана, но не является владельцем базы или у неё нет прав на схему. Это особенно часто на PostgreSQL 15+, где права на public больше не выдаются всем ролям по умолчанию:

docker compose exec db psql -U postgres -d commento -c "GRANT ALL ON SCHEMA public TO commento;"
docker compose exec db psql -U postgres -d commento -c "ALTER DATABASE commento OWNER TO commento;"

Если ошибка про relation does not exist — миграции при первом старте не отработали. Обычно это следствие того, что контейнер Commento успел один раз запуститься до готовности базы (см. раздел про healthcheck выше), словил ошибку подключения и больше не пытался прогнать миграции повторно. Проще всего — остановить оба контейнера, убедиться, что база пустая или удалить volume, и поднять заново по порядку.

docker compose down
docker volume rm <project>_commento_pg
docker compose up -d

Учтите: это удалит все данные в базе, если она не пустая — на живом сервере с реальными комментариями сначала снимите бэкап через pg_dump. Общие принципы диагностики PostgreSQL — connection refused, нехватка прав, разросшийся диск — разобраны в статье про частые ошибки PostgreSQL на сервере, пригодится, если проблема глубже, чем сам Commento.

Не приходит письмо подтверждения и не работает модерация

Пользователь регистрируется, чтобы оставить комментарий, но письмо с подтверждением не приходит — и он навсегда застревает в статусе неподтверждённого аккаунта. То же самое с уведомлениями о новых комментариях для модератора.

Commento сам почту не отправляет без настроенного SMTP. Переменные окружения:

COMMENTO_SMTP_HOST=smtp.example.com
COMMENTO_SMTP_PORT=587
COMMENTO_SMTP_USERNAME=commento@example.com
COMMENTO_SMTP_PASSWORD=пароль_приложения
COMMENTO_SMTP_FROM_ADDRESS=commento@example.com

Если эти переменные не заданы вовсе, Commento в некоторых сборках тихо отключает отправку писем — ни ошибки в логах, ни явного предупреждения в интерфейсе, просто письма не уходят. Первым делом проверьте, что переменные действительно попали в контейнер:

docker compose exec commento env | grep SMTP

Дальше — стандартная диагностика SMTP: порт 587 может быть заблокирован у хостера (актуально для некоторых зарубежных провайдеров, но не для серверов, где 587/25 открыты явно), логин отличается от адреса FROM, или почтовый провайдer требует пароль приложения, а не основной пароль аккаунта. Если проблема не в самом Commento, а в том, что письма вообще не уходят с сервера — это отдельная и более общая тема, разобранная в статье не отправляется почта с сервера.

Как временный обход, пока SMTP не настроен: подтвердите пользователя вручную прямо в базе — это неидеальное решение для одного администратора, но рабочее для разработки:

docker compose exec db psql -U commento -d commento -c \
  "UPDATE commenters SET emailNotificationPolicy='pending-moderation' WHERE email='вы@example.com';"

Точные названия столбцов зависят от версии образа — свежую схему проще всего посмотреть командой \d commenters в psql, прежде чем писать UPDATE руками.

Ошибки за nginx: mixed content, 502, редиректы

Commento почти всегда стоит за nginx как reverse proxy на отдельном поддомене. Рабочий конфиг:

server {
    listen 443 ssl http2;
    server_name comments.example.com;

    ssl_certificate     /etc/letsencrypt/live/comments.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/comments.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Заголовок X-Forwarded-For важен не только для логов: Commento использует IP клиента для антиспам-эвристик, и без него все комментарии будут выглядеть как пришедшие с одного адреса — вашего сервера.

Если nginx отдаёт 502 Bad Gateway — контейнер либо не поднят, либо слушает не тот порт/адрес, либо упал под нагрузкой. Порядок диагностики (проверить процесс, проверить порт, проверить логи) общий для любого reverse proxy и подробно разобран в статье про ошибку 502 Bad Gateway в nginx. Отдельно проверьте, что домен comments.example.com открывается по HTTPS и сертификат не просрочен — иначе браузер заблокирует загрузку виджета как небезопасный ресурс, даже если основной сайт открыт по HTTPS. За автопродление сертификатов и типичные грабли certbot отвечает статья certbot или acme.sh — что выбрать для сервера.

Стоит ли использовать Commento в 2026 году

Здесь стоит сказать прямо: активная разработка открытого Commento практически остановилась несколько лет назад — автор проекта сосредоточился на других задачах, а сообщество продолжило развитие под именем Comentario (форк с той же идеей — комментарии без слежки, self-hosted, на Go с PostgreSQL). Если вы разворачиваете комментарии с нуля в конце 2026 года, разумно сразу посмотреть в сторону Comentario: там активнее чинят баги, обновляют зависимости и добавляют функции вроде SSO и модерации через веб-интерфейс, которых в оригинальном Commento не хватает.

Сам Commento при этом не «сломан» — миллионы строк комментариев на существующих сайтах продолжают работать без нареканий, база стабильна, а протокол виджета простой. Если у вас уже развёрнут Commento и он работает — ошибки из этой статьи с высокой вероятностью решат проблему без миграции. Но для нового проекта закладывать долгосрочную ставку на инструмент без активной поддержки — риск: следующая уязвимость в зависимостях Go или PostgreSQL-драйвере может не дождаться патча. Миграция между Commento и Comentario относительно прямолинейна, поскольку оба используют похожую схему данных и экспорт в JSON — но сверяйте её с актуальной документацией конкретной версии перед переносом, а не по памяти из старых статей.

Что не зависит от выбора движка — так это то, на чём он крутится. Лёгкому Go-бинарнику с PostgreSQL достаточно скромного VPS, но именно стабильность сети и диска определяют, будет ли форма комментариев открываться мгновенно или подвисать у части читателей. В MAATRIX можно арендовать VPS в России, США или Великобритании под такие сервисы и платить картой российского банка, по СБП, криптовалютой или токеном MAAT — без иностранной карты и подтверждений, которые обычно требует зарубежный хостинг.

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