El mensaje "Conexión rechazada" en la aplicación móvil de ownCloud suele indicar un problema de conectividad incluso antes de que comience la autenticación: el teléfono llegó a una dirección, pero ningún servidor aceptó la conexión en el punto final de red solicitado. La redacción exacta puede variar según la versión de Android o iOS, por lo que conviene considerarlo un síntoma, no un diagnóstico.
Escenario ilustrativo: imagine una pequeña empresa de diseño llamada Northstar Studio. Su personal normalmente se conecta a https://cloud.example.com/owncloudtravés de la aplicación móvil ownCloud. Tras un cambio de proxy inverso, varios teléfonos muestran el mensaje "Conexión rechazada". La interfaz web de ownCloud sigue funcionando desde el portátil de un administrador en la oficina, pero no con datos móviles. Este escenario ficticio se utilizará a lo largo de la guía para mostrar cómo se combinan los pasos de solución de problemas; no se trata de un informe de una implementación real ni de un resultado de prueba.
No comience por restablecer la contraseña del usuario. Una contraseña incorrecta, un token caducado o un problema de OAuth ocurren después de que el cliente puede comunicarse con el servidor. Una conexión TCP rechazada suele estar relacionada con un host o puerto incorrecto, un servidor web o proxy detenido, una regla de firewall o un servicio que solo escucha en una interfaz interna.
La documentación móvil actual de ownCloud confirma que las aplicaciones se configuran con la URL del servidor ownCloud. La documentación de ownCloud WebDAV también indica que las aplicaciones móviles deben usar la URL base y la carpeta, como example.com/owncloud, en lugar de ingresar manualmente un punto final WebDAV. Consulte la documentación de acceso a ownCloud WebDAV .
En el ejemplo de Northstar, la URL esperada es https://cloud.example.com/owncloud. Verifique los cuatro componentes: esquema, nombre de host, puerto opcional y ruta. Los errores comunes incluyen usar http://cuando el servicio público solo escucha en HTTPS, omitir un puerto no estándar, usar un nombre de host interno que no se puede resolver fuera de la oficina o ingresar un punto final DAV en lugar de la URL base de ownCloud.
La documentación de Android indica que la aplicación prueba la conexión tras introducir la URL del servidor y las credenciales, y recomienda un servidor con SSL habilitado para que la conexión utilice HTTPS. La documentación de iOS también comprueba la URL del servidor, el método de autenticación y el certificado TLS al añadir una cuenta. Consulta la guía de conexión de ownCloud para Android y la guía de cuenta de ownCloud para iOS .
En el teléfono afectado, abre la URL exacta de ownCloud en un navegador. Esto suele ser un indicador clave. Si el navegador carga la página de ownCloud pero la aplicación no, investiga el certificado específico de la aplicación, la redirección, la autenticación OAuth o la configuración de la cuenta. Si tanto el navegador como la aplicación fallan en la misma red, continúa con las comprobaciones del servidor y la red.
También realiza pruebas desde más de una red. En nuestro ejemplo ilustrativo de Northstar, la conexión Wi-Fi de la oficina funciona, pero los datos móviles fallan. Esto apunta a un problema de exposición de DNS público, cortafuegos, NAT o proxy inverso, en lugar de un problema con el nombre de usuario de ownCloud.
Desde una máquina que pueda acceder al servidor, pruebe la URL y el socket de escucha. Comandos como los siguientes son puntos de partida útiles:
curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'Una respuesta HTTP exitosa no tiene por qué ser necesariamente 200una redirección; esta también puede demostrar que un servicio web está respondiendo. La clave está en si se acepta una conexión TCP. Si ningún servicio escucha en el puerto público esperado, solucione este problema antes de modificar la configuración de la aplicación ownCloud.
Muchas implementaciones de ownCloud colocan Apache, NGINX, HAProxy, Traefik u otro proxy delante de la aplicación. Asegúrese de que el servicio público esté en funcionamiento, vinculado a la interfaz prevista y reenviando el tráfico al backend de ownCloud. Un proxy detenido, vinculado solo a una interfaz 127.0.0.1o configurado para un puerto de subida incorrecto puede provocar un rechazo inmediato.
ownCloud documenta explícitamente los proxies inversos y requiere que las direcciones de proxy en las que ownCloud debería confiar se configuren en trusted_proxies. También documenta la configuración de sobrescritura para los casos en que la detección automática de nombre de host, protocolo o raíz web falla detrás de un proxy. Consulte la guía de configuración de proxy inverso de ownCloud .
Si HTTPS funciona en el propio servidor pero no desde un teléfono fuera de la LAN, revise el firewall del host, el grupo de seguridad en la nube, el enrutador o la regla NAT, y cualquier firewall corporativo anterior. Para una implementación HTTPS normal, el puerto TCP 443 debe ser accesible en la dirección pública. Si utiliza intencionadamente un puerto personalizado, este debe estar expuesto e incluido en la URL.
No desactive el firewall como solución permanente. En su lugar, identifique el oyente necesario y permita solo el tráfico que su diseño requiera. En el caso de Northstar, la pregunta clave no es "¿Está activado el firewall?", sino "¿Puede un cliente externo acceder a la dirección y el puerto publicados para ownCloud?".
Un problema con el certificado es diferente de un rechazo literal de TCP, pero suele aparecer inmediatamente después de solucionar el problema de conectividad. La documentación actual de iOS indica que la aplicación comprueba los certificados TLS al añadir un servidor y permite al usuario inspeccionar los detalles del certificado. La documentación de Android también describe advertencias para los certificados que no se pueden verificar.
Utilice un certificado cuyo nombre de host coincida con el nombre de host público de ownCloud y cuya cadena sea de confianza para el dispositivo siempre que sea posible. Revise también las redirecciones HTTP a HTTPS. La documentación de seguridad de iOS indica que las redirecciones durante el inicio de sesión no se siguen automáticamente; se solicita la aprobación del usuario. Consulte la documentación de seguridad de ownCloud para iOS .
Una vez que el servidor web acepte conexiones, verifique que ownCloud reconozca el nombre de host utilizado por el teléfono. ownCloud requiere que las URL utilizadas para acceder al servidor estén permitidas trusted_domains. Esto es importante cuando se introduce un nuevo nombre de host público, se migra el servicio o se expone una instalación que antes era interna.
Para una instalación clásica, inspeccione la configuración en lugar de editarla a ciegas. Puede usar esto occpara leer los dominios configurados:
sudo -u www-data ./occ config:system:get trusted_domainsSi falta el nombre de host público, agréguelo usando la occ config:system:setsintaxis documentada para un índice de matriz no utilizado. La referencia oficial del comando está disponible en la documentación del comando occ de ownCloud . Para implementaciones de contenedores, la documentación actual de ownCloud expone configuraciones equivalentes relacionadas con el dominio y el proxy a través de variables de entorno como OWNCLOUD_TRUSTED_DOMAINSy OWNCLOUD_TRUSTED_PROXIES.
Vuelve al dispositivo afectado y realiza la prueba en una secuencia controlada: primero, carga la URL en el navegador; luego, añade o vuelve a conectar la cuenta de ownCloud; a continuación, abre la vista de Archivos y confirma que aparece la lista de directorios. Repite el proceso una vez con Wi-Fi y otra con datos móviles si el servicio está diseñado para funcionar en ambas conexiones.
En el ejemplo de Northstar, supongamos que el administrador descubre que el proxy inverso de reemplazo solo escuchaba en el puerto 443 en la interfaz privada. Configurar correctamente el oyente público explicaría por qué el acceso a la oficina funcionaba mientras que el acceso móvil estaba denegado. Esto es solo una ilustración del proceso de razonamiento, no una afirmación sobre un incidente real de ownCloud.
| Lo que observas | Próxima comprobación más útil |
|---|---|
| La aplicación y el navegador del teléfono son rechazados. | Nombre de host público, puerto, oyente, cortafuegos, NAT, servicio proxy |
| Funciona con Wi-Fi pero no con datos móviles. | DNS público y ruta de firewall/NAT/proxy orientada a Internet |
| El navegador funciona, la aplicación se detiene en la revisión del certificado. | Nombre de host TLS, cadena de certificados, redirecciones |
| El servidor responde, pero ownCloud rechaza el host. | trusted_domainsy configuración de sobrescritura del proxy inverso |
| La conexión se establece correctamente, pero el inicio de sesión falla. | Credenciales, OAuth2, autenticación de dos factores o política de tokens |
Evite cambiar contraseñas, configuraciones de base de datos, permisos de archivos o límites de memoria PHP solo porque la aplicación móvil muestre el mensaje "Conexión rechazada". Si bien estas configuraciones pueden ser relevantes para otros fallos de ownCloud, no son lo primero que debe investigar cuando el cliente no puede establecer una conexión de red. Del mismo modo, no ignore permanentemente las advertencias de certificado como sustituto de la corrección de una configuración TLS pública.
A partir de octubre de 2026, ownCloud publica la documentación actualizada para su servidor Classic y sus clientes móviles independientes para Android e iOS. Las etiquetas y pantallas exactas pueden variar entre las distintas versiones de la aplicación, por lo que se recomienda seguir el orden de solución de problemas descrito anteriormente como método habitual: primero, compruebe la conectividad de red; luego, valide el comportamiento del proxy y TLS; y solo entonces acceda a la configuración de la aplicación y la autenticación de ownCloud.
Establezca una fecha de vencimiento máxima para los enlaces públicos de ownCloud Server, comprenda a qué recursos compartidos afecta y verifique la política sin pasar por alto los enlaces más antiguos.
Configure la sincronización automática de la lista global de direcciones (GAL) de Zimbra, establezca el intervalo de sondeo, fuerce una sincronización de prueba, verifique las marcas de tiempo y solucione problemas con contactos LDAP internos o externos obsoletos.
Configure el inicio de sesión basado en LDAP para ownCloud Infinite Scale, asigne usuarios y grupos, elija OIDC integrado o externo, proteja las credenciales y verifique la autenticación de forma segura.
Planifica una migración de ownCloud Classic 10 a Infinite Scale con la aplicación compatible migrate-to-ocis. Descubre qué se transfiere, qué no, los requisitos previos de LDAP, los comandos y las comprobaciones de transición.
Aprende dónde carga Zimbra las reglas personalizadas de SpamAssassin, cómo escribir y validar una regla .cf, reiniciar Amavis, probar los encabezados de los mensajes y revertir los cambios de forma segura.
Realice copias de seguridad y restaure un buzón de correo individual de Zimbra CE con zmmailbox. Exporte un archivo ZIP con metadatos, verifíquelo y pruebe la recuperación de forma segura en una cuenta de prueba.
Aprende a establecer una cuota de espacio personal para un usuario de ownCloud Infinite Scale, a distinguirla de los límites globales y del espacio de proyecto, y a asignar valores predeterminados a los nuevos usuarios según su rol.
Diagnostique los tiempos de espera de registro SIP de BigBlueButton FreeSWITCH comprobando el estado del servicio, los oyentes SIP y ESL, las direcciones NAT, las reglas del firewall y los registros.
Solucione los errores de conexión rechazada de la aplicación móvil ownCloud comprobando la URL del servidor, el puerto HTTPS, el servidor web, el cortafuegos, el proxy, el TLS y los dominios de confianza.
Compara las diferentes formas de controlar las nuevas cuentas de Matrix en Synapse, desde deshabilitar el registro público hasta emitir tokens de uso limitado, con ejemplos de configuración y comprobaciones.
