Cuando una sala de Matrix tarda mucho en abrirse o unirse, primero determine si la demora afecta a un servidor remoto, a una sala o a toda su instancia de Synapse. Esta distinción es importante: la federación es un intercambio bidireccional entre servidores, y unirse a una sala puede involucrar a varios servidores. Las uniones lentas pueden deberse al proceso de Synapse, al servidor remoto, al enrutamiento DNS o TLS, a la base de datos o al tamaño y estado de la sala. No existe una solución única para el "retraso de la federación" que resuelva todos estos problemas.
Verificado: Synapse registra información sobre reintentos de conexión a destinos remotos, expone métricas de Prometheus e incluye límites de velocidad para las conexiones a salas. Depende de la situación: cuál de estos factores es responsable de una conexión lenta individual. No se puede determinar solo a partir del síntoma: si el otro servidor principal o una red intermedia es lento. Comience con un usuario afectado, una sala y el tiempo aproximado de un intento lento; compare esos detalles con una sala de control que se conecta normalmente.
Utilice el comprobador oficial de federación de Matrix con el nombre del servidor Matrix de su servidor doméstico. Este puede revelar problemas comunes de DNS, delegación, certificados y accesibilidad. El nombre del servidor en los ID de usuario puede diferir del de la máquina o el proxy que aloja Synapse, por lo que conviene comprobar el punto final de federación y la delegación configurados, en lugar de asumir que el dominio del ID de usuario aloja Synapse directamente.
La documentación de federación de Synapse describe el puerto de federación predeterminado como TCP 8448, mientras que las implementaciones delegadas o con proxy inverso pueden usar HTTPS en el puerto 443. El puerto correspondiente debe ser accesible desde otros servidores de origen, y es posible que los firewalls de salida también deban permitir el tráfico de federación. Verifique las reglas de firewall de entrada y salida correspondientes y vuelva a realizar la prueba desde el Probador de federación. No abra ambos puertos indiscriminadamente si su implementación está configurada para usar solo uno.
Un resultado que muestre un error de certificado, DNS o enrutamiento apunta a problemas de configuración o accesibilidad de la red, no a la capacidad del servidor. Revise los registros DNS y la delegación del nombre del servidor Matrix, la cadena de certificados TLS del proxy inverso y si el proxy reenvía las rutas de federación a Synapse. Synapse documenta que, en algunas configuraciones, los servidores federados no siguen una redirección permanente 308, por lo que también debe investigar las redirecciones inesperadas. Solucione el error específico y vuelva a realizar la prueba antes de modificar el número de trabajadores o los límites de velocidad.
Referencia: Configuración y solución de problemas de la federación de Synapse y guía del firewall de Synapse .
Synapse marca temporalmente un destino remoto como fuera de línea después de que fallan las solicitudes de federación. Los retrasos en los reintentos utilizan un mecanismo de retroceso, por lo que los fallos repetidos pueden hacer que los mensajes o las uniones que involucran a ese destino parezcan retrasados. Esto no indica que todo su servidor principal sea lento: puede tratarse de un único servidor remoto inaccesible o que esté fallando en las solicitudes.
Los administradores pueden inspeccionar la API de administración de federación de Synapse, que documenta la información GET /_synapse/admin/v1/federation/destinations. Utilice un token de acceso de administrador del servidor y manténgalo privado. Revise los registros de destino y los campos de reintento para el servidor principal involucrado en la sala afectada. Estos registros ayudan a identificar cuándo un destino está reintentando la conexión, pero por sí solos no demuestran por qué falló la conexión. Correlacione estos datos con los registros de Synapse, los registros del proxy, las pruebas de DNS/TLS y las horas en que los usuarios informaron problemas.
La API de administración de la federación está documentada como experimental y sujeta a cambios. Evite usar scripts como si fuera una API de cliente pública estable. Synapse también documenta una operación de restablecimiento del tiempo de espera de conexión que puede provocar otro intento en segundo plano para un destino que ya se encuentra en tiempo de espera. Considere esto como una acción de diagnóstico o recuperación solo después de corregir o comprender la causa del fallo; borrar repetidamente los tiempos de espera no hará que un servidor remoto defectuoso responda. Una respuesta HTTP exitosa del punto final de restablecimiento no significa que el intento de federación en segundo plano haya finalizado.
Referencia: API de administración de Synapse Federation . El estado experimental de la API y los campos disponibles pueden cambiar con cada versión de Synapse, por lo que conviene verificar la documentación de la versión que utilice antes de usar cualquier operación.
Habilite el punto final de métricas de Prometheus de Synapse únicamente en una red interna de confianza o tras controles de acceso. La guía oficial de monitorización documenta /_synapse/metricsy muestra cómo exponerlo mediante un oyente de métricas o un oyente HTTP existente. Las métricas pueden incluir detalles operativos; no publique este punto final abiertamente. Si ya recopila métricas, compare el tiempo de una unión lenta con el uso de CPU, memoria, latencia de la solicitud, duración de la transacción de la base de datos y actividad de federación entrante y saliente.
Utilice los gráficos para distinguir entre la sobrecarga general y los retrasos específicos de la federación. Si las solicitudes de clientes y las transacciones de la base de datos se ralentizan al mismo tiempo que las uniones, inspeccione la presión de la CPU y la memoria del host, el estado de PostgreSQL, los límites de conexión, la latencia del disco y las consultas de larga duración. Si la actividad de la sala local se mantiene receptiva, pero un destino remoto presenta fallos o retrasos en los reintentos, priorice la accesibilidad de la federación y ese servidor remoto. Si solo una sala grande se ve afectada, el estado de la sala y el número de servidores participantes pueden influir; compárela con una sala más pequeña antes de sacar conclusiones.
La guía de Grafana de Synapse recomienda revisar el tiempo de envío de mensajes, el uso de CPU y memoria, el número y la duración de las transacciones de la base de datos, y los gráficos de federación. Un alto número de transacciones no implica automáticamente un cuello de botella; la duración y la carga del sistema también son importantes. Consulte los nombres de las métricas de su versión de Synapse instalada y la documentación actual del panel de control, ya que las métricas se han renombrado con el tiempo.
Referencias: Synapse Prometheus: monitorización y comprensión de Synapse a través de gráficos de Grafana .
Synapse tiene rc_joinslímites separados para las conexiones locales y remotas. Una conexión remota puede requerir más trabajo que unirse a una sala en la que el servidor ya participa. Synapse también cuenta con rc_joins_per_roomuna función que limita las conexiones recientes a una sala para ayudar a mitigar las oleadas de conexiones masivas. Si los registros o las respuestas del cliente indican que se está aplicando una limitación de velocidad, revise esta configuración y el volumen de conexiones recientes antes de modificarla.
No aumente los límites de velocidad como una solución general para acelerar el proceso. Unos límites más altos pueden aumentar la carga en su servidor y en otros servidores domésticos, y podrían reducir la protección contra ataques de denegación de servicio. Si una migración o incorporación masiva legítima alcanza un límite configurado, identifique el límite exacto y revise los valores documentados para su versión de Synapse. Considere distribuir la carga de trabajo de conexión a lo largo del tiempo. Modifique un valor relevante a la vez, conserve la configuración anterior y supervise las tasas de error y el uso de recursos tras recargar o reiniciar según lo requiera su implementación.
Referencia: Configuración de Synapse:rc_joins y Configuración de Synapse:rc_joins_per_room . Los valores predeterminados y las opciones compatibles pueden variar según la versión; compárelos con la versión instalada antes de editar.
Repita la misma prueba de conexión después del cambio. Confirme que el usuario se conecta correctamente, que el destino afectado ya no falla repetidamente, que el Probador de Federación informa correctamente las comprobaciones pertinentes y que la latencia de la solicitud/base de datos vuelve a su rango normal. Esté atento a la recurrencia durante un período de alta demanda posterior; un intento exitoso no demuestra que el servidor remoto o la red funcionen correctamente de forma constante.
Si las métricas locales y las comprobaciones de federación parecen correctas, pero solo un servidor remoto sigue fallando, comparta la marca de tiempo, el destino, el error anonimizado y los ID de solicitud relevantes con los administradores de ese servidor. Si varias salas y destinos se ven afectados junto con solicitudes locales lentas, investigue la capacidad de Synapse y PostgreSQL antes de ajustar el comportamiento de la federación. Registre su versión de Synapse en las notas del incidente, ya que la configuración y los detalles de la API de administración evolucionan.
Diagnosticar y reducir de forma segura el almacenamiento multimedia de Matrix Synapse, purgar la caché remota, gestionar las cargas locales y configurar la retención para evitar incidentes de disco lleno.
Solucione el problema de la advertencia HSTS faltante en Nextcloud configurando el servidor web HTTPS o el proxy inverso, y luego verifique de forma segura el encabezado Strict-Transport-Security.
Solucione el error "CSync Unknown Error" del cliente de escritorio de ownCloud reconstruyendo la base de datos de sincronización oculta y, a continuación, verifique la conectividad, los permisos, los nombres de archivo, el espacio en disco y los registros.
El proxy Matrix Sliding Sync está archivado y reemplazado. Habilite la sincronización deslizante simplificada nativa en Synapse, verifique la compatibilidad del cliente, actualice el enrutamiento del proxy y pruebe la sincronización móvil de forma segura.
Diagnostique la lentitud en la federación de Matrix Synapse y en las uniones a salas comprobando la conectividad, el estado de reintento del servidor remoto, las métricas, la carga de la base de datos y los límites de velocidad de unión.
Configure la retención de la papelera de Nextcloud y las tareas en segundo plano para eliminar automáticamente los archivos borrados, verificar la limpieza y evitar comandos de purga inseguros para todos los usuarios.
Diagnostica el eco de BigBlueButton y el retardo de audio de WebRTC separando la retroalimentación del micrófono del retardo de la red, comprobando la prueba de eco, los dispositivos del navegador, la conectividad UDP y la carga del servidor.
Configura un repositorio Restic cifrado y una tarea programada (cron job) para Nextcloud, incluyendo el modo de mantenimiento, una copia de seguridad de MariaDB, retención, registros y comprobaciones de restauración.
Solucione los problemas de cargas de ownCloud que se quedan atascadas en el 99 % revisando los registros, el almacenamiento temporal, el espacio de fragmentos, los límites de PHP, las sesiones, los proxies y el bloqueo de archivos en el orden correcto.
Habilite y aplique correctamente la autenticación de dos factores (2FA) de Zimbra, registre una cuenta de administrador, elija la verificación por TOTP o correo electrónico y pruebe el inicio de sesión en la consola de administración.
