2026: Не устанавливаются плагины в самостоятельно размещённом Dify? Сначала проверьте Plugin Daemon

В официальном списке выпусков Dify версия 1.18.0 датирована 23 октября 2026 года — дата и материалы выпуска. Если плагины перестали устанавливаться, сначала проверьте связь из контейнера API с Plugin Daemon, адрес сервиса и согласованность ключей, а затем сопоставьте версии образов с Compose-файлом. Не меняйте наугад IP-адреса и порты: сообщение SDK в журнале само по себе ещё не доказывает, что Daemon недоступен.

Эта инструкция подойдёт тем, у кого в самостоятельно размещённом Dify не устанавливается плагин или не загружается страница управления.
Она также пригодится разработчикам, которые поддерживают собственный Dify Docker Compose и получили ошибки после обновления.
Руководителям небольших команд она поможет отделить сбой конфигурации от обоснованной потребности в другой инфраструктуре.

Что именно не работает: установка, страница управления или запрос API

Ошибка установки — это наблюдаемый результат, а не готовый диагноз. До изменения конфигурации зафиксируйте, что именно видит пользователь, какой ответ возвращает API и в каком состоянии находятся API и Plugin Daemon. Если доступна только одна строка журнала без времени, контекста запроса и статуса сервисов, по ней нельзя надёжно установить первопричину.

Разделяйте как минимум три ситуации:

• Установка плагина завершается ошибкой. Запишите полный текст сообщения из интерфейса, время операции и название плагина. Затем проверьте, поступил ли соответствующий запрос в журналы API и Daemon.
• Страница управления плагинами не загружается или отображается неполно. Это может быть связано с ответом API, правами, состоянием приложения или сетевым запросом, а не обязательно с отказом самого Daemon.
• В ответе API есть ошибка соединения или HTTP-ошибка. Важны конкретный маршрут, код ответа и момент возникновения ошибки: отказ установить соединение отличается от ответа уже доступного сервиса.

Фраза Failed to request plugin daemon — полезная подсказка для поиска, но не причина сама по себе. Уточните, какой компонент её записал: API, фоновая задача или Plugin Daemon. Если журнал показывает предупреждение SDK, но при этом сервис здоров и запросы проходят, не следует автоматически объявлять Daemon неисправным.

Для сопоставления используйте один временной интервал: сохраните время операции, последние записи API и Daemon, а также состояние контейнеров. В примерах ниже строки вывода условные: формат и точные сообщения зависят от образа и версии. Отдельные сообщения пользователей в репозитории могут подсказать, какие симптомы искать, но они не доказывают, что у вашей установки та же причина.

Связь API с Daemon: проверяйте имя сервиса, а не запомнившийся IP

В конфигурации Docker Compose имя сервиса обычно служит стабильным способом обращения между контейнерами в одной сети. Контейнерный IP может измениться после пересоздания, поэтому постоянный адрес, взятый из старого вывода inspect, часто превращает временную диагностику в будущую неисправность. Поведение сети и поиск сервисов по имени описаны в документации Docker Compose о сетях.

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

docker compose ps
docker network ls
docker network inspect <имя_сети>

Подставляйте фактическое имя сети из вывода Compose. В docker network inspect проверьте, присутствуют ли в одной ожидаемой сети контейнеры API и Plugin Daemon. Если Daemon отсутствует, сначала выясните, не завершился ли он при запуске, не остановлен ли профилем и не находится ли за другим именем проекта Compose.

Затем выполняйте проверку из контейнера API, а не с хоста:

docker compose exec api sh
getent hosts <имя_сервиса_daemon>

Здесь api и <имя_сервиса_daemon> — примеры обозначений, а не универсальные имена для каждого файла. Найдите реальные имена в своём Compose. Если в образе нет getent, используйте доступный диагностический инструмент, например nslookup, если он установлен. Важно проверить разрешение имени именно из окружения API: успешный запрос с хоста ничего не говорит о доступе между двумя контейнерами.

Если имя разрешается, проверьте соединение с адресом и портом, которые заданы в текущей конфигурации для данного режима развёртывания. Сначала определите их в Compose и переменных окружения; не подставляйте номер порта из инструкции для другой версии:

nc -vz <имя_сервиса_daemon> <порт_из_конфигурации>

Интерпретируйте результат осторожно. Ошибка разрешения имени направляет проверку к названию сервиса и общей сети. Отказ соединения может указывать на неверный порт, незапущенный процесс или доступность только на другом интерфейсе. Успешное TCP-соединение подтверждает лишь доступность порта: оно не проверяет секрет, правильность HTTP-запроса или возможность выполнить операцию плагина.

