Jak skonfigurować synchronizację Matrix Sliding w celu szybszego ładowania na urządzeniach mobilnych (bez starszego serwera proxy)

Aktualizacja, 6 października 2026 r.: Samodzielny serwer proxy Matrix Sliding Sync nie jest już właściwym komponentem do instalacji. Matrix.org zarchiwizowało swoje matrix-org/sliding-syncrepozytorium w listopadzie 2025 r., ponieważ zaimplementowano w nim starsze API MSC3575, które zostało zastąpione przez Simplified Sliding Sync (MSC4186). Synapse obsługuje natywną implementację od wersji 1.114, a obsługa jest domyślnie włączona. W lipcu 2026 r. zespół Matrix Spec Core zaakceptował główną propozycję MSC4186; powiązane propozycje rozszerzeń pozostają w oddzielnych pracach.

W przypadku nowoczesnego wdrożenia mobilnego Synapse, praktyczna konfiguracja polega na uruchomieniu aktualnej wersji Synapse, potwierdzeniu, że reklamuje ona natywną synchronizację Sliding Sync, upewnieniu się, że odwrotny serwer proxy przekazuje ścieżki API klienta Matrix bez zmian oraz użyciu kompatybilnego klienta mobilnego. Nie jest wymagany oddzielny kontener proxy, baza danych proxy ani stary adres URL wykrywania proxy.

Czy nadal warto zainstalować samodzielny serwer proxy Sliding Sync?

Nie, nie dotyczy to nowego wdrożenia przeznaczonego dla obecnych klientów mobilnych Matrix. Zarchiwizowany serwer proxy implementuje protokół MSC3575, a nie nowszy, natywny przepływ MSC4186. W repozytorium projektu podano, że nie jest on już utrzymywany i że nowi klienci Matrix nie będą już z nim współpracować. Organizacja Matrix.org ogłosiła również przejście na natywne wsparcie i usunięcie obsługi serwera proxy MSC3575 z Element X w styczniu 2025 roku.

Historyczny przewodnik po serwerze proxy może być nadal przydatny podczas identyfikacji starej instalacji: korzystała ona z PostgreSQL, trwałego klucza tajnego i SYNCV3_*konfiguracji środowiska. Instrukcje te opisują architekturę wycofaną z użytku. Nie kopiuj ich na nowy serwer ani nie udostępniaj publicznie starszego serwera proxy tylko dlatego, że w starym poradniku jest on opisany jako szybszy.

Co się zmieniło i co to oznacza dla użytkowników urządzeń mobilnych?

Wcześniejszy serwer proxy był oddzielną usługą pośredniczącą między klientem a jego serwerem domowym. Uproszczona synchronizacja przesuwna jest zaimplementowana w samym Synapse. Umożliwia ona kompatybilnym klientom żądanie odpowiedniego okna listy pokoi użytkownika i jego stopniową aktualizację, co może zmniejszyć ilość pracy synchronizacyjnej wykonywanej przez aplikację mobilną podczas otwierania lub powrotu do dużego konta.

To ulepszenie synchronizacji, a nie gwarancja, że ​​każdy ekran załaduje się natychmiast. Nie powoduje to zniknięcia powolnego serwera multimediów, opóźnionego połączenia ze zdalnym pokojem, słabego zasięgu sieci komórkowej ani przeciążonej bazy danych. Aplikacja mobilna musi obsługiwać protokół MSC4186, a serwer domowy musi go reklamować. W ogłoszeniu Matrix.org czytamy, że natywna implementacja protokołu Synapse omija ograniczenia związane z oddzielnym magazynem danych i początkową pełną synchronizacją, charakterystyczne dla starego serwera proxy.

Czego potrzebujesz przed włączeniem tej funkcji?

• Serwer domowy Matrix z systemem Synapse. Niniejszy przewodnik nie zakłada, że ​​Dendrite, Conduit lub inny serwer domowy udostępnia tę samą natywną implementację.
• Utrzymana wersja Synapse. Wersja 1.114 wprowadziła natywną obsługę MSC4186, ale korzysta z aktualnie obsługiwanej wersji, zamiast traktować wersję 1.114 jako zalecenie dotyczące bezpieczeństwa lub konserwacji.
• Klient mobilny obsługujący uproszczoną synchronizację przesuwną. Wydajny serwer domowy nie może zmusić starszego klienta do korzystania z interfejsu API, którego nie implementuje.
• Działający punkt końcowy klienta HTTPS i konfiguracja odwrotnego serwera proxy dla serwera domowego.
• Ostatnia kopia zapasowa bazy danych i konfiguracji wykonana przed uaktualnieniem lub zmianą routingu serwera.

Jak sprawdzić, czy Synapse reklamuje już natywną funkcję Sliding Sync?

