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

MAATRIX

Вы гуглите «perplexica ошибки», открываете репозиторий по старой ссылке — а там другое название, другой Docker-образ и ни следа config.toml из старых гайдов. С 9 марта 2026 года проект называется Vane — и это первая, самая тихая причина «ничего не работает». Дальше настоящие поломки: поиск крутится и не отвечает, интерфейс жалуется на «не настроен ни один провайдер», в консоли браузера — TypeError без понятной строчки. Разберём по слоям: что изменилось при переименовании, где рвётся связка с SearXNG и моделями, и какой сервер под это разумно брать.

Быстрая диагностика ошибок Perplexica: с какого слоя начинать

«Perplexica не работает» — слишком общая жалоба сразу на четыре слоя, и каждый лечится по-своему. Симптом обычно подсказывает, с чего начать.

Три команды закрывают половину случаев:

docker ps --filter name=vane --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'
docker logs --tail=80 vane
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/api/providers

Первая показывает образ — itzcrazykns1337/vane или ещё старый itzcrazykns1337/perplexica: это объясняет половину расхождений с чужими скриншотами. Вторая — источник правды: приложение и встроенный поиск пишут в один поток вывода, там же видна трассировка при падении на старте. Третья — смоук-тест: 200 с телом значит, что сервер жив и хотя бы один провайдер виден бэкенду; 000 или Connection refused — дело в сети и порте 3000, а не в ключах.

Perplexica стал Vane 9 марта 2026: почему у вас другой образ и нет config.toml

Коммит feat(app): rename to 'vane' вошёл в master 9 марта 2026 года. Ещё релиз v1.12.1 от 31 декабря 2025-го ссылался в changelog на github.com/ItzCrazyKns/Perplexica; первым релизом под новым именем стал v1.12.2 от 10 апреля 2026-го. Автор объясняет переезд уходом от названия, слишком похожего на коммерческий Perplexity, и сдвигом от статуса «клона» к самостоятельному продукту. Хостинг perplexica.io остался отдельным платным сервисом под старым именем — к вашему серверу отношения не имеет.

Для вашего сервера это три конкретные вещи:

• Docker-образ. Было itzcrazykns1337/perplexica, стало itzcrazykns1337/vane (и vane:slim-latest — без встроенного поиска).
• Путь данных. База и файлы пишутся в /home/vane/data, том называется vane-data. Если контейнер и том у вас с прошлого раза именовались на старый лад, команда -v vane-data:/home/vane/data --name vane их не подхватит и создаст пустой том рядом — настройки придётся вводить заново. Сверьте, что вообще осталось: docker volume ls.
• Конфиг-файла больше нет. config.toml с ключами в [MODELS.OPENAI] и адресом поиска в [API_ENDPOINTS] из репозитория убрали — sample.config.toml отдаёт 404. Всё вводится один раз через мастер на http://ваш-сервер:3000 и хранится в SQLite внутри тома, а не в файле, откатываемом через git.

Переезд свежий: даже кнопки One-Click Deploy в README ссылаются на templateName=perplexica. Найдёте статью с config.toml — это гайд до 9 марта 2026-го, повторять построчно не стоит: пути и имя контейнера там другие.

«Не настроен ни один провайдер»: ключи, Ollama и свои OpenAI-совместимые серверы

Первое, что видит почти каждый после переезда на мастер настроек, — сообщение, что провайдеры чат-моделей не заданы, даже при вписанном ключе. Чек-лист для своего OpenAI-совместимого сервера (LM Studio, LocalAI, LiteLLM) — три пункта:

• сервер слушает 0.0.0.0, а не 127.0.0.1 — иначе контейнер Vane физически не достучится до процесса на хосте;
• имя модели в настройках совпадает с тем, что реально загружено — не название семейства, а точный идентификатор;
• поле API-ключа не пустое, даже если сервер не проверяет авторизацию вовсе — Vane отказывается слать запрос без значения, и подходит любая непустая строка.

