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

MAATRIX

На ноутбуке AnythingLLM запускается двойным щелчком, а на сервере ведёт себя иначе: контейнер уходит в бесконечный рестарт, чат отвечает красной плашкой «Could not respond to message», выбранная модель откатывается после каждого docker compose up, а PDF не загружается вовсе. Эти ошибки AnythingLLM повторяются от установки к установке и опознаются по одной строке в логе. Ниже — шесть сценариев: симптом, причина, команда, правка.

С чего начинать разбор: три процесса и один каталог

AnythingLLM выглядит как одно приложение, но внутри контейнера их три, и поломка живёт в конкретном. Сервер — Node/Express на порту 3001: отдаёт фронтенд, держит настройки и ходит к провайдеру модели. Коллектор — процесс на 8888, он парсит PDF, DOCX и веб-страницы; наружу его не публикуют. Состояние целиком лежит в /app/server/storage: база anythingllm.db, векторы lancedb/, разобранные документы documents/, кэш vector-cache/ и файл .env.

Симптом указывает на слой почти однозначно.

Первичная диагностика — четыре команды:

docker ps --filter name=anythingllm --format '{{.Status}}\t{{.Ports}}'
docker logs --tail 200 anythingllm 2>&1 | grep -iE 'error|eacces|prisma|failed'
curl -s http://127.0.0.1:3001/api/ping
docker exec anythingllm ls -la /app/server/storage

/api/ping авторизации не требует и отвечает {"online":true}. Ответ есть — сервер поднялся, причина дальше по цепочке; молчит при статусе Restarting — вам в следующий раздел. И помните: красная плашка в чате — ответ сервера, а не модели. Есть в ней fetch failed или ECONNREFUSED — до LLM запрос не дошёл, правки промпта бесполезны.

Контейнер уходит в рестарт: storage, .env и SQLite

Поломка первого дня: интерфейс не открывается, а в логе — одна из двух строк.

Error: EACCES: permission denied, open '/app/server/storage/anythingllm.db'
Error: EISDIR: illegal operation on a directory, read

EACCES. Процесс в контейнере работает от пользователя с UID 1000, а каталог storage создан на хосте под root — записи нет, и Prisma не открывает SQLite-файл. Лечится сменой владельца, а не chmod 777:

sudo chown -R 1000:1000 /opt/anythingllm/storage
sudo find /opt/anythingllm/storage -type d -exec chmod 755 {} \;

EISDIR. Классика Docker: если пробросить файл .env, которого на хосте нет, демон создаст на его месте каталог, и приложение прочитает директорию как файл. Проверка — ls -la /opt/anythingllm/storage/.env: видите drwxr-xr-x вместо -rw- — удалите каталог, создайте файл через touch, перезапустите контейнер.

Тома нет вовсе. Тогда storage жил внутри контейнера и умер вместе с ним при docker rm: рабочие пространства, ключи и векторы не вернуть. Проверьте монтирование и STORAGE_DIR:

docker inspect -f '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' anythingllm
docker exec anythingllm env | grep -E 'STORAGE_DIR|SERVER_PORT|JWT_SECRET'

База заблокирована. Строка SQLITE_BUSY: database is locked почти всегда означает, что storage вынесли на NFS, CIFS или синхронизируемую папку: SQLite полагается на файловые блокировки, которых там нет. Каталог должен лежать на локальном NVMe, а бэкап делается снимком остановленного контейнера:

docker compose stop && tar -czf /root/allm-$(date +%F).tgz -C /opt/anythingllm storage && docker compose start

Отдельно: JWT_SECRET должен быть не короче 12 символов, SIG_KEY и SIG_SALT — не короче 32, иначе ломается старт или авторизация. Смена JWT_SECRET разлогинивает всех.

«Could not respond to message»: запрос до модели не дошёл

Плашка вида Could not respond to message. fetch failed значит одно: сервер отправил запрос провайдеру и не получил ответа. Причин четыре.

Контейнер и localhost. Самая массовая: Ollama работает на хосте, а в настройках стоит http://127.0.0.1:11434. Внутри контейнера это адрес самого контейнера, в логе — connect ECONNREFUSED 127.0.0.1:11434. Нужен адрес хоста, и Ollama обязан слушать не только loopback:

sudo systemctl edit ollama.service    # [Service] Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama
sudo ufw allow from 172.17.0.0/16 to any port 11434 proto tcp
docker exec anythingllm curl -s http://host.docker.internal:11434/api/tags | head -c 300

