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

MAATRIX

FreshRSS — один из немногих self-hosted сервисов, который реально работает «поставил и забыл»: лёгкий, без Node.js-зоопарка, разумная замена Google Reader. Но именно из-за этой простоты, когда что-то ломается, разбираться приходится с нуля — документация местами скупая, а ошибки в логах не всегда очевидны. Ниже — конкретные проблемы, с которыми сталкиваются на боевых VPS, и что с ними делать.

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

Ставите FreshRSS, открываете /i/ для установки — и вместо мастера белая страница или голая «500 Internal Server Error» без деталей. Первым делом включите вывод ошибок PHP и посмотрите лог PHP-FPM:

tail -50 /var/log/php8.3-fpm.log
tail -50 /var/log/nginx/error.log

В девяти случаях из десяти причина — не хватает PHP-расширения. FreshRSS требует конкретный набор, и если ставили «минимальный» PHP, чего-то обязательно нет:

sudo apt install php8.3-curl php8.3-xml php8.3-intl php8.3-gd \
  php8.3-mbstring php8.3-sqlite3 php8.3-zip
sudo systemctl restart php8.3-fpm

Если планируете MySQL или PostgreSQL вместо SQLite — добавьте php8.3-mysql или php8.3-pgsql соответственно, иначе на шаге выбора СУБД мастер установки просто не покажет нужный вариант в списке.

Отдельная причина белого экрана — memory_limit в PHP выставлен слишком низко (64M на некоторых образах по умолчанию). FreshRSS при обновлении лент и импорте OPML легко упирается в этот лимит. Поднимите до 256M в /etc/php/8.3/fpm/php.ini и перезапустите php-fpm.

FreshRSS не обновляет ленты автоматически

Веб-интерфейс открывается, ленты добавляются, но новые статьи появляются только если зайти и нажать «Актуализировать» руками. Это значит, что фоновое обновление не настроено — FreshRSS сам по себе не «живёт» в фоне, ему нужен внешний планировщик.

Правильный способ — cron-задача от имени пользователя веб-сервера (обычно www-data), которая дёргает встроенный скрипт актуализации:

sudo crontab -u www-data -e

И добавить строку:

*/15 * * * * /usr/bin/php /var/www/FreshRSS/app/actualize_script.php > /dev/null 2>&1

Частая ошибка — прописать команду в crontab обычного пользователя (root или своего), а не www-data: скрипт тогда либо падает по правам на каталог data/, либо создаёт файлы с неправильным владельцем, из-за чего веб-интерфейс потом не может их прочитать. Проверить, что задача реально выполняется, можно логом:

grep CRON /var/log/syslog | grep actualize

Если строк нет вообще — cron демон не видит задачу (опечатка в пути к PHP или неправильный синтаксис). Если строки есть, но ленты всё равно не обновляются, зайдите в админку FreshRSS: Настройки → Обновление ленты — там должен стоять режим «Через планировщик (cron)», а не «Ручной» или «При посещении сайта». Про сами cron-задачи на сервере — отдельный разбор в статье про частые ошибки cron, если проблема шире одного FreshRSS.

Impossible to connect при добавлении ленты

Пытаетесь добавить конкретный источник — FreshRSS пишет «Impossible to connect to feed (RSSFile HTTP...)» или похожую ошибку сети, хотя лента открывается в браузере без проблем. Причины делятся на три группы.

Первая — сервер не может достучаться до источника из-за исходящего файрвола или блокировки на уровне хостера. Проверьте вручную с сервера:

curl -I -v https://example.com/rss.xml

Вторая — источник отдаёт устаревший или самоподписанный TLS-сертификат, а curl на сервере строг к проверке цепочки. Временно (для диагностики, не для продакшена) можно проверить гипотезу флагом -k, но постоянным решением это быть не должно — если проблема в сертификате именно вашего сайта на другом домене, разберитесь с самим сертификатом, а не отключайте проверку.

Третья, самая частая на практике — источник блокирует запросы без нормального User-Agent или требует куки/JS-рендеринг (Cloudflare-защита, антибот). FreshRSS такие ленты не потянет в принципе — это ограничение самого источника, а не бага. Проверить, отдаёт ли сайт вообще валидный RSS без браузерных танцев: curl -A "Mozilla/5.0" https://example.com/feed.

Permission denied при записи в data или config

После установки или переноса на новый сервер FreshRSS ругается на невозможность записать в ./data/ или ./data/users/_/config.php. Классическая проблема прав после git clone или распаковки архива не от имени веб-сервера:

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

Если используете Docker-образ FreshRSS, ситуация похожая, но лечится через volume: убедитесь, что примонтированный каталог на хосте принадлежит тому же UID, что и процесс внутри контейнера (по умолчанию часто 1000). Несовпадение UID хоста и контейнера — топ-причина «permission denied» именно в контейнерных установках, и права нужно поправить снаружи, а не пытаться chmod 777 изнутри контейнера как временный костыль, который потом забывают убрать.

Отдельно проверьте SELinux, если сервер на AlmaLinux или CentOS — там даже при правильном chown доступ может блокироваться политикой безопасности, и в логе PHP будет обычный «permission denied» без намёка на SELinux. Диагностика: sudo ausearch -m avc -ts recent, и если находки есть — sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/FreshRSS/data(/.*)?" с последующим restorecon -R.

SQLite заблокирована при большом числе лент

На старте почти все ставят FreshRSS с базой SQLite — это правильный выбор для личного использования на 20-50 лент. Но когда лент становится несколько сотен, а обновление идёт параллельно с чтением через веб-интерфейс, начинают проскакивать ошибки database is locked.

SQLite не рассчитана на конкурентную запись — это не баг FreshRSS, а фундаментальное свойство файловой базы. Если ошибка появляется регулярно, а не разово при совпадении cron и активного чтения, пора переезжать на MySQL/MariaDB или PostgreSQL. Миграция делается встроенной CLI-командой:

cd /var/www/FreshRSS
php ./cli/create-user.php --no-config --help

Практичнее не мигрировать данные вручную, а сразу поставить второй профиль подключения к MySQL через мастер установки (/i/) и перенести подписки через экспорт/импорт OPML — это надёжнее, чем ковырять базу напрямую. Про сам MySQL на сервере, если после переезда начнутся отдельные проблемы с самой СУБД, — смотрите разбор частых ошибок MySQL.

Мобильные приложения не подключаются через Google Reader API

FreshRSS умеет отдавать данные по протоколу Google Reader API — это то, что нужно, чтобы читать ленты из привычных мобильных клиентов (например, приложений, поддерживающих Fever/GReader API). В самом FreshRSS его нужно явно включить в профиле пользователя, и отдельно задать API-пароль (он не совпадает с паролем от веб-интерфейса) — это первая и самая частая причина, по которой клиент пишет «неверный логин или пароль», хотя в браузере вы заходите нормально.

Вторая частая причина — реверс-прокси перед FreshRSS обрезает или неправильно передаёт заголовки авторизации. Если FreshRSS стоит за nginx, в конфиге обязательно должны быть проброшены стандартные заголовки:

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-Proto FreshRSS иногда генерирует ссылки на API с неправильной схемой (http вместо https), и клиент, ожидающий строго HTTPS, просто отваливается по TLS. Если конфиг реверс-прокси кажется подозрительным в целом, есть отдельный разбор типовых проблем — nginx как reverse proxy. Если вместо самодельного nginx вы используете обратный прокси с автоматическим SSL, полезно свериться со статьёй про ошибки Let's Encrypt на сервере — сертификат для домена FreshRSS ничем не отличается от любого другого.

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