Если за прокси стоит LiteLLM, впишите в это поле реальный master_key — по нашей статье про ошибки LiteLLM с API-ключами он обязан начинаться с sk-, и одно значение закрывает оба требования.

С Ollama путаница именно на Linux — а других VPS у нас не бывает. Инструкции для Windows и macOS советуют http://host.docker.internal:11434, но на Linux этот хост сам не резолвится, нужен приватный IP хоста: http://<internal-ip>:11434. По умолчанию демон слушает только 127.0.0.1, и контейнер не достучится, даже зная верный IP. Правится через systemd:

sudo systemctl edit ollama.service

В файл добавляется:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Дальше sudo systemctl daemon-reload && sudo systemctl restart ollama, а фаервол — на подсеть Docker: sudo ufw allow from 172.17.0.0/16 to any port 11434.

Отдельно — известный баг на кастомных OpenAI-совместимых провайдерах: часть моделей за такими прокси отдаёт поиск с TypeError: Cannot read properties of undefined (reading 'slice') в консоли и без единого результата, хотя сама SearXNG отвечает нормально. Трассировка ведёт в .next/server/chunks/641.js — ломается разбор нестандартного JSON-ответа модели, не ваша настройка; фикс уже в отдельном PR. Обход — переключить модель на «родного» провайдера (OpenAI, Anthropic, Groq, Gemini) и обновиться, когда фикс выйдет в релиз.

Поиск в Perplexica зависает или молчит: SearXNG внутри и снаружи контейнера

Здесь два сценария, и важно понимать, в каком вы находитесь.

