2026 Dify: Plugin-Installation beim Self-Hosting fehlgeschlagen? Zuerst den Plugin Daemon prüfen

Auf der Dify-Verwaltungsseite schlägt die Plugin-Installation fehl oder die Anfrage an den Plugin Daemon endet mit einem Verbindungsfehler.

Dieser Leitfaden richtet sich an Sie, wenn Sie Dify selbst hosten und Plugins nicht installieren oder verwalten können.
Er ist auch für Teams gedacht, die eine angepasste Docker-Compose-Datei betreiben, nach einem Upgrade Fehler sehen oder den dauerhaften Serverbetrieb für ihre Wissensdatenbank planen.

Zuletzt aktualisiert am 31.10.2026. Geprüft anhand der offiziellen Dify-Releases, der versionsgebundenen Bereitstellungsdateien und der Dokumentation zum Compose-Netzwerk.

Fehlermeldung und Fehlerursache auseinanderhalten

Ein Hinweis wie „Failed to request plugin daemon“ beschreibt zunächst, dass eine Anfrage nicht erfolgreich abgeschlossen wurde. Er beweist für sich genommen weder, dass der Daemon gestoppt ist, noch dass ein bestimmter Port falsch eingestellt wurde. Für eine belastbare Diagnose müssen Sie drei Beobachtungen zusammenführen: Was zeigt die Oberfläche? Was protokolliert der API-Dienst? Was meldet der Plugin Daemon zum selben Vorgang?

Notieren Sie vor Änderungen den genauen Fehlertext und den Zeitpunkt. Suchen Sie dann in den Protokollen beider Dienste nach Einträgen aus demselben Zeitfenster. Prüfen Sie, ob der API-Dienst gar keine Verbindung aufbauen kann, ob eine Antwort mit einem HTTP-Fehler ankommt oder ob der Daemon die Anfrage erhält und erst beim Start eines bestimmten Plugins scheitert. Diese Unterscheidung verhindert, dass ein Plugin-Problem mit Änderungen am gesamten Container-Netzwerk beantwortet wird.

Ein SDK- oder Plugin-Startfehler in den Daemon-Protokollen ist daher nicht automatisch die Erklärung für einen Verbindungsfehler zwischen API und Daemon. Ein einzelner Warnhinweis kann zeitlich neben dem eigentlichen Fehler auftreten, ohne dessen Ursache zu sein. Beurteilen Sie immer, ob der API-Dienst die Anfrage tatsächlich gesendet hat und ob der Daemon sie empfangen hat.

Verbindung aus dem API-Container prüfen

Bei einer vollständigen Compose-Bereitstellung kommunizieren Dienste üblicherweise über das Compose-Netzwerk und den dort verfügbaren Dienstnamen. Welche Namen und Einstellungen in Ihrer Installation gelten, ergibt sich jedoch aus genau der Compose-Datei, die Sie verwenden. Die Docker-Dokumentation zur Namensauflösung und Kommunikation in Compose-Netzwerken erklärt dieses Prinzip; sie ersetzt nicht den Abgleich mit Ihrer Dify-Konfiguration.

Ermitteln Sie zuerst die tatsächlichen Dienstnamen:

docker compose config --services
docker compose ps

Nutzen Sie anschließend den in der Ausgabe vorhandenen API-Dienstnamen und den in Ihrer Compose-Datei definierten Daemon-Dienstnamen. Die folgenden Beispiele setzen voraus, dass Ihre Dienste tatsächlich api und plugin_daemon heißen. Falls die Schlüssel anders lauten, ersetzen Sie sie durch die Werte aus Ihrer Konfiguration:

docker compose exec api sh -lc 'getent hosts plugin_daemon'
docker compose exec api sh -lc 'printenv | grep -E "PLUGIN_DAEMON|PLUGIN.*URL"'

Eine aufgelöste Adresse zeigt, dass der Name innerhalb des Containers gefunden wird. Sie beweist noch nicht, dass der Zielprozess erreichbar ist oder die Anfrage akzeptiert. Prüfen Sie deshalb als Nächstes aus demselben API-Container die konfigurierte URL. Verwenden Sie dabei den Wert, den Ihre Version tatsächlich bereitstellt, nicht eine frei angenommene Adresse:

docker compose exec api sh -lc 'curl -sv "$PLUGIN_DAEMON_URL" -o /dev/null'