Если требуется проверить порядок запуска зависимостей, сопоставьте его с фактической готовностью процесса. Само наличие depends_on не означает, что приложение уже принимает запросы. В документации Compose о порядке запуска описано, как учитывать проверки готовности, если конфигурация и используемые механизмы поддерживают такой вариант.

API-контейнер не видит Plugin Daemon: как проверить сетевую связь?

Начните с разрешения имени Daemon внутри API-контейнера, затем проверьте TCP-соединение с портом из активной версии конфигурации. Если имя не разрешается, выясните, подключены ли контейнеры к общей сети и совпадает ли имя с именем сервиса. Если имя разрешается, но соединение отвергается, проверьте состояние Daemon, его фактический порт и привязку процесса. Не фиксируйте временный IP вручную, если официальный файл для вашей версии использует сервисное имя.

Для каждой проверки записывайте команду, время и результат. Например, getent вернул имя и адрес, а nc сообщил об отказе соединения. Это гораздо полезнее, чем заметка «сеть вроде работает»: она позволяет увидеть, на каком именно этапе возникает сбой. Так можно ответить и на вопрос, связана ли ошибка установки с сетью: связь подтверждается не фактом запуска контейнеров, а проверками из нужного контейнера и соответствующими записями API и Daemon.

URL и секреты: сверяйте параметры одной схемы развёртывания

Следующий шаг — проверить, совпадают ли адреса и секреты, которыми пользуются компоненты. Не объединяйте значения из разных примеров и режимов запуска: разработческая среда с промежуточными сервисами и полноценный контейнерный запуск могут ожидать разные настройки.

В частности, localhost внутри контейнера означает сам этот контейнер. Поэтому адрес localhost в параметре API не станет адресом Plugin Daemon только потому, что оба процесса запущены на одном сервере. Чтобы подтвердить, куда направляется запрос, найдите фактическую переменную в среде API и проследите, откуда она получает значение: из файла .env, Compose-описания, переменной окружения при запуске или другого источника.

В официальном шаблоне переменных Plugin Daemon можно проверить назначение параметров, связанных с его работой. Однако шаблон из ветки main может измениться; для исправления действующей установки сопоставляйте значения с тем релизом, который у вас реально развёрнут. Не копируйте ключи из примера или чужого контейнера: проверьте, что компоненты одной установки используют согласованные значения согласно актуальной документации этой версии.

Что проверить в адресах и секретах

1. Получите актуальный Compose-файл и .env, по которым действительно запущен проект. Не считайте локальный файл актуальным, если развёртывание запускается из другого каталога или автоматизированного процесса.
2. Найдите параметры API, относящиеся к Plugin Daemon, и соответствующие параметры самого Daemon. Сопоставьте адрес, порт и секрет по именам и назначениям, сверяясь с официальным шаблоном для своей версии.
3. Проверьте, не указывает ли адрес на localhost, если целевой компонент находится в другом контейнере.
4. Убедитесь, что в API и Daemon не попали разные значения после ручного редактирования, обновления секрета или восстановления из резервной копии.
5. После изменения примените конфигурацию тем способом, который предусмотрен для вашей версии, и вновь проверьте журналы обоих сервисов.

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

Dify Plugin Daemon доступен, но запрос завершается ошибкой?

Тогда разделите транспортную и прикладную проверки. Доступный порт не подтверждает корректность секрета, совместимость интерфейсов или успешный запуск конкретного плагина. Сопоставьте время запроса в API и Daemon, проверьте HTTP-ответ и изучите записи Daemon, относящиеся именно к этой операции. Если запрос дошёл, а ошибка возникает при инициализации одного плагина, не делайте вывод, что недоступен весь Daemon.

Для проверки соответствия конфигурации используйте официальный Compose-файл Dify версии 1.18.0 и шаблон переменных окружения этой версии. Эти материалы помогают сопоставить структуру и переменные, но не являются готовой заменой вашей настройке: локальные изменения, профиль запуска и дополнительные сервисы нужно учитывать отдельно.

После обновления: установите, не разошлись ли версии файлов и образов

Ошибка, возникшая после обновления, часто требует проверки не только тега основного приложения, но и полной согласованности комплекта: Compose-файла, .env, образов сервисов и сохранённых изменений. Нельзя считать, что старый файл развёртывания автоматически подходит к новому образу, или что обновление только одного контейнера завершает обновление всей установки.

Для версии 1.18.0 используйте опубликованные инструкции Dify по Docker-развёртыванию вместе с соответствующими Compose-описанием и шаблоном окружения. В официальной ленте выпусков версия 1.18.0 указана как выпущенная 23 октября 2026 года. Это подтверждает дату релиза, но само по себе не означает, что конкретная ошибка плагинов была исправлена именно в нём.

Сделайте сверку в контролируемом порядке:

