How to Set Up Matrix Sliding Sync for Faster Mobile Loading (Without the Legacy Proxy)

Update, October 6, 2026: The standalone Matrix Sliding Sync proxy is no longer the right component to install. Matrix.org archived its matrix-org/sliding-sync repository in November 2025 because it implemented the older MSC3575 API, which was superseded by Simplified Sliding Sync (MSC4186). Synapse has supported the native implementation since version 1.114, with support enabled by default. In July 2026, the Matrix Spec Core Team accepted the core MSC4186 proposal; related extension proposals remain separate work.

For a modern Synapse mobile deployment, the practical setup is to run a current Synapse release, confirm that it advertises native Sliding Sync, ensure the reverse proxy passes Matrix client API paths through unchanged, and use a compatible mobile client. A separate proxy container, proxy database, and old proxy discovery URL are not required.

Should you still install the standalone Sliding Sync proxy?

No, not for a new deployment intended for current Matrix mobile clients. The archived proxy implements MSC3575, not the newer native MSC4186 flow. The project’s own repository says it is no longer maintained and that modern Matrix clients are no longer expected to work with it. Matrix.org also announced the move to native support and the removal of MSC3575 proxy support from Element X in January 2025.

The historical proxy guide may still be useful when identifying an old installation: it used PostgreSQL, a persistent secret, and a SYNCV3_* environment configuration. Those instructions describe a retired architecture. Do not copy them into a new server or expose a legacy proxy publicly just because an old tutorial calls it faster.

What changed, and what does it mean for mobile users?

The earlier proxy was a separate service that sat between a client and its homeserver. Simplified Sliding Sync is implemented in Synapse itself. It lets compatible clients request a relevant window of a user’s room list and update it incrementally, which can reduce the amount of sync work a mobile app must do when opening or returning to a large account.

This is a sync improvement, not a guarantee that every screen will load instantly. It does not make a slow media server, a delayed remote room join, weak mobile coverage, or a busy database disappear. The mobile app must support MSC4186, and the homeserver must advertise it. The Matrix.org announcement says the native Synapse implementation avoids the old proxy’s separate data store and initial full-sync limitation.

What do you need before enabling it?

• A Matrix homeserver running Synapse. This guide does not assume that Dendrite, Conduit, or another homeserver exposes the same native implementation.
• A maintained Synapse release. Version 1.114 introduced native MSC4186 support, but use a current supported release rather than treating 1.114 as a security or maintenance recommendation.
• A mobile client that supports Simplified Sliding Sync. A capable homeserver cannot make an older client use an API it does not implement.
• A working HTTPS client endpoint and reverse proxy configuration for the homeserver.
• A recent database and configuration backup before upgrading or changing server routing.

How can you check whether Synapse already advertises native Sliding Sync?

Query the public Client-Server API versions endpoint from a terminal. Replace the example host with the public base URL your Matrix clients use:

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

A response of true means the server advertises the native Simplified Sliding Sync feature flag. A response of false, null, or a missing key means you should check the Synapse version and configuration before testing the client. If jq is not installed, request the same URL in a browser or run curl -fsS https://matrix.example.org/_matrix/client/versions and inspect the JSON response.

This flag is the server’s capability signal; it does not prove that a particular app release is compatible or that every reverse-proxy route is correct. Use a client whose release notes document native Sliding Sync support and verify the request path in its logs or browser/network diagnostics when available.

How do you enable native support in Synapse?

Synapse 1.114 and later enabled native Sliding Sync by default. If the versions response is already true, there is usually no separate service to install and no new sync database to create. Avoid adding speculative configuration simply because older guides describe the proxy.

If the feature is explicitly disabled in your Synapse configuration, review the setting under experimental_features. In releases that use the documented flag, the relevant YAML is:

experimental_features:
  msc3575_enabled: true

Only add or change this setting after checking the configuration documentation for your installed Synapse version. Back up homeserver.yaml, preserve the rest of the existing experimental_features block, and keep YAML indentation consistent. Validate the file using Synapse’s configuration validation command for your installation, then restart Synapse through the service manager or container orchestration method you already use. Recheck /_matrix/client/versions afterward.

