Wenn das Handy still bleibt und Nextcloud nicht klingelt

Wenn das Handy partout nicht klingelt

Es gibt kaum ein Phänomen in einer selbst betriebenen Nextcloud-Installation, das mehr Ratlosigkeit erzeugt als ausbleibende Benachrichtigungen. Die Weboberfläche zeigt an, dass drei neue Dateien geteilt wurden, ein Kommentar eingegangen ist, vielleicht gerade jemand in einem Talk-Raum anruft – nur das Handy bleibt still. Kein Ton, kein Banner, keine kleine rote Zahl auf dem App-Icon. Wer dann zum ersten Mal in die Serverlogs schaut, stößt auf Begriffe wie notify_push, HPB, Reverse Proxy, FCM und wundert sich, warum ein vermeintlich simples Feature gleich mehrere Dienste, Zertifikate und Firewall-Regeln benötigt.

Dabei ist der Hintergrund technisch durchaus nachvollziehbar, wenn man sich einmal klarmacht, wie mobile Betriebssysteme mit Benachrichtigungen umgehen. Android und iOS erlauben es Anwendungen seit Jahren nicht mehr, im Hintergrund dauerhaft eine offene Verbindung zum eigenen Server zu halten. Der Akku würde das schlicht nicht überleben, und beide Plattformen haben ihre Push-Systeme als zentrale Vermittlungsstellen etabliert. Für eine selbst gehostete Anwendung wie Nextcloud bedeutet das eine Zäsur: Der Server kann nicht mehr direkt mit der App auf dem Smartphone sprechen, sondern muss über Dritte kommunizieren – über Google oder Apple, oder über einen eigenen Vermittler, der die Rolle dieser Dienste übernimmt.

Genau an dieser Stelle beginnt die Geschichte der Nextcloud-Push-Benachrichtigungen, und sie ist deutlich vielschichtiger, als es die Marketingfolien mancher Anbieter suggerieren. Wer verstehen will, warum die Einrichtung manchmal holprig verläuft und warum es sich dennoch lohnt, sollte sich mit ein paar Grundlagen beschäftigen. Nicht zuletzt, weil die Entscheidung für oder gegen bestimmte Komponenten erhebliche Auswirkungen auf Datenschutz, Betriebsaufwand und Zuverlässigkeit hat.

Drei Welten, ein Ziel

Um das Ganze zu sortieren, hilft eine grobe Dreiteilung. Da ist zunächst die Nextcloud-Instanz selbst. Sie erzeugt Ereignisse – eine neue Datei, eine Kalendereinladung, eine Talk-Nachricht, ein Freigabehinweis. Diese Ereignisse landen über die App Notifications in einer internen Tabelle. Ohne weitere Maßnahmen sieht sie nur, wer sich gerade in der Weboberfläche befindet. Die zweite Welt ist der Transportweg: ein Dienst, der dafür sorgt, dass eine Nachricht aus der Nextcloud den Weg auf ein Mobilgerät findet. Die dritte Welt ist schließlich das Empfangsgerät selbst, also die Nextcloud-Apps für Android und iOS, die sich beim Betriebssystem für Push registrieren und die Zustellung anschließend anzeigen.

In der klassischen Standardkonfiguration übernimmt Google die Rolle des Vermittlers für Android und Apple für iOS. Dabei fällt auf: Die eigentliche Nachricht, also der Inhalt einer Benachrichtigung, verlässt in dieser Konstellation nicht zwangsläufig die eigene Infrastruktur. Nextcloud verwendet ein Verfahren, bei dem über die Push-Dienste lediglich ein Signal ohne Inhalt übertragen wird – die App holt die Details anschließend direkt vom eigenen Server ab. Trotzdem bleibt ein unangenehmer Beigeschmack, denn der Server muss die Google- oder Apple-Infrastruktur überhaupt erreichen können, was in abgeschotteten Umgebungen nicht immer möglich oder erwünscht ist.

Der Push-Proxy als Sonderfall