• Запишите версии и теги образов, фактически запущенных контейнеров. Важны реальные теги, а не только предполагаемое значение в файле.
• Сравните текущие Compose и .env с файлами того релиза, который вы устанавливаете. Изменения, внесённые вручную, переносите осознанно, а не копированием всего старого файла поверх нового.
• Проверьте, присутствует ли Plugin Daemon в обновлённой конфигурации и совпадают ли его ожидаемые адреса и параметры с настройками API.
• Проверьте журналы запуска после пересоздания контейнеров. Ошибка загрузки конфигурации и ошибка отдельного запроса плагина — разные этапы.
• Сохраните копии файлов и журналов до следующего изменения, чтобы иметь возможность сравнить результат и откатить ошибочное редактирование.

Не используйте старый номер порта или готовый блок окружения из отдельного обсуждения, пока не подтвердили его соответствие текущему релизу и схеме запуска. Вопросы пользователей в репозитории показывают, что ошибки запроса Plugin Daemon встречались в разных версиях и режимах, но отдельные сообщения не доказывают общей первопричины. Для итогового вывода нужны воспроизводимая проверка и сведения о конкретной установке.

Проверка после исправления: подтвердите работу плагина от интерфейса до сервиса

Успешное прохождение одной сетевой команды — промежуточный результат, не критерий завершённого исправления. Проведите тест через ту же операцию, которая раньше завершалась ошибкой, и зафиксируйте результаты по всей цепочке: действие в интерфейсе, запрос API, обращение к Plugin Daemon и итоговое состояние плагина.

Перед тестированием проверьте, что все обязательные контейнеры находятся в ожидаемом состоянии. Выполните одну контролируемую операцию с плагином и сохраните время её запуска. Затем проверьте, что страница управления загружается, API не возвращает ошибку соединения, а журналы Daemon относятся к этой же операции. Если тест не прошёл, сопоставьте запись API с записью Daemon по времени и характеру ответа, прежде чем менять следующий параметр.

Для воспроизводимости сохраните:

• версию Dify и теги используемых образов;
• Compose-файл и перечень изменённых переменных без открытых секретов;
• схему сетей и реальные имена сервисов;
• команды проверки DNS и соединения с их выводом;
• результат установки и состояние страницы управления;
• относящиеся к тесту записи API и Plugin Daemon.

Означает ли ошибка установки, что нужен другой сервер?

Нет, не сама по себе. Если проблема вызвана неверным DNS-именем, несогласованным секретом, ошибкой Compose или смешанными версиями файлов, перенос на другую машину не исправит конфигурацию. Оценивать инфраструктуру следует после подтверждения, что цепочка запросов настроена правильно, а сбой связан с устойчивой нехваткой ресурсов или требованиями длительной эксплуатации.

При таком решении отдельно учитывайте потребление памяти всеми сервисами, объём документов и журналов, рост базы данных и резервное копирование. Не переносите данные, не согласовав, где хранятся каталоги и тома, и как будет проверено восстановление. Для предварительной оценки требований к памяти и дискам полезно составить собственный перечень сервисов и фактических данных, а не ориентироваться на единый универсальный минимум. До выбора размещения также проверьте границы и условия услуги, чтобы не приписывать серверу возможности, которые не заявлены в условиях.

Чтобы исключить пропущенный шаг, пройдите проверку перед повторным развёртыванием или переносом:

• [ ] Сохранены полный текст ошибки, время операции и имя компонента, который записал сообщение.
• [ ] Проверено состояние API и Plugin Daemon по фактически запущенным контейнерам.
• [ ] Из контейнера API проверяется имя сервиса Daemon, указанное в актуальном Compose.
• [ ] API и Daemon подключены к ожидаемой общей сети.
• [ ] Порт взят из файлов текущего релиза, а не из чужого примера.
• [ ] Адрес и секреты сверены между компонентами без публикации самих секретов.
• [ ] После обновления сопоставлены теги образов, Compose и шаблон окружения.
• [ ] Проведена повторная установка или другая прежняя операция через интерфейс.
• [ ] Результат подтверждён по журналам API и Daemon за один и тот же временной интервал.

Если после исправления Plugin Daemon работает, а ресурсов текущей среды достаточно, менять размещение ради одной ошибки не требуется. Если же вы планируете постоянно обслуживать Dify, базу знаний и сопутствующие сервисы, сравните совместно используемый VPS с выделенной машиной: у общей среды могут проявляться конкуренция с соседними задачами, ограничения на системные настройки и непрозрачность распределения ресурсов. Аренда независимого AMD-сервера у OSFP Cloud может быть уместна именно при потребности в выделенной машине для длительной эксплуатации, но не как универсальный способ чинить Plugin Daemon. Перед выбором сверьте фактические требования к памяти, хранилищу, ОС и резервному копированию с текущими условиями услуги.