Die Ausgabe muss vorsichtig interpretiert werden. Ein Fehler bei der Namensauflösung deutet auf Dienstname oder Netzwerkkonfiguration. Eine abgelehnte Verbindung spricht eher dafür, dass Zieladresse oder Listener nicht erreichbar sind. Eine HTTP-Antwort zeigt zunächst, dass eine Verbindung bis zu einem HTTP-Dienst aufgebaut wurde; auch ein Fehlerstatus kann dafür sprechen. Daraus folgt noch nicht, dass Authentifizierung und Plugin-Anfrage funktionieren. Für die von Dify vorgesehenen Variablen vergleichen Sie Ihre Datei mit der Plugin-Daemon-Umgebungsvorlage und der zu Ihrer Version passenden Konfiguration.

Dienstadresse und Schlüssel abgleichen

Wenn die Verbindung grundsätzlich zustande kommt, prüfen Sie als Nächstes, ob API und Daemon dieselbe Bereitstellungsart erwarten. Eine komplette Docker-Compose-Installation ist nicht automatisch mit Einstellungen aus einer lokalen Entwicklungsumgebung oder einer selbst zusammengestellten Teilinstallation kompatibel. Verwechseln Sie außerdem eine interne Dienstadresse nicht mit einer Adresse, die nur vom Browser oder einem externen Client erreichbar sein soll.

In einer Container-Umgebung bezeichnet localhost den jeweiligen Container selbst. Wenn Sie eine Daemon-URL mit localhost in der Konfiguration des API-Containers finden, prüfen Sie daher, ob der Daemon tatsächlich im selben Container läuft. Ist er ein eigener Compose-Dienst, muss die Adresse zu der vorgesehenen Container-Kommunikation passen. Ändern Sie den Wert nicht pauschal: Vergleichen Sie ihn mit der Compose-Datei und der Beispiel-Umgebung für dieselbe Version.

Die offizielle Plugin-Daemon-Vorlage hilft dabei, die relevanten Einstellungen und deren vorgesehene Zuordnung zu erkennen. Vergleichen Sie insbesondere:

• den in der API-Konfiguration hinterlegten Daemon-Endpunkt mit dem tatsächlichen Compose-Dienst;
• den Schlüssel, den der API-Dienst verwendet, mit der passenden Daemon-Konfiguration;
• die Netzwerke, denen beide Dienste zugeordnet sind;
• Abweichungen zwischen Ihrer aktiven Umgebungsdatei und dem Beispiel der verwendeten Version.

Geben Sie Schlüssel nicht in Supportbeiträgen oder öffentlich zugänglichen Protokollen weiter. Für die Diagnose genügt es meist, auf beiden Seiten zu prüfen, ob der erwartete Variablenname vorhanden ist und ob der Wert übereinstimmt. Ein teilweise maskierter Vergleich ist sicherer, als den vollständigen Schlüssel in ein Ticket zu kopieren.

Versionsmischung nach Änderungen ausschließen

Nach einem Upgrade oder einer manuellen Anpassung kann die Bereitstellung aus Bestandteilen verschiedener Versionen bestehen: etwa einer neuen Anwendung, einer älteren Compose-Datei und einer nicht aktualisierten Umgebungsdatei. Dann kann ein Dienst starten, während eine andere Komponente eine abweichende Konfiguration erwartet. Prüfen Sie die Zusammengehörigkeit der Dateien, bevor Sie einzelne Einstellungen aus fremden Beispielen übernehmen.

Dify führt die Veröffentlichung von Version 1.18.0 mit Datum 23.10.2026 in den offiziellen Releases. Für diese Version sollten Sie die offizielle Docker-Bereitstellungsbeschreibung, die zugehörige Compose-Datei und die passende Umgebungsvariablen-Vorlage gemeinsam heranziehen. Übertragen Sie daraus keine einzelne Einstellung in eine andere Version, ohne deren Kompatibilität zu prüfen.

Wenn Dienste beim Start zeitweise noch nicht erreichbar sind, untersuchen Sie zusätzlich die Abhängigkeiten und Startreihenfolge. Die Compose-Konfiguration kann Abhängigkeiten deklarieren; ein gestarteter Container ist aber nicht in jedem Fall gleichbedeutend mit einem für jede Anfrage bereiten Dienst. Die Dokumentation zur Startreihenfolge in Compose beschreibt, welche Rolle Abhängigkeiten und Zustandsprüfungen spielen. Prüfen Sie die konkrete Umsetzung in Ihrer Version, statt eine Healthcheck-Konfiguration aus einem anderen Projekt zu kopieren.

SDK-Hinweise und Daemon-Ausfall unterscheiden

Eine Logzeile mit einem SDK-Begriff kann auffällig sein, aber sie ist erst dann ein belastbarer Ansatzpunkt, wenn sie zum tatsächlichen Fehlerpfad passt. Fragen Sie: Hat der Daemon zur selben Zeit eine Anfrage erhalten? Gibt es eine dazu passende Antwort? Scheitert die Verbindung schon vor dem Plugin-Start, oder entsteht der Fehler erst während der Initialisierung eines einzelnen Plugins?