Deshalb hat die Nextcloud-Community früh begonnen, alternative Wege zu entwickeln. Der bekannteste ist der Push-Proxy von Nextcloud selbst. Er sitzt als hauseigener Vermittlungsdienst zwischen der eigenen Instanz und den Apps und leitet Push-Signale weiter, ohne dass der Server direkt mit Google sprechen muss. In der Standardvariante läuft dieser Proxy auf Servern der Nextcloud GmbH – wer das nicht möchte, kann ihn selbst betreiben. Die Konfiguration dafür ist durchaus machbar, sie erfordert aber einiges an Fingerspitzengefühl, dazu später mehr.

Ein zweiter, oft unterschätzter Baustein ist der notify_push-Dienst, auch unter dem Kürzel push daemon bekannt. Er hat eine andere Aufgabe als der Push-Proxy. Während der Proxy die Signale an die mobilen Endgeräte bringt, sorgt notify_push dafür, dass auch die Web-Oberfläche und andere Clients sofort von Änderungen erfahren, ohne dass sie in kurzen Abständen pollen müssen. Technisch ist das ein in Rust geschriebener Dienst, der über WebSockets mit der Nextcloud kommuniziert. Ohne ihn funktioniert Nextcloud natürlich weiterhin – nur eben träger. In größeren Installationen merkt man das deutlich, vor allem wenn viele Nutzer gleichzeitig aktiv sind.

Was die Notifications-App leistet

Die App Notifications gehört inzwischen zum Standardrepertoire jeder Nextcloud-Installation. Sie sammelt Ereignisse aus allen möglichen Quellen: Freigaben, Kommentare, Sicherheitswarnungen, Zwei-Faktor-Meldungen, Kalendererinnerungen, Talk-Anrufe. Über eine interne API lassen sich eigene Anwendungen anbinden, was den Weg für Erweiterungen öffnet – etwa für Monitoring-Skripte, die den Administrator informieren, wenn eine Festplatte voll läuft.

Wichtig ist die Unterscheidung zwischen sichtbaren und unsichtbaren Benachrichtigungen. Manche Ereignisse sollen nur im Web-Interface auftauchen, andere wiederum auch das Handy erreichen. Nextcloud hat dafür ein Prioritätensystem eingeführt, das in den Einstellungen der jeweiligen App sichtbar wird. Die Verwaltung dieser Prioritäten wirkt auf den ersten Blick ein wenig spröde, erfüllt aber ihren Zweck.

Für administrative Zwecke lässt sich die Notifications-API auch per OCS-Schnittstelle ansprechen. Das ist praktisch, wenn man etwa aus einem Skript heraus eine Warnung an eine bestimmte Gruppe schicken will, ohne dafür eine eigene App zu installieren. Die nötigen Endpunkte sind sauber dokumentiert, der Aufwand ist überschaubar.

Der Weg ins Mobilgerät

Kommen wir zur praktischen Seite. Eine Nextcloud-Benachrichtigung auf einem Smartphone muss drei Hürden überstehen. Erstens: Die Instanz muss den Push-Dienst überhaupt erreichen können. Zweitens: Die App muss beim Dienst registriert sein. Drittens: Beide müssen wissen, dass sie zusammengehören. Wird eine dieser Hürden nicht überwunden, verstummt die Kommunikation – oft ohne aussagekräftige Fehlermeldung, was die Fehlersuche mühsam macht.

Historisch war dieser Weg eng mit Firebase Cloud Messaging (FCM) für Android und dem Apple Push Notification Service (APNs) für iOS verknüpft. Die Apps registrierten sich bei den jeweiligen Diensten, holten sich einen Token, und der wurde zusammen mit der Nextcloud-ID an den hauseigenen Push-Proxy übermittelt. Der Proxy wiederum kannte den Weg zu Google und Apple und stellte die Zustellung sicher. Der Vorteil: kein direkter Kontakt der Server-Infrastruktur mit der Google- oder Apple-Welt.

Mit Blick auf die europäische Datenschutzdebatte wurde dieser Ansatz mehrfach hinterfragt. Der Streit drehte sich lange um die Frage, ob die Übermittlung eines Tokens, der lediglich eine Geräte-ID darstellt, bereits personenbezogene Daten berührt. Juristisch ist die Lage knifflig und wird von Datenschutzbeauftragten unterschiedlich beurteilt. Faktisch gilt: Wer maximale Kontrolle möchte, kommt um einen selbst betriebenen Push-Proxy nicht herum, oder er nutzt gleich einen anderen Distributionsweg wie UnifiedPush auf Android.