В docker run нужен --add-host=host.docker.internal:host-gateway, в Compose — extra_hosts: ["host.docker.internal:host-gateway"]; альтернатива — адрес шлюза 172.17.0.1. Порт 11434 наружу не публикуют: у Ollama нет авторизации.

Имя модели не совпадает. Ollama отвечает 404 и строкой model "llama3.1" not found, try pulling it first. Имя обязано совпадать с выводом ollama list посимвольно, вместе с тегом: qwen2.5:7b-instruct-q4_K_M и qwen2.5:7b — разные модели, а llama3.1 разворачивается в llama3.1:latest, которого может не быть.

Внешний провайдер отказал. С OpenAI и Anthropic текст плашки приходит от них: 401 — неверный ключ, 403 unsupported_country_region_territory — не тот регион исходящего IP, 429 insufficient_quota — пустой баланс, а не рейт-лимит. Перевыпуск ключа лечит только первое.

Первый запрос после простоя. Ollama выгружает веса через пять минут бездействия, и следующий запрос ждёт чтения модели с диска: 7B в Q4 — порядка 4,5 ГБ. Повторов AnythingLLM не делает: одна ошибка — сообщение потеряно. Лечится Environment="OLLAMA_KEEP_ALIVE=24h" в том же drop-in.

Настройки не сохраняются после перезапуска

Симптом звучит как мистика: в интерфейсе сменили модель или эмбеддер, всё заработало, а после docker compose up -d значение вернулось к прежнему. Ошибок в логе нет никаких.

Причина — два источника правды. Настройки из веб-интерфейса AnythingLLM пишет в /app/server/storage/.env, но переменные из блока environment: в Compose (и флаги -e в docker run) попадают в окружение процесса раньше и при старте выигрывают. В файле лежит новое значение, а работает старое. Сравните два вывода:

docker exec anythingllm cat /app/server/storage/.env | grep -vE '^#|^
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть AnythingLLM
«Could not respond to message»: запрос до модели не дошёл
Плашка вида Could not respond to message. fetch failed значит одно: сервер отправил запрос провайдеру и не получил ответа. Причин четыре.
Контейнер и localhost. Самая массовая: Ollama работает на хосте, а в настройках стоит http://127.0.0.1:11434. Внутри контейнера это адрес самого контейнера, в логе — connect ECONNREFUSED 127.0.0.1:11434. Нужен адрес хоста, и Ollama обязан слушать не только loopback:
sudo systemctl edit ollama.service    # [Service] Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama
sudo ufw allow from 172.17.0.0/16 to any port 11434 proto tcp
docker exec anythingllm curl -s http://host.docker.internal:11434/api/tags | head -c 300
В docker run нужен --add-host=host.docker.internal:host-gateway, в Compose — extra_hosts: ["host.docker.internal:host-gateway"]; альтернатива — адрес шлюза 172.17.0.1. Порт 11434 наружу не публикуют: у Ollama нет авторизации.
Имя модели не совпадает. Ollama отвечает 404 и строкой model "llama3.1" not found, try pulling it first. Имя обязано совпадать с выводом ollama list посимвольно, вместе с тегом: qwen2.5:7b-instruct-q4_K_M и qwen2.5:7b — разные модели, а llama3.1 разворачивается в llama3.1:latest, которого может не быть.
Внешний провайдер отказал. С OpenAI и Anthropic текст плашки приходит от них: 401 — неверный ключ, 403 unsupported_country_region_territory — не тот регион исходящего IP, 429 insufficient_quota — пустой баланс, а не рейт-лимит. Перевыпуск ключа лечит только первое.
Первый запрос после простоя. Ollama выгружает веса через пять минут бездействия, и следующий запрос ждёт чтения модели с диска: 7B в Q4 — порядка 4,5 ГБ. Повторов AnythingLLM не делает: одна ошибка — сообщение потеряно. Лечится Environment="OLLAMA_KEEP_ALIVE=24h" в том же drop-in.
Настройки не сохраняются после перезапуска
Симптом звучит как мистика: в интерфейсе сменили модель или эмбеддер, всё заработало, а после docker compose up -d значение вернулось к прежнему. Ошибок в логе нет никаких.
Причина — два источника правды. Настройки из веб-интерфейса AnythingLLM пишет в /app/server/storage/.env, но переменные из блока environment: в Compose (и флаги -e в docker run) попадают в окружение процесса раньше и при старте выигрывают. В файле лежит новое значение, а работает старое. Сравните два вывода:
docker exec anythingllm cat /app/server/storage/.env | grep -vE '^#|^$'
docker exec anythingllm env | grep -E 'LLM_PROVIDER|EMBEDDING|VECTOR_DB|OLLAMA|OPEN_AI'
Расходятся — причина найдена. Выбирайте один источник:
Инфраструктура в Compose, модели в интерфейсе. В environment: остаются только STORAGE_DIR, SERVER_PORT, JWT_SECRET, SIG_KEY, SIG_SALT, DISABLE_TELEMETRY=true. Провайдер и эмбеддер тогда переживают перезапуск.
Всё в Compose. Годится для воспроизводимого развёртывания из репозитория, но менять эти поля в UI бессмысленно — они откатятся.
У путаницы есть продолжение: подменив эмбеддер, вы оставляете старые документы с векторами прежней размерности. Встроенный даёт 384 измерения, text-embedding-3-small — 1536; Chroma ответит Embedding dimension 384 does not match collection dimensionality 1536, а LanceDB промолчит и перестанет находить нужное. Смена эмбеддера требует переиндексации — она разобрана в статье про то, почему AnythingLLM не индексирует документы.
Nginx перед AnythingLLM: 413, обрыв стрима и мёртвые агенты
AnythingLLM не умеет ни TLS, ни сетевой авторизации, поэтому наружу его выставляют через Nginx. Настройки по умолчанию ломают четыре вещи.
server {
    listen 443 ssl;
    server_name llm.example.com;

    client_max_body_size 512m;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}
