Quando l'apertura o l'accesso a una stanza Matrix richiede molto tempo, è necessario innanzitutto determinare se il ritardo riguarda un singolo server remoto, una singola stanza o l'intera istanza di Synapse. Questa distinzione è importante: la federazione è uno scambio bidirezionale tra server e l'accesso a una stanza può coinvolgere diversi server. I ritardi nell'accesso possono essere causati dal processo Synapse, dal server remoto, dal routing DNS o TLS, dal database o dalle dimensioni e dallo stato della stanza. Non esiste un singolo parametro per la "lentezza della federazione" che risolva tutti questi problemi.
Verificato: Synapse registra le informazioni sui tentativi di connessione alla destinazione remota, espone le metriche di Prometheus e include i limiti di velocità per le connessioni alle stanze. Dipende dalla situazione: quale di questi fattori è responsabile di una singola connessione lenta. Non desumibile dal solo sintomo: se l'altro homeserver o una rete intermedia è lenta. Inizia con un utente interessato, una stanza e il tempo approssimativo di un tentativo lento; confronta questi dettagli con una stanza di controllo che si connette normalmente.
Utilizza il tester ufficiale di federazione Matrix con il nome del server Matrix del tuo homeserver. Può rivelare problemi comuni di DNS, delega, certificati e raggiungibilità. Il nome del server negli ID utente potrebbe differire dalla macchina o dal proxy che ospita Synapse, quindi verifica l'endpoint di federazione e la delega configurati anziché presumere che il dominio dell'ID utente ospiti direttamente Synapse.
La documentazione di Synapse sulla federazione indica come porta di federazione predefinita la TCP 8448, mentre le implementazioni con delega o proxy inverso possono utilizzare HTTPS sulla porta 443. La porta pertinente deve essere raggiungibile dagli altri homeserver e potrebbe essere necessario consentire il traffico di federazione anche sui firewall in uscita. Verificare la corrispondenza delle regole del firewall in entrata e in uscita, quindi eseguire nuovamente il test con il Federation Tester. Non aprire entrambe le porte indiscriminatamente se l'implementazione è configurata per utilizzarne solo una.
Un risultato che mostra un errore di certificato, DNS o di routing indica un problema di configurazione o di raggiungibilità della rete, non di capacità del server. Esaminare i record DNS e la delega per il nome del server Matrix, la catena di certificati TLS del proxy inverso e verificare se il proxy inoltra i percorsi di federazione a Synapse. Synapse documenta che in alcune configurazioni i server federati non seguono un reindirizzamento permanente 308, quindi è necessario esaminare anche i reindirizzamenti imprevisti. Correggere il controllo specifico non riuscito e ripetere il test prima di modificare il numero di worker o i limiti di velocità.
Riferimenti: Configurazione e risoluzione dei problemi della federazione Synapse e Guida al firewall Synapse .
Synapse contrassegna temporaneamente una destinazione remota come offline dopo che le richieste di federazione non sono andate a buon fine. I ritardi nei tentativi di connessione utilizzano un meccanismo di backoff, pertanto ripetuti errori possono far apparire ritardati i messaggi o le connessioni che coinvolgono tale destinazione. Questo non significa necessariamente che l'intero server domestico sia lento: potrebbe trattarsi di un singolo server remoto irraggiungibile o che non riesce a inviare le richieste.
Gli amministratori possono esaminare l'API di amministrazione della federazione di Synapse, che documenta GET /_synapse/admin/v1/federation/destinations. Utilizzare un token di accesso server-admin e mantenerlo privato. Esaminare i record di destinazione e i campi di retry per l'homeserver coinvolto nella stanza interessata. Questi record aiutano a identificare quando una destinazione sta ritentando la connessione, ma da soli non dimostrano il motivo del fallimento della connessione. Correlare questi dati con i log di Synapse, i log del proxy, i test DNS/TLS e gli orari in cui gli utenti hanno segnalato problemi.
L'API di amministrazione della federazione è documentata come sperimentale e soggetta a modifiche. Evitate di utilizzarla tramite script come se fosse un'API client pubblica stabile. Synapse documenta anche un'operazione di reset-connection-timeout che può innescare un nuovo tentativo in background per una destinazione già in cooldown. Consideratela un'azione diagnostica o di ripristino solo dopo aver corretto o compreso l'errore sottostante; la cancellazione ripetuta dei cooldown non può far rispondere un server remoto non funzionante. Una risposta HTTP positiva dall'endpoint di reset non significa che il tentativo di federazione in background sia già stato completato.
Riferimento: API di amministrazione di Synapse Federation . Lo stato sperimentale dell'API e i campi disponibili possono variare a seconda della versione di Synapse, pertanto si consiglia di verificare la documentazione relativa alla versione in uso prima di eseguire qualsiasi operazione.
Abilita l'endpoint delle metriche Prometheus di Synapse solo su una rete interna fidata o dietro controlli di accesso. La guida ufficiale al monitoraggio documenta /_synapse/metricse mostra come esporlo tramite un listener di metriche o un listener HTTP esistente. Le metriche possono includere dettagli operativi; non pubblicare questo endpoint apertamente. Se raccogli già metriche, confronta il tempo di un join lento con CPU, memoria, latenza della richiesta, durata della transazione del database e attività di federazione in entrata e in uscita.
Utilizzate i grafici per distinguere un sovraccarico generalizzato dai ritardi specifici della federazione. Se le normali richieste dei client e le transazioni del database rallentano contemporaneamente alle operazioni di join, verificate la pressione della CPU e della memoria dell'host, lo stato di PostgreSQL, i limiti di connessione, la latenza del disco e le query di lunga durata. Se l'attività della stanza locale rimane reattiva ma una destinazione remota presenta errori o ritardi nei tentativi di connessione, date priorità alla raggiungibilità della federazione e a quel server remoto. Se è interessata solo una stanza di grandi dimensioni, lo stato della stanza e il numero di server partecipanti potrebbero contribuire al problema; confrontatelo con una stanza più piccola prima di trarre conclusioni.
La guida Grafana di Synapse consiglia di controllare il tempo di invio dei messaggi, la CPU e la memoria, il numero e la durata delle transazioni del database e i grafici di federazione. Un elevato numero di transazioni non è automaticamente il collo di bottiglia; anche la durata e il carico del sistema sono importanti. Verifica i nomi delle metriche della versione di Synapse installata e la documentazione del dashboard, poiché i nomi delle metriche sono stati modificati nel tempo.
Riferimenti: Monitoraggio di Synapse con Prometheus e comprensione di Synapse tramite i grafici di Grafana .
Synapse ha rc_joinslimiti separati per gli accessi locali e per quelli remoti. Un accesso remoto può richiedere più lavoro rispetto all'accesso a una stanza a cui il server partecipa già. Synapse dispone anche di rc_joins_per_roomuna funzione che limita gli accessi recenti a una stanza per contribuire a mitigare i picchi di accessi di massa. Se i log o le risposte del client indicano una limitazione della frequenza, verificare queste impostazioni e il volume degli accessi recenti prima di modificarle.
Non aumentare i limiti di velocità come soluzione generica per "migliorare le prestazioni". Limiti più elevati possono aumentare il carico sul server e sugli altri server domestici, e potrebbero ridurre la protezione contro i picchi di join. Se un'operazione di migrazione o onboarding legittima sta raggiungendo un limite configurato, identifica il limite esatto e verifica i valori documentati per la tua versione di Synapse. Valuta la possibilità di distribuire il carico di lavoro dei join nel tempo. Modifica un valore rilevante alla volta, mantieni la configurazione precedente e monitora i tassi di errore e l'utilizzo delle risorse dopo il ricaricamento o il riavvio, come richiesto dalla tua implementazione.
Riferimento: Configurazione di Synapse:rc_joins e Configurazione di Synapse:rc_joins_per_room . Le impostazioni predefinite e le opzioni supportate possono variare a seconda della versione; confrontale con la versione installata prima di modificarle.
Ripeti lo stesso test di join dopo la modifica. Verifica che l'utente si unisca correttamente, che la destinazione interessata non presenti più errori ripetuti, che il Federation Tester segnali correttamente i controlli pertinenti e che la latenza della richiesta/del database torni al suo intervallo normale. Monitora la ricomparsa del problema durante un successivo periodo di picco; un singolo tentativo riuscito non garantisce che il server remoto o la rete siano sempre funzionanti.
Se le metriche locali e i controlli di federazione risultano corretti, ma solo un homeserver remoto continua a presentare problemi, condividi con gli amministratori di tale server il timestamp, la destinazione, l'errore (opportunamente formattato) e gli ID delle richieste pertinenti. Se diverse stanze e destinazioni sono interessate, oltre alle richieste locali lente, verifica la capacità di Synapse e PostgreSQL prima di ottimizzare il comportamento della federazione. Annota la versione di Synapse nelle note dell'incidente, poiché la configurazione e i dettagli dell'API di amministrazione sono soggetti a modifiche.
Risolvi l'avviso di Nextcloud relativo alla mancanza di HSTS configurando il server web HTTPS o il proxy inverso, quindi verifica in modo sicuro l'intestazione Strict-Transport-Security.
Risolvi l'errore "CSync Unknown Error" del client ownCloud Desktop ricostruendo il database di sincronizzazione nascosto, quindi verifica la connettività, le autorizzazioni, i nomi dei file, lo spazio su disco e i log.
Il proxy Matrix Sliding Sync è stato archiviato e sostituito. Abilitare la sincronizzazione Simplified Sliding Sync nativa in Synapse, verificare il supporto del client, aggiornare il routing del proxy e testare la sincronizzazione mobile in modo sicuro.
Diagnostica i rallentamenti nella federazione Matrix Synapse e nell'adesione alle stanze verificando la connettività, lo stato dei tentativi del server remoto, le metriche, il carico del database e i limiti di frequenza di adesione.
Configura la conservazione del cestino e le attività in background di Nextcloud per rimuovere automaticamente i file eliminati, verificare l'avvenuta pulizia ed evitare comandi di eliminazione sicura per tutti gli utenti.
Diagnostica l'eco di BigBlueButton e il ritardo audio di WebRTC separando il feedback del microfono dal ritardo di rete, verificando il test dell'eco, i dispositivi del browser, la connettività UDP e il carico del server.
Configura un repository Restic crittografato e un'attività pianificata (cron job) per Nextcloud, includendo la modalità di manutenzione, un dump di MariaDB, la conservazione dei dati, i log e i controlli di ripristino.
Risolvi i problemi di caricamento su ownCloud bloccati al 99% controllando i log, lo spazio di archiviazione temporaneo, lo spazio dei chunk, i limiti PHP, le sessioni, i proxy e il blocco dei file nell'ordine corretto.
Abilita e applica correttamente l'autenticazione a due fattori (2FA) di Zimbra, registra un account amministratore, scegli la verifica tramite TOTP o e-mail e testa l'accesso alla Console di amministrazione.
Configura Mjolnir per la moderazione di Matrix: crea un account bot dedicato, configura la sua sala di controllo, proteggi le stanze, gestisci le liste di ban e verifica le autorizzazioni in modo sicuro.