UnifiedPush und ntfy

UnifiedPush ist ein Ansatz aus der freien Softwareszene, der das Problem an der Wurzel packt. Statt sich auf einen proprietären Dienst zu verlassen, definiert UnifiedPush eine offene Schnittstelle, über die Apps ihre Push-Kanäle beziehen. Ein Distributor, häufig ein selbst betriebener ntfy-Server, fungiert als Vermittler. Die Nextcloud Android App unterstützt UnifiedPush mittlerweile; damit lässt sich der Weg über Google komplett umgehen. Der Preis ist ein zusätzlicher Dienst, der betrieben und abgesichert werden will. Nicht jedermanns Sache, aber für schutzbedürftige Umgebungen ein echter Gewinn.

Auf iOS ist die Lage enger, weil Apple seinen Push-Dienst nicht durch Drittanbieter ersetzen lässt. Wer dort Benachrichtigungen wünscht, muss über APNs gehen. Das ist eine technische Beschränkung des Systems, keine Entscheidung von Nextcloud. Die offizielle Kommunikation ist hier ehrlich: ohne Apple Push keine iOS-Benachrichtigungen, Punkt.

notify_push in der Praxis

Der notify_push-Dienst ist in den vergangenen Jahren zu einem zentralen Bestandteil gut laufender Nextcloud-Installationen gereift. Seine Aufgabe: Die Weboberfläche und andere Clients informieren, sobald etwas passiert – Freigaben, Uploads, Chat-Nachrichten. Klassische AJAX-Abfragen alle paar Sekunden sind damit Geschichte, was nicht nur Last spart, sondern auch den gefühlten Bedienkomfort deutlich verbessert.

Die Einrichtung ist im Kern unspektakulär, hat aber einige Stolperfallen. Die wichtigste: notify_push lauscht in der Regel auf einem lokalen Port (klassisch 7867) und braucht einen Reverse Proxy, der den Endpunkt unter der Nextcloud-Domain als WebSocket erreichbar macht. Wer Nextcloud hinter Apache, Nginx oder Caddy betreibt, kann das mit wenigen Zeilen erledigen. Vergisst man die WebSocket-Weiterleitung, zeigt der Status zwar an, dass der Daemon läuft, aber die Verbindung bleibt bei jedem Clientversuch hängen. Ein Blick in die Browser-Entwicklerkonsole liefert dann schnell Klarheit: Der WebSocket-Handshake antwortet mit einem 400er oder 404er.

# Beispielkonfiguration für Nginx
location /push/ {
    proxy_pass http://127.0.0.1:7867/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
}

Ein zweiter häufiger Fehler ist die fehlende Berücksichtigung der Nextcloud-eigenen Adresserkennung. Läuft die Instanz hinter einem Proxy, muss trusted_proxies in der config.php korrekt gesetzt sein, sonst weigert sich Nextcloud, die Anfragen anzunehmen. Auch die Weiterleitung von X-Forwarded-For und ähnlichen Headern will sauber konfiguriert sein. Wer das über Jahre zusammengewachsene Konfigurationen pflegt, kennt das Problem: Ein vergessenes Header-Feld reicht und die Benachrichtigung fließt nicht.

Für die Inbetriebnahme hat sich ein Ablauf bewährt: Zuerst überprüfen, ob notify_push auf dem Loopback-Interface erreichbar ist. Danach testen, ob der Reverse Proxy den WebSocket korrekt weiterleitet. Erst dann die eigentliche Verbindung aus der Nextcloud heraus konfigurieren. Der Befehl occ notify_push:setup hilft dabei, weil er seit einigen Versionen auch einige der erforderlichen Parameter selbst ermittelt.

Der eigene Push-Proxy

Wer einen eigenen Push-Proxy betreiben möchte, betritt etwas dünner dokumentiertes Terrain. Das Prinzip ist einfach: Ein Node.js-Dienst nimmt Push-Registrierungen entgegen, speichert sie in einer Datenbank und leitet Benachrichtigungen an FCM oder APNs weiter. Die Software liegt auf GitHub und lässt sich mit etwas Erfahrung selbst kompilieren. Wichtig: Der Proxy braucht gültige Zugangsdaten für FCM und APNs, üblicherweise in Form von JSON-Schlüsseln oder Zertifikaten. Diese Dateien sind sensibel und sollten mit Bedacht verteilt werden.