If you are running a release older than 1.114, plan a Synapse upgrade using the official upgrade instructions. Read the intervening release notes, back up the database and media/configuration files, and follow the supported upgrade path for your deployment. Do not combine a homeserver upgrade, reverse-proxy rewrite, and old-proxy removal into one unverified change.

Does your reverse proxy need a special Sliding Sync route?

Usually not. Native Sliding Sync uses a Matrix Client-Server API route under /_matrix/client, so your existing reverse proxy should forward the Matrix client API namespace to Synapse. The official Synapse reverse-proxy guide says to forward /_matrix and /_synapse/client and to preserve the request URI rather than canonicalizing or normalizing it.

Inspect your proxy rules if /_matrix/client/versions works but a compatible app cannot sync. Confirm that requests under /_matrix/client/unstable/org.matrix.simplified_msc3575/ reach Synapse and are not sent to a leftover MSC3575 proxy, blocked by a web application firewall, or rewritten by a path rule. If Synapse runs behind a proxy, retain the correct forwarded-protocol and client-IP headers described in Synapse’s documentation.

Do not create a new org.matrix.msc3575.proxy entry in /.well-known/matrix/client for native support. That key advertises the retired proxy API. If you previously added it in a static well-known JSON file or Synapse’s extra_well_known_client_content, remove only that legacy proxy property after checking that no required older client depends on it. Keep the normal homeserver discovery information intact.

How should you migrate an existing proxy installation?

1. Record the current Synapse version, client versions, proxy URL, reverse-proxy routes, and the old proxy’s database and secret locations.
2. Back up the homeserver database, configuration, and proxy database. Keep those backups until native client logins and sync have been verified.
3. Upgrade Synapse through its documented release path if it is older than 1.114, then confirm the native capability flag returns true.
4. Update mobile clients to releases that support native Simplified Sliding Sync. Follow any in-app migration or re-login prompt. Some existing sessions may need to sign in again to move from the old protocol.
5. Remove the retired proxy advertisement and route the Matrix client API path to Synapse. Reload the reverse proxy and check its configuration before applying it.
6. Test with one account and one mobile device first. Confirm login, room-list loading, opening an encrypted room, sending and receiving messages, and reconnecting after switching networks.
7. After the test succeeds for the clients you support, stop the legacy proxy. Retain its database backup for an agreed rollback window; delete old data only after you confirm it is no longer required.

The proxy database held proxy-side synchronization state rather than replacing Synapse’s room history. Still, avoid deleting it as part of the initial migration: it provides a reference for troubleshooting the legacy setup and a safer rollback boundary while users move to native sessions.

How do you tell whether mobile loading improved?

Compare the same client, account, device, and network before and after the change if you have reliable baseline measurements. Record the time from opening the app to a usable room list, whether recent messages appear without a long spinner, and whether the app catches up after a brief offline period. Repeat the comparison more than once; a single launch can be distorted by cache state, network conditions, or a large media download.

If the client still performs ordinary /sync requests and never advertises or attempts native support, check the client version and its own synchronization setting. If it requests the simplified endpoint but receives an error, inspect Synapse and reverse-proxy logs for that request. Check database health and server load if many users report slow loading. Sliding Sync can reduce sync work, but it cannot compensate for an overloaded database or a misrouted API request.

What are the main setup choices?

Sources and version notes

The standalone proxy repository is archived. Synapse’s native implementation dates to Synapse 1.114. The Matrix Spec Core Team accepted the core MSC4186 proposal in July 2026, while related extensions remain separate. Synapse, mobile clients, and the Matrix specification continue to evolve, so check the documentation and release notes for the exact versions you run.

• Archived Sliding Sync proxy repository and legacy setup notes
• Matrix.org: Sunset of the proxy and migration to native support
• Matrix.org: Native Simplified Sliding Sync in Synapse 1.114
• Synapse changelog: MSC4186 support enabled by default in 1.114
• Synapse documentation: Reverse proxy routing and URI handling
• Matrix.org: MSC4186 acceptance and remaining extension work