Update, 6. Oktober 2026: Der eigenständige Matrix Sliding Sync-Proxy ist nicht mehr die richtige Komponente. Matrix.org hat sein matrix-org/sliding-syncRepository im November 2025 archiviert, da es die ältere MSC3575-API implementierte, die durch Simplified Sliding Sync (MSC4186) ersetzt wurde. Synapse unterstützt die native Implementierung seit Version 1.114, wobei die Unterstützung standardmäßig aktiviert ist. Im Juli 2026 akzeptierte das Matrix Spec Core Team den Kernvorschlag für MSC4186; zugehörige Erweiterungsvorschläge werden weiterhin separat bearbeitet.
Für eine moderne mobile Synapse-Bereitstellung empfiehlt sich folgende Konfiguration: Verwenden Sie eine aktuelle Synapse-Version, stellen Sie sicher, dass diese natives Sliding Sync unterstützt, gewährleisten Sie, dass der Reverse-Proxy die Matrix-Client-API-Pfade unverändert weiterleitet, und nutzen Sie einen kompatiblen mobilen Client. Ein separater Proxy-Container, eine Proxy-Datenbank und eine alte Proxy-Discovery-URL sind nicht erforderlich.
Sollten Sie den eigenständigen Sliding Sync-Proxy trotzdem installieren?
Nein, nicht für eine neue Bereitstellung für aktuelle Matrix-Mobilclients. Der archivierte Proxy implementiert MSC3575, nicht den neueren nativen MSC4186-Flow. Laut dem Projekt-Repository wird er nicht mehr weiterentwickelt, und moderne Matrix-Clients sind nicht mehr damit kompatibel. Matrix.org kündigte außerdem die Umstellung auf native Unterstützung und die Entfernung der MSC3575-Proxy-Unterstützung aus Element X für Januar 2025 an.
Die Anleitung für ältere Proxys kann bei der Identifizierung einer alten Installation noch hilfreich sein: Sie verwendete PostgreSQL, ein persistentes Geheimnis und eine SYNCV3_*Umgebungskonfiguration. Diese Anweisungen beschreiben eine veraltete Architektur. Kopieren Sie sie nicht auf einen neuen Server und stellen Sie einen Legacy-Proxy nicht öffentlich zur Verfügung, nur weil eine alte Anleitung ihn als schneller empfiehlt.
Was hat sich geändert und was bedeutet das für mobile Nutzer?
Der frühere Proxy war ein separater Dienst zwischen Client und Server. Die vereinfachte gleitende Synchronisierung ist direkt in Synapse implementiert. Sie ermöglicht kompatiblen Clients, einen relevanten Ausschnitt aus der Raumliste eines Nutzers anzufordern und diesen schrittweise zu aktualisieren. Dadurch kann der Synchronisierungsaufwand für mobile Apps beim Öffnen oder Zurückkehren zu einem großen Konto reduziert werden.
Dies ist eine Verbesserung der Synchronisierung, keine Garantie für das sofortige Laden aller Bildschirme. Es behebt weder einen langsamen Medienserver, noch eine verzögerte Verbindung zu einem entfernten Raum, schwachen Mobilfunkempfang oder eine ausgelastete Datenbank. Die mobile App muss MSC4186 unterstützen, und der Heimserver muss dies bekanntgeben. Laut der Ankündigung auf Matrix.org umgeht die native Synapse-Implementierung den separaten Datenspeicher und die anfängliche Einschränkung der vollständigen Synchronisierung des alten Proxys.
Was benötigen Sie, bevor Sie es aktivieren können?
- Ein Matrix-Homeserver mit Synapse. Diese Anleitung setzt nicht voraus, dass Dendrite, Conduit oder ein anderer Homeserver dieselbe native Implementierung bereitstellt.
- Eine gepflegte Synapse-Version. Version 1.114 führte native MSC4186-Unterstützung ein, verwenden Sie jedoch eine aktuell unterstützte Version, anstatt 1.114 als Sicherheits- oder Wartungsempfehlung zu betrachten.
- Ein mobiler Client, der Simplified Sliding Sync unterstützt. Ein leistungsfähiger Homeserver kann einen älteren Client nicht dazu zwingen, eine API zu verwenden, die er nicht implementiert.
- Eine funktionierende HTTPS-Client-Endpunkt- und Reverse-Proxy-Konfiguration für den Homeserver.
- Vor dem Upgrade oder der Änderung des Server-Routings sollte eine aktuelle Datenbank- und Konfigurationssicherung erstellt werden.
Wie kann man überprüfen, ob Synapse bereits natives Sliding Sync anbietet?
Fragen Sie den öffentlichen Client-Server-API-Versionsendpunkt über ein Terminal ab. Ersetzen Sie den Beispielhost durch die öffentliche Basis-URL, die Ihre Matrix-Clients verwenden:
curl -fsS https://matrix.example.org/_matrix/client/versions | jq -r '.unstable_features["org.matrix.simplified_msc3575"]'
Eine Antwort truebedeutet, dass der Server das native Feature-Flag für vereinfachte Gleitsynchronisierung (Simplified Sliding Sync) anbietet. Eine Antwort mit den Werten „ false“, null„“ oder einem fehlenden Schlüssel bedeutet, dass Sie die Synapse-Version und -Konfiguration überprüfen sollten, bevor Sie den Client testen. Falls Synapse jqnicht installiert ist, rufen Sie dieselbe URL in einem Browser auf oder führen Sie den Befehl aus curl -fsS https://matrix.example.org/_matrix/client/versionsund überprüfen Sie die JSON-Antwort.
Dieses Flag signalisiert die Serverfähigkeit; es beweist weder die Kompatibilität einer bestimmten App-Version noch die Korrektheit jeder Reverse-Proxy-Route. Verwenden Sie einen Client, dessen Versionshinweise die native Unterstützung für Sliding Sync dokumentieren, und überprüfen Sie den Anfragepfad in dessen Protokollen oder, falls verfügbar, in der Browser-/Netzwerkdiagnose.
Wie aktiviert man die native Unterstützung in Synapse?
Synapse 1.114 und höher aktivierten standardmäßig die native Sliding-Sync-Funktion. Wenn die Versionsantwort bereits lautet true, ist in der Regel kein separater Dienst zu installieren und keine neue Synchronisierungsdatenbank zu erstellen. Vermeiden Sie es, spekulative Konfigurationen hinzuzufügen, nur weil ältere Anleitungen den Proxy beschreiben.
Wenn die Funktion in Ihrer Synapse-Konfiguration explizit deaktiviert ist, überprüfen Sie die Einstellung unter experimental_features. In Versionen, die das dokumentierte Flag verwenden, lautet der relevante YAML-Code:
experimental_features:
msc3575_enabled: true
Diese Einstellung sollte nur nach Prüfung der Konfigurationsdokumentation Ihrer installierten Synapse-Version hinzugefügt oder geändert werden. Erstellen Sie eine Sicherungskopie homeserver.yaml, behalten Sie den restlichen vorhandenen experimental_featuresBlock bei und achten Sie auf eine konsistente YAML-Einrückung. Validieren Sie die Datei mit dem Synapse-Befehl zur Konfigurationsvalidierung für Ihre Installation und starten Sie Synapse anschließend über den Service Manager oder die Container-Orchestrierungsmethode neu, die Sie bereits verwenden. Überprüfen Sie die Konfiguration /_matrix/client/versionsanschließend erneut.
Wenn Sie eine ältere Version als 1.114 verwenden, planen Sie ein Synapse-Upgrade gemäß der offiziellen Upgrade-Anleitung. Lesen Sie die Versionshinweise der vorherigen Version, sichern Sie die Datenbank und die Medien-/Konfigurationsdateien und folgen Sie dem für Ihre Bereitstellung empfohlenen Upgrade-Pfad. Führen Sie ein Homeserver-Upgrade, eine Reverse-Proxy-Neuschreibung und die Entfernung des alten Proxys nicht in einer einzigen, nicht verifizierten Änderung durch.
Benötigt Ihr Reverse-Proxy eine spezielle Sliding-Sync-Route?
Normalerweise nicht. Native Sliding Sync verwendet eine Matrix-Client-Server-API-Route unter `/mv/matrix/` /_matrix/client, daher sollte Ihr bestehender Reverse-Proxy den Matrix-Client-API-Namespace an Synapse weiterleiten. Die offizielle Synapse-Reverse-Proxy-Anleitung empfiehlt, `/mv/matrix/` und `/mv/matrix/` weiterzuleiten /_matrixund /_synapse/clientdie Anfrage-URI beizubehalten, anstatt sie zu kanonisieren oder zu normalisieren.
Überprüfen Sie Ihre Proxy-Regeln, falls /_matrix/client/versionsdie Synchronisierung mit einer kompatiblen App funktioniert. Stellen Sie sicher, dass Anfragen /_matrix/client/unstable/org.matrix.simplified_msc3575/Synapse erreichen und nicht an einen verbliebenen MSC3575-Proxy gesendet, von einer Web Application Firewall blockiert oder durch eine Pfadregel umgeschrieben werden. Falls Synapse hinter einem Proxy läuft, behalten Sie die in der Synapse-Dokumentation beschriebenen Header für das weitergeleitete Protokoll und die Client-IP-Adresse bei.
Erstellen Sie keinen neuen org.matrix.msc3575.proxyEintrag /.well-known/matrix/clientfür die native Unterstützung. Dieser Schlüssel verweist auf die veraltete Proxy-API. Falls Sie ihn zuvor in einer statischen, bekannten JSON-Datei oder in der Synapse-Konfiguration hinzugefügt haben extra_well_known_client_content, entfernen Sie nur diese Legacy-Proxy-Eigenschaft, nachdem Sie geprüft haben, ob kein älterer Client davon abhängt. Die normalen Homeserver-Erkennungsinformationen bleiben unverändert.
Wie migriert man eine bestehende Proxy-Installation?
- Notieren Sie die aktuelle Synapse-Version, Client-Versionen, Proxy-URL, Reverse-Proxy-Routen sowie die Datenbank- und Geheimnisspeicherorte des alten Proxys.
- Sichern Sie die Homeserver-Datenbank, die Konfiguration und die Proxy-Datenbank. Bewahren Sie diese Sicherungen auf, bis die Anmeldungen und die Synchronisierung der nativen Clients verifiziert wurden.
- Aktualisieren Sie Synapse über den dokumentierten Release-Pfad, falls es älter als Version 1.114 ist, und überprüfen Sie anschließend, ob das Flag für native Fähigkeiten zurückgegeben wird
true.
- Aktualisieren Sie Ihre mobilen Clients auf Versionen, die die native vereinfachte Wischsynchronisierung unterstützen. Folgen Sie allen Anweisungen zur Migration oder erneuten Anmeldung in der App. Bei einigen bestehenden Sitzungen ist möglicherweise eine erneute Anmeldung erforderlich, um vom alten Protokoll zu wechseln.
- Entfernen Sie die deaktivierte Proxy-Ankündigung und leiten Sie den Matrix-Client-API-Pfad zu Synapse um. Laden Sie den Reverse-Proxy neu und überprüfen Sie seine Konfiguration, bevor Sie ihn anwenden.
- Testen Sie zunächst mit einem Konto und einem Mobilgerät. Bestätigen Sie die Anmeldung, das Laden der Raumliste, das Öffnen eines verschlüsselten Raums, das Senden und Empfangen von Nachrichten sowie die Wiederverbindung nach einem Netzwerkwechsel.
- Nachdem der Test für die von Ihnen betreuten Clients erfolgreich abgeschlossen wurde, stoppen Sie den alten Proxy. Bewahren Sie die Datenbanksicherung für einen vereinbarten Rollback-Zeitraum auf; löschen Sie alte Daten erst, nachdem Sie bestätigt haben, dass sie nicht mehr benötigt werden.
Die Proxy-Datenbank enthielt den Synchronisierungsstatus auf Proxy-Seite und ersetzte nicht den Synapse-Raumverlauf. Dennoch sollte sie im Rahmen der ersten Migration nicht gelöscht werden: Sie dient als Referenz für die Fehlerbehebung der alten Konfiguration und als sicherer Rollback-Punkt beim Wechsel der Benutzer zu nativen Sitzungen.
Woran erkennt man, ob sich die Ladezeiten auf Mobilgeräten verbessert haben?
Vergleichen Sie denselben Client, dasselbe Konto, dasselbe Gerät und dasselbe Netzwerk vor und nach der Änderung, sofern Sie über verlässliche Ausgangswerte verfügen. Notieren Sie die Zeit vom Öffnen der App bis zur Anzeige einer nutzbaren Raumliste, ob aktuelle Nachrichten ohne langes Laden angezeigt werden und ob die App nach einer kurzen Offline-Phase wieder funktioniert. Wiederholen Sie den Vergleich mehrmals; ein einzelner Start kann durch den Cache-Zustand, die Netzwerkbedingungen oder einen großen Mediendownload verfälscht sein.
Wenn der Client weiterhin normale /syncAnfragen stellt und keine native Unterstützung ankündigt oder versucht, diese zu nutzen, überprüfen Sie die Clientversion und seine Synchronisierungseinstellungen. Falls er den vereinfachten Endpunkt anfordert, aber einen Fehler erhält, prüfen Sie die Synapse- und Reverse-Proxy-Protokolle für diese Anfrage. Überprüfen Sie den Zustand der Datenbank und die Serverlast, wenn viele Benutzer über langsame Ladezeiten berichten. Sliding Sync kann den Synchronisierungsaufwand reduzieren, aber eine überlastete Datenbank oder eine falsch weitergeleitete API-Anfrage nicht kompensieren.
Welche Hauptkonfigurationsoptionen gibt es?
| Ansatz | Optimale Passform | Kosten oder Einschränkung |
| Native vereinfachte Gleitsynchronisation in Synapse | Neue oder gewartete Synapse-Installationen und kompatible Clients | Erfordert einen kompatiblen Client; die Leistung hängt weiterhin vom Zustand des Servers und der Datenbank ab. |
| Legacy MSC3575-Proxy | Nur zum Verständnis oder zur vorübergehenden Aufrechterhaltung eines alten Testaufbaus | Archiviert, nicht mehr gewartet und voraussichtlich nicht mehr mit modernen Clients kompatibel. |
| Legacy Matrix-Synchronisierung | Clients oder Heimserver ohne native Sliding-Sync-Unterstützung | Funktioniert weiterhin für kompatible Clients, bietet aber nicht das gleiche native Verhalten der verschiebbaren Raumliste. |
Quellen und Versionshinweise
Das eigenständige Proxy-Repository ist archiviert. Die native Implementierung von Synapse stammt aus Version 1.114. Das Matrix Spec Core Team hat den Kernvorschlag MSC4186 im Juli 2026 angenommen, während zugehörige Erweiterungen weiterhin separat verwaltet werden. Synapse, mobile Clients und die Matrix-Spezifikation werden kontinuierlich weiterentwickelt. Prüfen Sie daher die Dokumentation und die Versionshinweise, um die genauen Versionen zu erfahren, die Sie verwenden.