Die Nextcloud-Instanz wird anschließend per config.php-Eintrag angewiesen, den eigenen Proxy zu verwenden:

'push' => [
    'proxy' => 'https://push.example.org',
],

Der Teufel steckt danach im Detail. Zertifikate müssen rechtzeitig erneuert werden (letsencrypt macht das automatisch, solange der Proxy über das offene Internet erreichbar ist). Der Proxy selbst sollte nicht direkt auf Port 80 oder 443 für andere Zwecke geöffnet werden; ein separater virtueller Host ist die saubere Lösung. Und schließlich muss man sich über eines im Klaren sein: Ein selbst betriebener Proxy ist ein zusätzlicher Dienst, der ausfallen kann. Wer ihn als Single Point of Failure einsetzt und keine Monitoring-Lösung betreibt, merkt einen Ausfall möglicherweise erst, wenn die Belegschaft sich beschwert.

Skalierung und Betrieb

Für kleinere und mittlere Installationen reicht ein einzelner Proxy-Prozess problemlos aus. Bei mehreren tausend Geräten wird es interessant: Dann ist eine horizontale Skalierung über mehrere Instanzen sinnvoll, mit einem Load Balancer davor. Der Proxy selbst ist zustandslos genug, um das zu erlauben – die Registrierungen liegen in einer Datenbank, die ohnehin zentral sein muss. Redis eignet sich gut, um die Registrierungen schnell abzurufen.

Ein oft übersehener Punkt ist die Überwachung. Push-Dienste sind gnadenlos, wenn es um falsch konfigurierte Endpunkte geht: Sie liefern entweder gar keine Rückmeldung oder verweigern die Zustellung dauerhaft. Logs sind daher essenziell, und ein Alarm, der anschlägt, wenn Zustellraten plötzlich fallen, spart viel Ärger.

Talk: wenn Klingeln wichtiger wird als Meldungen

Nextcloud Talk hat eine Sonderrolle in der Benachrichtigungslandschaft. Anrufe wollen zeitnah zugestellt werden, sonst verpuffen sie. Hinzu kommen Besonderheiten wie Klingelsequenzen, die über einen kurzen Zeitraum mehrfach ausgelöst werden. Für Talk existiert neben dem allgemeinen Push-Weg ein eigener Baustein, das High Performance Backend, kurz HPB. Es übernimmt die Rolle eines Signalisierungsservers und kümmert sich um Anrufe, Räume und Push-Zustellungen in einer Geschwindigkeit, die der Standardweg nicht leisten kann.

Das HPB ist in Rust geschrieben, es ist der gleiche Dienst, der auch notify_push enthält – nur mit zusätzlichen Funktionen für Talk. Wer Talk produktiv nutzt, sollte sich mit dem HPB vertraut machen. Es ist einer der wenigen Fälle, in denen sich eine zusätzliche Komponente tatsächlich rundum lohnt, weil die Benutzererfahrung deutlich von ihr profitiert. Ohne HPB klingelt das Handy manchmal erst nach dem dritten Klingelton – oder gar nicht, wenn die Verbindung zu spät stand.

Konfiguriert wird das HPB über occ talk:signaling:add und einige weitere Befehle. Der Dienst lauscht auf einem lokalen Port und wird ebenfalls per Reverse Proxy eingebunden. Die Authentifizierung zwischen Talk und Backend erfolgt über ein gemeinsames Geheimnis, das ausgetauscht werden muss. Stimmt es nicht überein, gibt es keine Signalisierung – mit entsprechend stummen Anrufen.

Troubleshooting: die üblichen Verdächtigen

Wenn Benachrichtigungen ausbleiben, hilft eine strukturierte Fehlersuche. Aus der Praxis lassen sich einige häufige Ursachen benennen, die fast immer wiederkehren.