Zapytaj o publiczny punkt końcowy wersji API klient-serwer z terminala. Zastąp przykładowy host publicznym adresem URL bazowym, którego używają Twoi klienci Matrix:

curl -fsS https://matrix.example.org/_matrix/client/versions   | jq -r '.unstable_features["org.matrix.simplified_msc3575"]'

Odpowiedź „ trueoznacza, że ​​serwer reklamuje natywną flagę funkcji Simplified Sliding Sync”. Odpowiedź false„, null” lub brakujący klucz oznacza, że ​​przed przetestowaniem klienta należy sprawdzić wersję i konfigurację Synapse. Jeśli jqnie jest zainstalowany, należy zażądać tego samego adresu URL w przeglądarce lub uruchomić aplikację curl -fsS https://matrix.example.org/_matrix/client/versionsi sprawdzić odpowiedź JSON.

Ta flaga to sygnał możliwości serwera; nie dowodzi ona, że ​​dana wersja aplikacji jest zgodna ani że każda trasa odwrotnego proxy jest poprawna. Użyj klienta, którego informacje o wydaniu dokumentują natywną obsługę Sliding Sync i zweryfikuj ścieżkę żądania w jego logach lub diagnostyce przeglądarki/sieci, jeśli jest dostępna.

Jak włączyć natywną obsługę w Synapse?

W Synapse 1.114 i nowszych wersjach natywna synchronizacja Sliding Sync była domyślnie włączona. Jeśli odpowiedź wersji to true, zazwyczaj nie ma potrzeby instalowania osobnej usługi ani tworzenia nowej bazy danych synchronizacji. Unikaj dodawania spekulatywnej konfiguracji tylko dlatego, że starsze przewodniki opisują serwer proxy.

Jeśli funkcja jest jawnie wyłączona w konfiguracji Synapse, sprawdź ustawienie w sekcji experimental_features. W wersjach korzystających z udokumentowanej flagi odpowiedni plik YAML to:

experimental_features:
  msc3575_enabled: true

Dodaj lub zmień to ustawienie dopiero po sprawdzeniu dokumentacji konfiguracji zainstalowanej wersji Synapse. Utwórz kopię zapasową homeserver.yaml, zachowaj resztę istniejącego experimental_featuresbloku i zachowaj spójność wcięć YAML. Sprawdź poprawność pliku za pomocą polecenia weryfikacji konfiguracji Synapse dla swojej instalacji, a następnie uruchom ponownie Synapse za pomocą menedżera usług lub metody orkiestracji kontenerów, której już używasz. Sprawdź ponownie /_matrix/client/versionspóźniej.

Jeśli korzystasz z wersji starszej niż 1.114, zaplanuj aktualizację Synapse, korzystając z oficjalnych instrukcji aktualizacji. Przeczytaj informacje o wydaniu, utwórz kopię zapasową bazy danych oraz plików multimedialnych/konfiguracyjnych i postępuj zgodnie ze ścieżką aktualizacji obsługiwaną dla Twojego wdrożenia. Nie łącz aktualizacji serwera domowego, przepisywania odwrotnego proxy i usuwania starego proxy w jedną niezweryfikowaną zmianę.

Czy Twój odwrotny serwer proxy wymaga specjalnej trasy Sliding Sync?

Zazwyczaj nie. Native Sliding Sync korzysta z trasy API klient-serwer Matrix w ramach /_matrix/client, więc Twój istniejący serwer proxy odwrotnego powinien przekazywać przestrzeń nazw API klienta Matrix do Synapse. Oficjalny przewodnik po serwerze proxy odwrotnego Synapse zaleca przekierowywanie /_matrixi /_synapse/clientzachowywanie URI żądania zamiast jego kanonizacji lub normalizacji.

Sprawdź, czy reguły proxy /_matrix/client/versionsdziałają, ale zgodna aplikacja nie może się zsynchronizować. Upewnij się, że żądania docierają do /_matrix/client/unstable/org.matrix.simplified_msc3575/Synapse i nie są wysyłane do resztkowego serwera proxy MSC3575, blokowane przez zaporę sieciową aplikacji internetowych lub przepisywane przez regułę ścieżki. Jeśli Synapse działa za serwerem proxy, zachowaj poprawne nagłówki forwarded-protocol i client-IP opisane w dokumentacji Synapse.

Nie twórz nowego org.matrix.msc3575.proxywpisu w /.well-known/matrix/clientcelu uzyskania obsługi natywnej. Ten klucz reklamuje wycofane API proxy. Jeśli dodałeś je wcześniej w statycznym, znanym pliku JSON lub w pliku Synapse extra_well_known_client_content, usuń tylko tę starszą właściwość proxy po sprawdzeniu, czy nie jest od niej zależny żaden wymagany starszy klient. Zachowaj nienaruszone informacje o standardowym wykrywaniu serwera domowego.