413 при загрузке документа. client_max_body_size по умолчанию равен 1 МБ, и серьёзный PDF отлетает: в браузере молчаливый сбой, в /var/log/nginx/access.log — код 413. Лимит ставьте осознанно, он же ограничивает случайного посетителя.
Ответ приходит целиком в конце или обрывается на минуте. proxy_buffering on копит поток SSE в буфере, и эффект печатной машинки пропадает. proxy_read_timeout по умолчанию 60 секунд — длинная генерация не доживает, в error.log появляется upstream timed out (110: Connection timed out) while reading upstream.
Агент не стартует. Режим @agent работает по WebSocket, и без апгрейда соединения в консоли браузера видно WebSocket connection to 'wss://llm.example.com/api/agent-invocation/...' failed. Переменную $connection_upgrade объявляют в блоке http: map $http_upgrade $connection_upgrade { default upgrade; '' close; }.
502 Bad Gateway. Строка connect() failed (111: Connection refused) while connecting to upstream означает, что за прокси никого нет: контейнер лежит или публикует другой порт — смотрите ss -tlnp | grep 3001. Публиковать порт правильно как 127.0.0.1:3001:3001: иначе Docker пробьёт ufw своими цепочками в iptables, и интерфейс окажется открыт всему интернету.
Честное ограничение: фронтенд собран под корень домена. На подпути вроде /llm/ без пересборки он не заработает — страница откроется белой, ассеты уйдут в 404. Берите отдельный поддомен.
Что всплывает на второй неделе: память, диск, обновления
Первые дни всё работает, а потом сервис падает по ночам. Три технические причины и одна организационная.
Память. Проверяется командой docker inspect anythingllm --format '{{.State.OOMKilled}}': true — контейнер убит ядром, то же видно в dmesg -T | grep -i 'killed process'. Бывает мягче: процесс упирается в предел кучи Node и пишет FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory — обычно при разборе крупного документа. Разработчик называет минимумом около 2 ГБ RAM и двух ядер, но это минимум для интерфейса поверх внешнего API. Расчёт под конкретные модели — в статье про то, сколько RAM нужно для AnythingLLM.
Диск. Каталог storage растёт быстрее ожиданий: рядом с оригиналом живут разобранный текст в documents/, векторы в vector-cache/ и индекс в lancedb/.
du -sh /opt/anythingllm/storage/* | sort -h
docker inspect --format '{{.LogPath}}' anythingllm | xargs du -h
Вторая команда часто находит json-лог на несколько гигабайт: Docker его не ротирует. Лечится драйвером логов с max-size: "50m" и max-file: "3" в Compose.
Обновление. Тег :latest означает, что очередной docker compose pull может принести миграцию схемы Prisma — она идёт при старте и назад не откатывается. Безопасный порядок: остановить, забрать архив storage, потом тянуть образ; для боевой установки зафиксируйте digest.
Потерянный пароль администратора. В многопользовательском режиме коды восстановления показываются ровно один раз — при создании учётной записи. Без них остаётся править таблицу users в anythingllm.db руками, на живой базе. Сохраните коды сразу.
Какой сервер брать под AnythingLLM в MAATRIX
Требования упираются в одно: где считается модель. Сам AnythingLLM — это Node-приложение, разбор документов и векторный поиск; тяжёлые вычисления появляются, только если инференс живёт на том же сервере.
Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Хватает, когда модель внешняя — OpenAI, Anthropic, OpenRouter или свой шлюз, — а AnythingLLM отвечает за интерфейс, документы и RAG. Формальные 2 ГБ из документации брать не советую: сервер, коллектор и встроенный эмбеддер укладывают такую машину на первой же партии PDF.
Комфортный вариант: 4 vCPU, 8 ГБ RAM, 80–120 ГБ NVMe. Команда до полутора десятков человек, библиотека на тысячи страниц, спокойная переиндексация и место под Qdrant или Chroma в соседнем контейнере. Диск здесь важнее процессора.
Локальная модель на том же сервере — отдельная история: прибавляются веса. Под 7B в Q4 закладывайте 16 ГБ RAM, под модели крупнее нужен GPU. Скорость генерации на CPU честно низкая: если ответы нужны в реальном времени, дешевле оставить AnythingLLM на компактном VPS, а инференс вынести на GPU-сервер.
Локация — Великобритания, Лондон. С британского адреса OpenAI и Anthropic отвечают штатно, без региональных 403, которые ловит российский IP. Пинг из Москвы до Лондона — несколько десятков миллисекунд: для интерфейса, где ответ и так идёт секундами, это незаметно, а европейцам задержка минимальна. Третий довод — юрисдикция: корпоративная база документов в британском ЦОД лежит в привычном европейским контрагентам правовом поле. Если в неё попадают персональные данные российских граждан и вы работаете по 152-ФЗ, берите RU, но внешние ИИ-API оттуда недоступны — модель придётся держать локально. US — когда нужен именно американский адрес.
Приложение из каталога apps.maatrix.io ставится автоматически при заказе сервера — вводить команды не нужно, работает и на Ubuntu, и на Debian. Адрес панели и ключи появятся в личном кабинете, раздел «Доступ»: остаётся войти, подключить провайдера модели и загрузить первые документы. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Как выбирается площадка, разобрано в обзоре VPS в Великобритании для доступа к нейросетям.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть AnythingLLM
Нужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Изображения и ВидеоАудио и звукИИ MAAT — Собеседник
#x27;
docker exec anythingllm env | grep -E 'LLM_PROVIDER|EMBEDDING|VECTOR_DB|OLLAMA|OPEN_AI'

Расходятся — причина найдена. Выбирайте один источник:

• Инфраструктура в Compose, модели в интерфейсе. В environment: остаются только STORAGE_DIR, SERVER_PORT, JWT_SECRET, SIG_KEY, SIG_SALT, DISABLE_TELEMETRY=true. Провайдер и эмбеддер тогда переживают перезапуск.
• Всё в Compose. Годится для воспроизводимого развёртывания из репозитория, но менять эти поля в UI бессмысленно — они откатятся.

У путаницы есть продолжение: подменив эмбеддер, вы оставляете старые документы с векторами прежней размерности. Встроенный даёт 384 измерения, text-embedding-3-small — 1536; Chroma ответит Embedding dimension 384 does not match collection dimensionality 1536, а LanceDB промолчит и перестанет находить нужное. Смена эмбеддера требует переиндексации — она разобрана в статье про то, почему AnythingLLM не индексирует документы.

Nginx перед AnythingLLM: 413, обрыв стрима и мёртвые агенты

AnythingLLM не умеет ни TLS, ни сетевой авторизации, поэтому наружу его выставляют через Nginx. Настройки по умолчанию ломают четыре вещи.

server {
    listen 443 ssl;
    server_name llm.example.com;

    client_max_body_size 512m;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

413 при загрузке документа. client_max_body_size по умолчанию равен 1 МБ, и серьёзный PDF отлетает: в браузере молчаливый сбой, в /var/log/nginx/access.log — код 413. Лимит ставьте осознанно, он же ограничивает случайного посетителя.

Ответ приходит целиком в конце или обрывается на минуте. proxy_buffering on копит поток SSE в буфере, и эффект печатной машинки пропадает. proxy_read_timeout по умолчанию 60 секунд — длинная генерация не доживает, в error.log появляется upstream timed out (110: Connection timed out) while reading upstream.

Агент не стартует. Режим @agent работает по WebSocket, и без апгрейда соединения в консоли браузера видно WebSocket connection to 'wss://llm.example.com/api/agent-invocation/...' failed. Переменную $connection_upgrade объявляют в блоке http: map $http_upgrade $connection_upgrade { default upgrade; '' close; }.

502 Bad Gateway. Строка connect() failed (111: Connection refused) while connecting to upstream означает, что за прокси никого нет: контейнер лежит или публикует другой порт — смотрите ss -tlnp | grep 3001. Публиковать порт правильно как 127.0.0.1:3001:3001: иначе Docker пробьёт ufw своими цепочками в iptables, и интерфейс окажется открыт всему интернету.

Честное ограничение: фронтенд собран под корень домена. На подпути вроде /llm/ без пересборки он не заработает — страница откроется белой, ассеты уйдут в 404. Берите отдельный поддомен.

Что всплывает на второй неделе: память, диск, обновления

Первые дни всё работает, а потом сервис падает по ночам. Три технические причины и одна организационная.

Память. Проверяется командой docker inspect anythingllm --format '{{.State.OOMKilled}}': true — контейнер убит ядром, то же видно в dmesg -T | grep -i 'killed process'. Бывает мягче: процесс упирается в предел кучи Node и пишет FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory — обычно при разборе крупного документа. Разработчик называет минимумом около 2 ГБ RAM и двух ядер, но это минимум для интерфейса поверх внешнего API. Расчёт под конкретные модели — в статье про то, сколько RAM нужно для AnythingLLM.

Диск. Каталог storage растёт быстрее ожиданий: рядом с оригиналом живут разобранный текст в documents/, векторы в vector-cache/ и индекс в lancedb/.

du -sh /opt/anythingllm/storage/* | sort -h
docker inspect --format '{{.LogPath}}' anythingllm | xargs du -h

Вторая команда часто находит json-лог на несколько гигабайт: Docker его не ротирует. Лечится драйвером логов с max-size: "50m" и max-file: "3" в Compose.

Обновление. Тег :latest означает, что очередной docker compose pull может принести миграцию схемы Prisma — она идёт при старте и назад не откатывается. Безопасный порядок: остановить, забрать архив storage, потом тянуть образ; для боевой установки зафиксируйте digest.

Потерянный пароль администратора. В многопользовательском режиме коды восстановления показываются ровно один раз — при создании учётной записи. Без них остаётся править таблицу users в anythingllm.db руками, на живой базе. Сохраните коды сразу.

Какой сервер брать под AnythingLLM в MAATRIX

Требования упираются в одно: где считается модель. Сам AnythingLLM — это Node-приложение, разбор документов и векторный поиск; тяжёлые вычисления появляются, только если инференс живёт на том же сервере.

Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Хватает, когда модель внешняя — OpenAI, Anthropic, OpenRouter или свой шлюз, — а AnythingLLM отвечает за интерфейс, документы и RAG. Формальные 2 ГБ из документации брать не советую: сервер, коллектор и встроенный эмбеддер укладывают такую машину на первой же партии PDF.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 80–120 ГБ NVMe. Команда до полутора десятков человек, библиотека на тысячи страниц, спокойная переиндексация и место под Qdrant или Chroma в соседнем контейнере. Диск здесь важнее процессора.

Локальная модель на том же сервере — отдельная история: прибавляются веса. Под 7B в Q4 закладывайте 16 ГБ RAM, под модели крупнее нужен GPU. Скорость генерации на CPU честно низкая: если ответы нужны в реальном времени, дешевле оставить AnythingLLM на компактном VPS, а инференс вынести на GPU-сервер.

Локация — Великобритания, Лондон. С британского адреса OpenAI и Anthropic отвечают штатно, без региональных 403, которые ловит российский IP. Пинг из Москвы до Лондона — несколько десятков миллисекунд: для интерфейса, где ответ и так идёт секундами, это незаметно, а европейцам задержка минимальна. Третий довод — юрисдикция: корпоративная база документов в британском ЦОД лежит в привычном европейским контрагентам правовом поле. Если в неё попадают персональные данные российских граждан и вы работаете по 152-ФЗ, берите RU, но внешние ИИ-API оттуда недоступны — модель придётся держать локально. US — когда нужен именно американский адрес.

Приложение из каталога apps.maatrix.io ставится автоматически при заказе сервера — вводить команды не нужно, работает и на Ubuntu, и на Debian. Адрес панели и ключи появятся в личном кабинете, раздел «Доступ»: остаётся войти, подключить провайдера модели и загрузить первые документы. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Как выбирается площадка, разобрано в обзоре VPS в Великобритании для доступа к нейросетям.

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