Wenn die Namensauflösung fehlschlägt, beheben Sie zuerst Dienstname oder Netzwerkanbindung. Wenn eine HTTP-Verbindung zustande kommt, prüfen Sie Status und Antwort auf API- und Daemon-Seite sowie den Schlüsselabgleich. Wenn nur ein Plugin betroffen ist und andere Verwaltungsfunktionen arbeiten, untersuchen Sie dessen Initialisierungsfehler, statt die gesamte Daemon-Verbindung vorsorglich umzubauen.

Community-Berichte und automatisch erzeugte Antworten können Hinweise darauf geben, welche Symptome andere Betreiber beobachtet haben. Sie sind aber weder eine offizielle Diagnose noch ein Beleg dafür, dass Ihre Bereitstellung dieselbe Ursache hat. Entscheidend sind die für Ihre Version veröffentlichten Dateien, die tatsächliche Anfrage und ein reproduzierbarer Test. Wenn Sie einen Bericht als Hinweis verwenden, trennen Sie klar zwischen der beobachteten Meldung und einer bestätigten Ursache.

Reparatur mit einer Funktionsprüfung abschließen

Nehmen Sie Änderungen einzeln vor und halten Sie fest, welche Datei Sie geändert haben. Wenn Sie mehrere Werte gleichzeitig ändern, lässt sich später kaum feststellen, welcher Eingriff den Fehler behoben oder neu ausgelöst hat. Nach einer Anpassung starten Sie nur die betroffenen Dienste entsprechend Ihrer Bereitstellung neu und kontrollieren sowohl deren Zustand als auch die neuen Protokolle.

Gehen Sie anschließend diese Prüfliste durch:

• [ ] Die wirksame Compose-Konfiguration lässt sich ohne fehlende Variablen ausgeben.
• [ ] Der API-Container löst den tatsächlichen Compose-Dienstnamen des Daemons auf.
• [ ] Die konfigurierte Daemon-Adresse ist aus dem API-Container erreichbar; eine HTTP-Antwort wird nicht mit erfolgreicher Authentifizierung gleichgesetzt.
• [ ] API und Daemon verwenden zueinander passende Schlüssel, ohne dass Sie diese öffentlich protokollieren.
• [ ] Images, Compose-Datei und Umgebungsbeispiele gehören zur vorgesehenen Dify-Version.
• [ ] Ein Plugin lässt sich installieren oder aktualisieren, und die Verwaltungsseite zeigt den erwarteten Zustand.
• [ ] Für den geprüften Vorgang finden sich keine neuen, dazu passenden Verbindungsfehler in API- und Daemon-Protokollen.
• [ ] Sie haben Version, relevante Konfigurationsänderungen und das Ergebnis des Tests für eine spätere Fehleranalyse festgehalten.

Ein erfolgreicher Test der Verwaltungsseite allein reicht nicht, wenn die eigentliche Plugin-Anfrage weiterhin scheitert. Umgekehrt sollte ein einzelner Warnhinweis ohne Auswirkung auf Installation oder Verwaltung nicht automatisch Anlass für einen Umbau der Serverumgebung sein. Wenn die Fehler nicht mit Netzwerk oder Version zusammenhängen, halten Sie den Dienst auf dem bestehenden System und untersuchen Sie die konkrete Plugin-Initialisierung weiter.

Häufige Fragen zur Plugin-Fehlersuche

Was hilft, wenn Dify „Failed to request plugin daemon“ meldet?

Prüfen Sie zuerst, ob der API-Container den Plugin-Daemon unter dem in Ihrer Compose-Datei vorgesehenen Dienstnamen auflösen und erreichen kann. Kontrollieren Sie danach die von API und Daemon verwendeten Adressen und Schlüssel sowie deren Image- und Konfigurationsversionen. Eine Meldung allein belegt weder einen Ausfall des Daemons noch, dass ein anderer Port die Lösung ist.

Ist eine fehlgeschlagene Plugin-Installation bei Dify immer ein Netzwerkproblem?

Nein. Ein Verbindungsfehler zwischen API und Daemon ist nur eine mögliche Ursache. Auch nicht übereinstimmende Schlüssel, eine falsche interne URL, abweichende Compose-Dateien oder ein einzelner Fehler beim Start eines Plugins kommen infrage. Vergleichen Sie deshalb API-Antwort, Daemon-Status und den konkreten Plugin-Fehler, statt aus einer einzelnen Logzeile auf die Ursache zu schließen.

Wie teste ich die Verbindung vom Dify-API-Container zum Plugin Daemon?