Jak przeprowadzić migrację istniejącej instalacji serwera proxy?

1. Zarejestruj bieżącą wersję usługi Synapse, wersje klienta, adres URL serwera proxy, trasy odwrotnego serwera proxy oraz lokalizacje bazy danych i tajnych kluczy starego serwera proxy.
2. Utwórz kopię zapasową bazy danych serwera domowego, konfiguracji i bazy danych proxy. Zachowaj te kopie zapasowe do czasu weryfikacji logowań i synchronizacji klienta natywnego.
3. Jeśli wersja Synapse jest starsza niż 1.114, zaktualizuj ją zgodnie z udokumentowaną ścieżką wydania, a następnie sprawdź, czy flaga natywnej funkcjonalności zwraca wartość true.
4. Zaktualizuj klientów mobilnych do wersji obsługujących natywną funkcję Simplified Sliding Sync. Postępuj zgodnie z instrukcjami migracji w aplikacji lub ponownego logowania. Niektóre istniejące sesje mogą wymagać ponownego zalogowania, aby przejść ze starego protokołu.
5. Usuń wycofaną reklamę proxy i skieruj ścieżkę API klienta Matrix do Synapse. Załaduj ponownie odwrotny serwer proxy i sprawdź jego konfigurację przed jego zastosowaniem.
6. Przetestuj najpierw na jednym koncie i jednym urządzeniu mobilnym. Potwierdź logowanie, załadowanie listy pokoi, otwarcie zaszyfrowanego pokoju, wysyłanie i odbieranie wiadomości oraz ponowne połączenie po zmianie sieci.
7. Po pomyślnym zakończeniu testu dla obsługiwanych klientów, zatrzymaj starszy serwer proxy. Zachowaj kopię zapasową jego bazy danych na uzgodniony okres przywracania; usuń stare dane dopiero po potwierdzeniu, że nie są już potrzebne.

Baza danych proxy przechowywała stan synchronizacji po stronie proxy, zamiast zastępować historię pokoju Synapse. Mimo to, należy unikać jej usuwania w ramach początkowej migracji: stanowi ona punkt odniesienia do rozwiązywania problemów ze starszą konfiguracją i zapewnia bezpieczniejszą granicę wycofania, gdy użytkownicy przechodzą na sesje natywne.

Jak stwierdzić, czy ładowanie urządzeń mobilnych uległo poprawie?

Jeśli dysponujesz wiarygodnymi pomiarami bazowymi, porównaj tego samego klienta, konto, urządzenie i sieć przed i po zmianie. Zanotuj czas od uruchomienia aplikacji do wyświetlenia listy dostępnych pokoi, sprawdź, czy ostatnie wiadomości pojawiają się bez długiego paska przewijania oraz czy aplikacja nadrabia zaległości po krótkim okresie offline. Powtórz porównanie więcej niż raz; pojedyncze uruchomienie może zostać zakłócone przez stan pamięci podręcznej, warunki sieciowe lub pobieranie dużej ilości multimediów.

Jeśli klient nadal wykonuje standardowe /syncżądania i nigdy nie reklamuje ani nie próbuje natywnej obsługi, sprawdź wersję klienta i jego własne ustawienia synchronizacji. Jeśli żąda uproszczonego punktu końcowego, ale otrzymuje błąd, sprawdź dzienniki Synapse i odwrotnego proxy dla tego żądania. Sprawdź stan bazy danych i obciążenie serwera, jeśli wielu użytkowników zgłasza wolne ładowanie. Przesuwająca się synchronizacja może zmniejszyć nakład pracy synchronizacji, ale nie zrekompensuje przeciążonej bazy danych lub błędnie przekierowanego żądania API.

Jakie są główne opcje konfiguracji?

Źródła i notatki dotyczące wersji

Samodzielne repozytorium proxy zostało zarchiwizowane. Natywna implementacja Synapse pochodzi z wersji Synapse 1.114. Zespół Matrix Spec Core zaakceptował propozycję MSC4186 w lipcu 2026 roku, natomiast powiązane rozszerzenia pozostają niezależne. Synapse, klienci mobilni i specyfikacja Matrix stale ewoluują, dlatego sprawdź dokumentację i informacje o wydaniach, aby dowiedzieć się, z których wersji korzystasz.

• Zarchiwizowane repozytorium proxy Sliding Sync i starsze notatki dotyczące konfiguracji
• Matrix.org: Zachód słońca z proxy i migracja do obsługi natywnej
• Matrix.org: Natywna uproszczona synchronizacja przesuwna w Synapse 1.114
• Dziennik zmian Synapse: obsługa MSC4186 włączona domyślnie w wersji 1.114
• Dokumentacja Synapse: odwrotne routing proxy i obsługa URI
• Matrix.org: Akceptacja MSC4186 i pozostałe prace rozszerzające