Mise à jour du 6 octobre 2026 : Le proxy Matrix Sliding Sync autonome n’est plus le composant approprié. Matrix.org a archivé son matrix-org/sliding-syncdépôt en novembre 2025 car il implémentait l’ancienne API MSC3575, remplacée depuis par Simplified Sliding Sync (MSC4186). Synapse prend en charge l’implémentation native depuis la version 1.114, avec une prise en charge activée par défaut. En juillet 2026, l’équipe principale de la spécification Matrix a accepté la proposition MSC4186 ; les propositions d’extension connexes restent à l’étude séparément.
Pour un déploiement mobile Synapse moderne, la configuration pratique consiste à utiliser une version récente de Synapse, à vérifier qu'elle prend en charge la synchronisation glissante native, à s'assurer que le proxy inverse transmet les chemins d'accès à l'API du client Matrix sans modification et à utiliser un client mobile compatible. Un conteneur proxy distinct, une base de données proxy et une ancienne URL de découverte de proxy ne sont pas nécessaires.
Non, pas pour un nouveau déploiement destiné aux clients mobiles Matrix actuels. Le proxy archivé implémente le protocole MSC3575, et non le flux natif plus récent MSC4186. Le dépôt du projet indique qu'il n'est plus maintenu et que les clients Matrix modernes ne sont plus censés fonctionner avec. Matrix.org a également annoncé le passage à une prise en charge native et la suppression de la prise en charge du proxy MSC3575 d'Element X en janvier 2025.
Le guide historique sur les proxys peut encore être utile pour identifier une ancienne installation : il utilisait PostgreSQL, un secret persistant et une SYNCV3_*configuration d'environnement. Ces instructions décrivent une architecture obsolète. Ne les copiez pas sur un nouveau serveur et n'exposez pas publiquement un proxy ancien sous prétexte qu'un ancien tutoriel le présente comme plus rapide.
L'ancien proxy était un service distinct qui faisait office d'intermédiaire entre un client et son serveur. La synchronisation glissante simplifiée est intégrée à Synapse. Elle permet aux clients compatibles de demander une fenêtre pertinente de la liste des salles d'un utilisateur et de la mettre à jour progressivement, ce qui réduit la charge de synchronisation d'une application mobile lors de l'ouverture ou de la consultation d'un compte volumineux.
Il s'agit d'une amélioration de la synchronisation, et non d'une garantie de chargement instantané de tous les écrans. Elle ne résout pas les problèmes liés à un serveur multimédia lent, à une connexion différée à une salle distante, à une faible couverture mobile ou à une base de données surchargée. L'application mobile doit être compatible avec le protocole MSC4186 et le serveur d'accès doit le signaler. L'annonce sur Matrix.org indique que l'implémentation native de Synapse évite le stockage de données séparé et la limitation de synchronisation initiale de l'ancien proxy.
Interrogez le point de terminaison public de l'API client-serveur depuis un terminal. Remplacez l'hôte d'exemple par l'URL de base publique utilisée par vos clients Matrix :
curl -fsS https://matrix.example.org/_matrix/client/versions | jq -r '.unstable_features["org.matrix.simplified_msc3575"]'Une réponse de truetype « true » indique que le serveur prend en charge la fonctionnalité de synchronisation glissante simplifiée native. Une réponse de type « false » false, null« false » ou une clé manquante signifie que vous devez vérifier la version et la configuration de Synapse avant de tester le client. Si Synapse jqn'est pas installé, accédez à la même URL dans un navigateur ou exécutez la commande curl -fsS https://matrix.example.org/_matrix/client/versionset examinez la réponse JSON.
Ce drapeau indique la capacité du serveur ; il ne garantit ni la compatibilité d'une version particulière de l'application, ni la validité de chaque route de proxy inverse. Utilisez un client dont les notes de version mentionnent la prise en charge native de la synchronisation glissante et vérifiez le chemin de la requête dans ses journaux ou les diagnostics du navigateur/réseau, le cas échéant.
Synapse 1.114 et versions ultérieures activent la synchronisation glissante native par défaut. Si la réponse de la commande « versions » est déjà « sliding Sync » true, il n'y a généralement aucun service supplémentaire à installer ni de nouvelle base de données de synchronisation à créer. Évitez d'ajouter une configuration superflue simplement parce que d'anciens guides décrivent le proxy.
Si cette fonctionnalité est explicitement désactivée dans votre configuration Synapse, vérifiez le paramètre correspondant experimental_features. Dans les versions utilisant l'indicateur documenté, le code YAML correspondant est :
experimental_features:
msc3575_enabled: trueN'ajoutez ou ne modifiez ce paramètre qu'après avoir consulté la documentation de configuration de votre version de Synapse. Sauvegardez le fichier homeserver.yaml, conservez le reste du experimental_featuresbloc existant et veillez à la cohérence de l'indentation YAML. Validez le fichier à l'aide de la commande de validation de configuration de Synapse pour votre installation, puis redémarrez Synapse via le gestionnaire de services ou la méthode d'orchestration de conteneurs que vous utilisez habituellement. Vérifiez à /_matrix/client/versionsnouveau après ces opérations.
Si vous utilisez une version antérieure à la 1.114, planifiez une mise à niveau de Synapse en suivant les instructions officielles. Consultez les notes de version intermédiaires, sauvegardez la base de données et les fichiers de configuration/média, puis suivez la procédure de mise à niveau recommandée pour votre déploiement. Ne combinez pas la mise à niveau du serveur d'accueil, la réécriture du proxy inverse et la suppression de l'ancien proxy en une seule opération non vérifiée.
Généralement non. La synchronisation glissante native utilise une route d'API client-serveur Matrix sous `/usr/localhost/123486` /_matrix/client, votre proxy inverse existant doit donc rediriger l'espace de noms de l'API client Matrix vers Synapse. Le guide officiel des proxys inverses de Synapse recommande de rediriger `/usr/localhost/123486` /_matrixet /_synapse/clientde conserver l'URI de la requête plutôt que de la normaliser ou de la canoniser.
Vérifiez vos règles de proxy si /_matrix/client/versionsla synchronisation fonctionne mais qu'une application compatible ne parvient pas à se synchroniser. Assurez-vous que les requêtes atteignent /_matrix/client/unstable/org.matrix.simplified_msc3575/Synapse et ne sont pas envoyées à un proxy MSC3575 résiduel, bloquées par un pare-feu applicatif web ou réécrites par une règle de chemin. Si Synapse s'exécute derrière un proxy, conservez les en-têtes forwarded-protocol et client-IP corrects, tels que décrits dans la documentation de Synapse.
Ne créez pas de nouvelle org.matrix.msc3575.proxyentrée /.well-known/matrix/clientpour la prise en charge native. Cette clé fait référence à l'API proxy obsolète. Si vous l'avez ajoutée précédemment dans un fichier JSON statique connu ou dans la configuration Synapse extra_well_known_client_content, supprimez uniquement cette propriété proxy héritée après avoir vérifié qu'aucun client ancien requis n'en dépend. Conservez les informations de découverte du serveur d'accueil intactes.
true.La base de données du proxy conservait l'état de synchronisation côté proxy au lieu de remplacer l'historique des salles Synapse. Il est toutefois déconseillé de la supprimer lors de la migration initiale : elle sert de référence pour le dépannage de l'ancienne configuration et offre une limite de retour en arrière plus sûre pendant la migration des utilisateurs vers les sessions natives.
Comparez le même client, compte, appareil et réseau avant et après la modification si vous disposez de mesures de référence fiables. Notez le temps écoulé entre l'ouverture de l'application et l'affichage d'une liste de salons utilisable, si les messages récents s'affichent sans délai de chargement et si l'application se met à jour après une brève période hors ligne. Répétez la comparaison plusieurs fois ; un seul lancement peut être faussé par l'état du cache, les conditions du réseau ou le téléchargement d'un fichier multimédia volumineux.
Si le client effectue toujours /syncdes requêtes ordinaires et n'utilise jamais de prise en charge native, vérifiez sa version et ses paramètres de synchronisation. S'il interroge le point de terminaison simplifié mais reçoit une erreur, consultez les journaux Synapse et du proxy inverse pour cette requête. Si de nombreux utilisateurs signalent des ralentissements, vérifiez l'état de la base de données et la charge du serveur. La synchronisation glissante peut réduire la charge de synchronisation, mais ne peut pas compenser une base de données surchargée ou une requête API mal acheminée.
| Approche | Meilleure adaptation | Coût ou limitation |
|---|---|---|
| Synchronisation glissante simplifiée native dans Synapse | Déploiements Synapse nouveaux ou maintenus et clients compatibles | Nécessite un client compatible ; les performances dépendent toujours de l’état du serveur et de la base de données. |
| proxy MSC3575 hérité | Uniquement pour comprendre ou maintenir temporairement une ancienne configuration de test | Archivé, non maintenu et ne répondant plus aux besoins des clients modernes. |
| Synchronisation avec la matrice héritée | Clients ou serveurs domestiques sans prise en charge native de la synchronisation glissante | Continue de fonctionner pour les clients compatibles, mais ne propose pas le même comportement natif de défilement de liste de salles. |
Le dépôt proxy autonome est archivé. L'implémentation native de Synapse date de la version 1.114. L'équipe principale de la spécification Matrix a accepté la proposition MSC4186 en juillet 2026, tandis que les extensions associées restent distinctes. Synapse, les clients mobiles et la spécification Matrix continuent d'évoluer ; consultez donc la documentation et les notes de version pour connaître les versions exactes que vous utilisez.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