Полный образ со встроенным SearXNG. itzcrazykns1337/vane:latest разворачивает поиск в том же контейнере: по умолчанию (ENV SEARXNG_API_URL=http://localhost:8080, зашито в образ) entrypoint поднимает SearXNG от searxng на Flask-сервере разработки, а не production-WSGI, слушающем 0.0.0.0:8080 только внутри контейнера. Скрипт до 30 раз с интервалом в секунду опрашивает curl http://localhost:8080 и, если поиск не поднялся, просто пишет предупреждение и запускает Vane всё равно. Вывод: docker ps покажет Up, а первый запрос в первые секунды упадёт — поиск ещё не готов.

Второй нюанс — лимитер SearXNG в /etc/searxng/limiter.toml содержит одну строку: link_token = true — самая жёсткая проверка бота, требующая токен от загрузки страницы браузером. Vane же обращается к своему SearXNG серверным запросом, без браузера и без X-Forwarded-For/X-Real-IP. В логе:

ERROR:searx.botdetection: X-Forwarded-For nor X-Real-IP header is set!

а на стороне Vane — оборванный запрос (ResponseAborted) и зависшая карточка без ответа. Это не про внешний Nginx и чужих ботов — SearXNG внутри контейнера блокирует собственное приложение, которое его же и запустило. В v1.12.2 добавили таймауты и валидацию именно для зависающих поисковых запросов — на версиях новее v1.12.1 зависание превращается в понятную ошибку вместо вечной загрузки.

Свой отдельный SearXNG (vane:slim-latest + SEARXNG_API_URL). Чаще всего просто неверный адрес — переменная указывает на IP хоста, а SearXNG сидит в другой Docker-сети под своим именем, либо наоборот. Проверка изнутри самого Vane:

docker exec vane curl -s -o /dev/null -w '%{http_code}\n' "$SEARXNG_API_URL/search?q=test&format=json"

200 — адрес верный. 403 или пустой ответ без результатов — это территория статьи про частые ошибки SearXNG на сервере, пересказывать не будем. А вот чего там нет: README Vane отдельно требует включённый движок Wolfram Alpha на вашем SearXNG — без него часть быстрых ответов и виджетов молча не работает. Если ставили SearXNG по нашему гайду с keep_only: [google, duckduckgo, brave, wikipedia, github] — wolframalpha в списке нет, верните его отдельно.

Chromium внутри контейнера: зачем он и во что обходится скрапинг

В сборке образа, кроме Next.js-приложения и SearXNG, есть шаг yarn playwright install --with-deps --only-shell chromium — headless-браузер ставится в тот же контейнер и используется скрапером глубокого разбора: с v1.12.2 сбор контента для Deep Research переведён на Chromium вместо простого HTTP-запроса — ради сайтов, отдающих пустую заглушку без JavaScript.

Следствие: каждый параллельный чат в режиме Deep Research со скрапингом — не лёгкий fetch, а процесс браузера на вкладку. Один чат погоды не делает, а два-три одновременных на 2 ГБ RAM упрутся в своп или OOM-killer раньше результата. Проверка руками:

docker stats vane --no-stream
docker exec vane ps aux | grep -i chrom

Если список процессов chrom за несколько часов без перезапуска только растёт — симптом браузеров, не закрывшихся штатно после сбоя скрапинга; риск любого Playwright-скрапера, лечится плановым перезапуском. Точных цифр «сколько ест один Chromium» без замера на своём трафике не даст никто — ориентир — docker stats на пике, а не чужие числа из интернета.

Обновление Vane и перенос данных между версиями

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

docker pull itzcrazykns1337/vane:latest
docker stop vane && docker rm vane
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

Настройки и история чатов сохраняются автоматически — они живут в томе vane-data, а не в образе. Для тех, кто собирал из исходников, порядок другой: git pull origin master, docker build -t vane . и пересоздание контейнера — простой docker restart новый код не подхватит.

Перед обновлением честнее снять бэкап тома, а не полагаться на «сохраняется само собой»:

docker run --rm -v vane-data:/data -v "$(pwd)":/backup alpine \
  tar czf /backup/vane-data-$(date +%F).tar.gz -C /data .

Минута времени — а откатиться на предыдущий тег, если обновление сломает связку с моделью или SearXNG, можно за секунды. По той же причине в проде держите не :latest, а конкретный тег вроде itzcrazykns1337/vane:v1.12.2.

Какую конфигурацию заказывать в MAATRIX под Perplexica

Vane сам не считает модели, а раздаёт запросы наружу — облачному провайдеру или вашему Ollama. В контейнере же, помимо лёгкого Node-процесса, живёт либо полноценный SearXNG на Python (толстый образ), либо отдельный сервис рядом, плюс Chromium на каждый скрапинг. Считать нужно по этой сумме.

Честный минимум: 2 vCPU, 4 ГБ RAM, 30 ГБ NVMe — толстый образ vane:latest со встроенным SearXNG, один-два пользователя, без параллельных Deep Research. Ограничение прямое: наша статья про SearXNG называет 1–2 ГБ RAM минимумом для одного метапоиска — толстый образ несёт его вторым процессом в том же контейнере, и на 4 ГБ реально вести одно активное исследование со скрапингом, не больше. Диск уходит под сам образ: исходники SearXNG, Python-окружение и Chromium тянут несколько гигабайт ещё до первого запроса.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe — и здесь разумнее не толстый образ, а vane:slim-latest с вынесенным SearXNG. Это ровно тот сценарий, под который у MAATRIX есть готовое приложение в каталоге: SearXNG разворачивается отдельно, живёт постоянно и не зависит от перезапуска Vane, а подключается через SEARXNG_API_URL. Освободившиеся ресурсы уходят на параллельный скрапинг и на локальную модель эмбеддингов для поиска по файлам, если не берёте её через API; точный расчёт под модель — в статье сколько RAM нужно для SearXNG и Perplexica.

Локация — Великобритания, Лондон. Смысл двойной. SearXNG с британского IP реже упирается в капчу, чем с адреса из засвеченной подсети — та же логика, что в статье про установку SearXNG. А для облачных провайдеров (если модели не через Ollama) с адреса в Лондоне не встретите блокировку 403 unsupported_country_region_territory, которая прилетает на российский IP; разбор — в статье про прокси к OpenAI через сервер в Великобритании. Сам Vane в каталог MAATRIX не входит — там SearXNG, он ставится сам при заказе, доступы в личном кабинете в разделе «Доступ»; Vane разворачиваете рядом одной командой docker run из README. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT — без иностранной карты.

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