• WebSocket geblockt: Ein vorgeschalteter Proxy, eine Firewall oder ein Load Balancer, der WebSocket-Upgrades nicht kennt, verhindert die Verbindung. Hier lohnt ein Blick in die Entwicklerwerkzeuge des Browsers und in die Logs des Proxys.
• Falscher Hostname: notify_push prüft, unter welchem Hostnamen die Anfrage eingeht. Weicht der Name von trusted_domains ab, wird die Verbindung abgelehnt. Besonders in Setups mit internen und externen Namen kommt das häufig vor.
• Systemzeit: Klingt trivial, ist aber ein Klassiker. Weicht die Uhrzeit auf Server und Clients um mehr als ein paar Minuten ab, scheitern TLS-Verbindungen. Regelmäßige NTP-Synchronisierung ist Pflicht.
• Token ungültig: Geräte, die neu installiert wurden, müssen ihren Push-Token aktualisieren. Bleibt eine App lange stumm, kann ein Neustart oder eine Neuinstallation der App helfen.
• Zertifikat abgelaufen: Bei selbst betriebenen Proxies ist ein abgelaufenes Let’s-Encrypt-Zertifikat eine überraschend häufige Ursache für Störungen – die Clients ignorieren schlicht die Verbindung.
• Content Security Policy: In gehärteten Umgebungen blockiert eine zu strenge CSP-Header-Zeile die WebSocket-Verbindung. Ein Blick in die Browserkonsole ist Gold wert.

Ein interessanter Aspekt ist, dass viele dieser Fehler dieselben Symptome produzieren – die Benachrichtigung kommt einfach nicht. Wer systematisch von innen nach außen testet, also erst den Daemon, dann den Proxy, dann die Verbindung zum Smartphone, spart sich viel Rätselraten.

Ein Blick in die Logs lohnt

Nextcloud protokolliert im Standardfall eher sparsam. Für tiefere Einblicke hilft es, den Log-Level temporär zu erhöhen und die notify_push-Logs separat einzusehen. Der Dienst schreibt normalerweise nach journalctl, wenn er als systemd-Unit läuft. Verbindungen mit Statuscode 400 oder 403 sind ein klarer Hinweis auf ein Problem in der Proxy-Kette – nicht selten fehlt ein Header.

Wer noch einen Schritt weitergehen will, kann mit Tools wie wscat oder websocat direkt gegen den lokalen Endpunkt testen. Das erspart die unübersichtliche Fehlersuche über den Browser.

Datenschutz und Selbstbestimmung

Die Diskussion um Push-Benachrichtigungen ist anschlussfähig an eine größere Debatte: Wie viel digitale Souveränität ist einer Organisation tatsächlich wichtig? Eine Nextcloud installiert man ja nicht ohne Grund selbst – es geht um Datenhoheit, um Kontrolle über den Weg der Informationen. Umso seltsamer wäre es, würde man die Benachrichtigungen dann vollständig über Google oder Apple laufen lassen, ohne die Alternativen überhaupt zu prüfen.

Der hauseigene Push-Proxy von Nextcloud ist ein Kompromiss: Er schützt die Inhalte, nicht aber das Metadatenblatt. Wer das eine Weile durchdenkt, kommt zum Schluss, dass ein vollständig selbst betriebener Proxy oder UnifiedPush die konsequente Fortsetzung der ursprünglichen Idee ist. Das kostet ein paar Stunden Einrichtungszeit – aber ohne diesen Aufwand bleibt die Datenhoheit immer ein wenig unvollständig.

Hinzu kommt: Was mit den mobilen Push-Tokens geschieht, ist letztlich Sache der Gerätehersteller. Ein Token, das lange nicht benutzt wird, verfällt; ein Gerät, das verloren geht, muss entfernt werden. Es lohnt sich, in regelmäßigen Abständen die Liste der registrierten Geräte durchzugehen und abgelaufene Einträge zu entfernen. Sowohl die Nextcloud-Verwaltungsoberfläche als auch der Push-Proxy bieten dafür Optionen.

Neue Entwicklungen und ein wenig Ausblick

Die Nextcloud-Push-Landschaft bewegt sich. In den vergangenen Versionen hat sich viel getan: Das HPB wurde ausgebaut, UnifiedPush ist auf Android offiziell unterstützt, und die Integration von Benachrichtigungen in Drittsysteme wurde über die Notifications-API verbessert. Auch die Rolle von notify_push wächst weiter, weil immer mehr Clients davon ausgehen, dass eine solche Verbindung verfügbar ist.