Starten Sie mit dem tatsächlichen API-Dienstnamen aus Ihrer Compose-Datei und prüfen Sie darin die Namensauflösung des Daemon-Dienstes. Rufen Sie anschließend die konfigurierte Daemon-URL aus demselben Container auf. Eine HTTP-Antwort, auch ein Fehlerstatus, zeigt zunächst nur, dass eine Verbindung zustande kam; sie bestätigt nicht automatisch eine erfolgreiche Plugin-Anfrage.

Welche Einstellungen prüfe ich bei einem Fehler in der Dify-Plugin-Verwaltung?

Gleichen Sie die von Ihrer installierten Dify-Version vorgegebenen internen Adressen, den Plugin-Daemon-Schlüssel und die Dienstnamen in der Compose-Konfiguration ab. Prüfen Sie außerdem, ob beide Container im erwarteten Netzwerk laufen und ob Images, Umgebungsdatei und Compose-Datei zur selben Version gehören. Kopieren Sie keine Werte aus einer anderen Bereitstellungsart.

Wenn die Fehleranalyse keine Ressourcenknappheit zeigt, ist ein Serverwechsel keine Reparatur für einen fehlerhaften Dienstnamen, Schlüssel oder Versionsmix. Für einen dauerhaften Betrieb sollten Sie stattdessen anhand Ihrer tatsächlichen Zahl an Anwendungen, Daten und Sicherungskopien bewerten, ob der bestehende Betriebspunkt ausreicht. Die Hinweise zu Arbeitsspeicher und Datenträgern für Serverdienste helfen bei dieser Planung; die Leistungs- und Dienstgrenzen sollten Sie ebenfalls prüfen, bevor Sie eine langfristige Mietlösung auswählen.

Eine gemeinsam genutzte VPS-Umgebung kann für Tests oder kleine, wechselnde Lasten passen. Bei dauerhaftem Betrieb können jedoch geteilte Ressourcen, eine begrenzte Kontrolle über die zugrunde liegende Hardware und abweichende Speicheroptionen die Planbarkeit erschweren. Wenn Sie für Dify und weitere selbst gehostete Anwendungen dauerhaft exklusiv zugewiesene Rechenressourcen benötigen, vergleichen Sie diese Anforderungen mit den aktuell ausgewiesenen Möglichkeiten von OSFP Cloud, statt die Miete eines physischen Servers als allgemeine Fehlerbehebung zu behandeln. Prüfen Sie die konkreten Bedingungen direkt in der aktuellen Produktübersicht von OSFP Cloud.

Häufige Fragen

Was hilft, wenn Dify „Failed to request plugin daemon“ meldet?

Prüfen Sie zuerst, ob der API-Container den Plugin-Daemon unter dem in Ihrer Compose-Datei vorgesehenen Dienstnamen auflösen und erreichen kann. Kontrollieren Sie danach die von API und Daemon verwendeten Adressen und Schlüssel sowie deren Image- und Konfigurationsversionen. Eine Meldung allein belegt weder einen Ausfall des Daemons noch, dass ein anderer Port die Lösung ist.

Ist eine fehlgeschlagene Plugin-Installation bei Dify immer ein Netzwerkproblem?

Nein. Ein Verbindungsfehler zwischen API und Daemon ist nur eine mögliche Ursache. Auch nicht übereinstimmende Schlüssel, eine falsche interne URL, abweichende Compose-Dateien oder ein einzelner Fehler beim Start eines Plugins kommen infrage. Vergleichen Sie deshalb API-Antwort, Daemon-Status und den konkreten Plugin-Fehler, statt aus einer einzelnen Logzeile auf die Ursache zu schließen.

Wie teste ich die Verbindung vom Dify-API-Container zum Plugin Daemon?

Starten Sie mit dem tatsächlichen API-Dienstnamen aus Ihrer Compose-Datei und prüfen Sie darin die Namensauflösung des Daemon-Dienstes. Rufen Sie anschließend die konfigurierte Daemon-URL aus demselben Container auf. Eine HTTP-Antwort, auch ein Fehlerstatus, zeigt zunächst nur, dass eine Verbindung zustande kam; sie bestätigt nicht automatisch eine erfolgreiche Plugin-Anfrage.

Welche Einstellungen prüfe ich bei einem Fehler in der Dify-Plugin-Verwaltung?

Gleichen Sie die von Ihrer installierten Dify-Version vorgegebenen internen Adressen, den Plugin-Daemon-Schlüssel und die Dienstnamen in der Compose-Konfiguration ab. Prüfen Sie außerdem, ob beide Container im erwarteten Netzwerk laufen und ob Images, Umgebungsdatei und Compose-Datei zur selben Version gehören. Kopieren Sie keine Werte aus einer anderen Bereitstellungsart.