Interessant ist ein Trend hin zu gruppenbasierten Benachrichtigungen – also Meldungen, die sich an Teams oder Abteilungen richten, statt an einzelne Nutzer. Die ersten Ansätze dazu existieren, sind aber noch nicht in der Breite angekommen. Wer heute schon mit Kollegen arbeitet, weiß: Sobald eine große Gruppe betroffen ist, werden Benachrichtigungskanäle schnell unübersichtlich. Hier ist noch Luft nach oben.

Auch beim Thema Verschlüsselung von Benachrichtigungen tut sich etwas. Der aktuelle Ansatz überlässt es dem Empfänger, die Details abzurufen. Für sensible Umgebungen kann das ausreichen. Eine durchgängige Ende-zu-Ende-Verschlüsselung der Push-Signale, ähnlich wie bei Messengern, wäre der nächste logische Schritt – technisch machbar, aber mit dem bestehenden FCM- und APNs-Modell nicht trivial.

Betriebliche Empfehlungen

Wer heute eine Nextcloud in einer Organisation betreibt, sollte ein paar Punkte berücksichtigen, die sich aus der Praxis bewährt haben.

• Den eigenen Push-Proxy oder UnifiedPush ernsthaft prüfen und nicht vorschnell abtun. Der Aufwand ist überschaubar, der Gewinn nachhaltig.
• notify_push grundsätzlich aktivieren, unabhängig von Push-Benachrichtigungen. Die Web-Oberfläche wird deutlich flotter.
• Monitoring für Push-Dienste einrichten. Wenige Metriken genügen: Verbindungsaufbau, Zustellrate, letzte erfolgreiche Benachrichtigung.
• Regelmäßig die Geräteliste durchgehen und abgemeldete Geräte entfernen.
• Updates zeitnah einspielen. Gerade notify_push und das HPB haben in der Vergangenheit sicherheitsrelevante Fixes erhalten.
• Firewall-Regeln dokumentieren und regelmäßig überprüfen. Ein vergessener ausgehender Port ist schnell die Ursache eines stummen Servers.

Nicht zuletzt lohnt es, sich mit den Nutzern abzustimmen. Manche stören sich an zu vielen Meldungen, andere an zu wenigen. Die Granularität der Einstellungen ist bei Nextcloud durchaus vorhanden – sie muss nur bekannt sein.

Ein Fazit ohne Pathos

Nextcloud-Push-Benachrichtigungen sind ein unscheinbares, aber essenzielles Stück Infrastruktur. Wer sie einmal zum Laufen gebracht hat, merkt nicht mehr, dass sie existieren. Wer sie falsch konfiguriert, wird täglich daran erinnert. Die technische Komplexität ergibt sich nicht aus Willkür, sondern aus den Bedingungen, unter denen mobile Betriebssysteme arbeiten. Nextcloud hat darauf über die Jahre mit durchdachten Komponenten reagiert: der Notifications-API, dem Push-Proxy, notify_push, dem High Performance Backend, der Unterstützung von UnifiedPush. Wer bereit ist, sich ein paar Stunden mit der Materie zu beschäftigen, bekommt eine Lösung, die zuverlässig läuft und dabei den eigenen Ansprüchen an Datenschutz und Betriebsautonomie gerecht wird.

Wer dagegen hofft, dass ein Schalter genügt, wird enttäuscht. Das ist die unschöne Wahrheit. Aber sie lässt sich mit dem Trost verbinden, dass jede der Komponenten für sich genommen logisch ist – und dass die Nextcloud-Community in den vergangenen Jahren viel Dokumentation und Beispielkonfigurationen beigesteuert hat. Wer einmal verstanden hat, wie die drei Welten – Instanz, Transportweg, Mobilgerät – zusammenspielen, findet sich in jedem Setup schneller zurecht. Und irgendwann klingelt das Handy dann zuverlässig. Meistens jedenfalls. Ausnahmen bestätigen bekanntlich die Regel, und seien es nur die obligatorisch vergessenen X-Forwarded-*-Header nach einem Reverse-Proxy-Umzug.