Tutoriales de VPS
Desplegar OpenList (AList) en un VPS (2026): Docker, WebDAV, montaje de nubes, HTTPS y configuración de seguridad
Despliega OpenList (AList) en un VPS con Docker Compose, configura HTTPS con dominio, WebDAV, almacenamiento local y controladores de nubes, y entiende la protección de acceso, la limitación de velocidad, los costes de tráfico, las copias de seguridad, las actualizaciones y los fallos comunes.
Desplegar OpenList (AList) en un VPS (2026): Docker, WebDAV, montaje de nubes, HTTPS y configuración de seguridad
Si quieres reunir Alibaba Cloud Drive, OneDrive, Google Drive, S3, WebDAV o discos locales detrás de un único punto de entrada web, OpenList es una de las opciones autoalojadas más populares ahora mismo. Es un fork de AList impulsado por la comunidad y admite vistas previas de archivos, enlaces directos, WebDAV, reproducción en línea, copia entre almacenamientos y muchos controladores de almacenamiento en la nube.
Este tipo de proyectos se malinterpreta a menudo como "una vez instalado, tienes una nube sin límite de velocidad". La velocidad real sigue dependiendo de la API de la nube, de la red entre el VPS y el almacenamiento, de los permisos de la cuenta, de los límites del proveedor y del ancho de banda de salida. Este artículo solo trata el uso de OpenList con cuentas de almacenamiento y archivos para los que tienes autorización, y no cubre la elusión de permisos de plataforma, límites de descarga ni reglas de compartición.
OpenList encaja en estos casos:
- Quienes quieren fusionar varias nubes personales o buckets de almacenamiento de objetos en un único directorio de archivos;
- Quienes quieren dar a los miembros de la familia o a un equipo pequeño un punto de entrada unificado para explorar archivos;
- Quienes necesitan WebDAV para que ordenadores, móviles o software multimedia accedan a directorios remotos;
- Quienes quieren discos locales del VPS, S3 y nubes en la misma interfaz de gestión;
- Quienes necesitan vistas previas, enlaces directos, compartición temporal, reproducción de vídeo en línea o copia entre almacenamientos.
Si necesitas colaboración entre varias personas, auditoría de permisos, historial de versiones y clientes de sincronización, Nextcloud, Seafile o una nube comercial encajan mejor. OpenList es más bien una "capa de agregación y acceso al almacenamiento" y no debería tratarse como tu única copia de seguridad.
El programa principal de OpenList es muy ligero; lo que realmente consume recursos son las miniaturas, la reproducción de vídeo en línea, el empaquetado de archivos, la caché, las descargas con aria2 y los accesos concurrentes múltiples.
| Escenario | Configuración recomendada | Notas |
|---|---|---|
| Navegación personal y enlaces directos | 1 núcleo, 1 GB, SSD de 20 GB | Montar solo poco almacenamiento, sin transcodificación |
| Uso familiar y WebDAV | 2 núcleos, 2 GB, NVMe de 40 GB | Dejar espacio para caché, registros y sistema |
| Varios almacenamientos, reproducción en línea | 2–4 núcleos, 4 GB, NVMe de 60 GB | Vigilar el ancho de banda de salida y el número de conexiones |
| Equipo pequeño o punto de entrada público de archivos | 4 núcleos, 8 GB, NVMe de 100 GB+ | Requiere limitación de velocidad, monitorización, copias de seguridad y auditoría |
Si los archivos están realmente en nubes, no necesitas comprar un disco local de VPS muy grande; si quieres usar almacenamiento local, cachear miniaturas o ejecutar descargas sin conexión, la capacidad de disco debe calcularse según el crecimiento de los datos. Puedes empezar leyendo Cómo elegir la configuración de un VPS y ¿Necesita un VPS almacenamiento de objetos?.
| Opción | Posicionamiento principal | Más adecuado para | Principales contrapartidas |
|---|---|---|---|
| OpenList | Agrega muchas nubes y almacenamiento local | Quienes quieren acceso unificado a varios almacenamientos | La autorización de cuentas, los límites del proveedor y las diferencias entre controladores hay que gestionarlos uno mismo |
| AList | El proyecto original y su ecosistema | Quienes tienen configuraciones antiguas o dependen de tutoriales antiguos | Confirmar el mantenimiento del proyecto y el estado de la versión antes de migrar |
| Cloudreve | Nube autoalojada y subidas de usuarios | Quienes necesitan usuarios, cuotas, subidas y un sistema de compartición | Mayor coste de despliegue y mantenimiento de la base de datos |
| Nextcloud | Colaboración, sincronización, permisos y plugins | Colaboración de archivos en equipo | Mayor uso de recursos y complejidad de actualización |
| Seafile | Sincronización de archivos eficiente | Sincronización multidispositivo y discos de equipo | Requiere planificar por separado la base de datos y el almacenamiento |
La ventaja de OpenList no es sustituir todas las nubes, sino poner el almacenamiento existente detrás de un punto de entrada unificado. Si necesitas recuperar realmente tus datos en tu propio servidor, deberías planificar directamente almacenamiento local, almacenamiento de objetos y copias de seguridad, en lugar de solo montar nubes de terceros.
Usa un Ubuntu 22.04/24.04 LTS o Debian 12 limpios. Primero confirma que Docker está disponible:
docker version
docker compose version
Crea el directorio de datos y restringe los permisos:
sudo mkdir -p /etc/openlist
sudo chmod 750 /etc/openlist
cd /opt
sudo mkdir -p openlist
sudo chown -R "$USER":"$USER" /opt/openlist
cd /opt/openlist
El directorio de datos de OpenList contiene la base de datos, la configuración, los usuarios, los controladores de almacenamiento y el estado de ejecución. No lo pongas en un directorio temporal y no montes el directorio raíz del host directamente en el contenedor.
El Compose oficial usa la imagen openlistteam/openlist y monta el /etc/openlist del host en el /opt/openlist/data del contenedor. En producción se recomienda fijar la versión; empieza con la v4.2.4 confirmada actualmente:
services:
openlist:
image: openlistteam/openlist:v4.2.4
container_name: openlist
restart: unless-stopped
user: "0:0"
environment:
UMASK: "022"
TZ: Asia/Shanghai
volumes:
- /etc/openlist:/opt/openlist/data
ports:
- "127.0.0.1:5244:5244"
- "127.0.0.1:5245:5245"
Guárdalo como /opt/openlist/compose.yaml e inicia:
cd /opt/openlist
docker compose up -d
docker compose ps
docker compose logs --tail=100 openlist
Vincular el puerto solo a 127.0.0.1 sirve para que internet solo pueda acceder a través del proxy inverso. El ejemplo oficial mapea directamente 5244 y 5245, pero en un VPS público no es aconsejable exponer el puerto de gestión original a internet.
Para ver la información inicial, revisa primero los registros del contenedor:
docker logs openlist --tail=100
Tras el primer inicio de sesión, cambia de inmediato la contraseña de administrador y la ruta de entrada segura, y guarda la información de recuperación. No escribas contraseñas iniciales, cookies ni tokens de almacenamiento en repositorios públicos.
Prepara un dominio dedicado, por ejemplo drive.example.com, y apunta el registro A al VPS. Puedes usar Caddy, Nginx o 1Panel como proxy inverso. Con Caddy como ejemplo:
drive.example.com {
reverse_proxy 127.0.0.1:5244
}
Caddy solicitará los certificados automáticamente, pero solo si el DNS, los puertos 80/443, el firewall y la hora del servidor son correctos. Cuando el panel o la configuración del proxy estén listos, prueba:
curl -I https://drive.example.com
Si encuentras fallos en la solicitud de certificados, bucles de redirección o errores de conexión al upstream, consulta Guía completa para usar Caddy como proxy inverso en un VPS y Solución de bucles de redirección HTTPS en un sitio web de VPS.
No añadas 5244, 5245, los puertos de base de datos ni el Docker Socket al grupo de seguridad público. WebDAV también debe ir por HTTPS; no transmitas contraseñas de cuenta por HTTP en texto plano.
No uses admin, el prefijo del correo ni el nombre del sitio como cuenta de administrador. Usa una cadena larga aleatoria para la contraseña y establece para la entrada de administración una ruta que no sea fácil de escanear. La entrada segura no es la única protección; debe combinarse con HTTPS, limitación de intentos de inicio de sesión y copias de seguridad.
Al compartir directorios públicamente, no hagas que todo el directorio raíz sea legible de forma anónima. Establece contraseñas o requisitos de inicio de sesión para directorios sensibles y fija tiempos de caducidad para los enlaces públicos. Al probar, usa un directorio dedicado no sensible; no experimentes directamente en la raíz de una nube privada.
Si solo lo usas tú, puedes restringir la IP de origen de la ruta de administración en el firewall de la nube o en la capa de proxy inverso. Cuando las direcciones de red móvil cambian con frecuencia, usar WireGuard o Tailscale para entrar en la red interna y luego acceder a la página de administración de OpenList suele ser más fiable que abrir el panel a todas las IPv4.
Los tokens de refresco de nubes, las cookies, los secretos de cliente y los S3 Secret son credenciales muy sensibles. No los expongas en capturas de pantalla, registros, tickets ni repositorios Git. Al cambiar contraseñas de cuenta, revocar autorizaciones o sospechar una filtración, revoca el token antiguo en la plataforma de origen y vuelve a vincular.
La configuración de almacenamiento de OpenList suele incluir tipo de controlador, ruta de montaje, ordenación, directorio raíz y parámetros de autorización. Se recomienda añadirlos en el siguiente orden:
- Primero añade un directorio de prueba local vacío;
- Confirma que el listado, la vista previa, la descarga y los permisos funcionan;
- Luego añade un almacenamiento S3 o WebDAV de bajo riesgo;
- Por último añade nubes con muchos archivos;
- Por cada controlador añadido, prueba la lectura de directorios, la descarga de un archivo y la descarga de archivos grandes.
El directorio de almacenamiento local debe ser una ruta accesible para el contenedor. Si quieres montar el /srv/files del host, debes añadir en Compose un montaje explícito de solo lectura o de lectura y escritura:
volumes:
- /etc/openlist:/opt/openlist/data
- /srv/files:/srv/files:ro
El modo de solo lectura es adecuado para mostrar y descargar archivos. Si habilitas la subida, el borrado, el renombrado o el movimiento desde la web, se necesita permiso de lectura y escritura, pero el riesgo también es mayor. No montes /, /home ni directorios que contengan claves SSH.
El almacenamiento S3 suele requerir Endpoint, Region, Bucket, Access Key, Secret Key y ruta raíz. Se recomienda crear una Access Key de privilegio mínimo específica para OpenList, que solo permita acceder al Bucket o prefijo especificado; no reutilices una clave maestra con permisos de toda la cuenta.
El almacenamiento de objetos es adecuado para imágenes, vídeos, copias de seguridad y archivos grandes, pero hay que calcular el tráfico de salida, el número de solicitudes y los costes de descarga. El punto de entrada web de OpenList no elimina los costes del almacenamiento de objetos de origen; especialmente cuando los enlaces directos reciben muchas visitas, configura límites de velocidad y alertas de ancho de banda.
WebDAV es adecuado para conectar con servicios de archivos autoalojados existentes o almacenamiento de oficina. Al configurarlo, confirma la URL HTTPS, el usuario, la contraseña y la ruta raíz, y prueba primero la lectura y escritura de archivos pequeños. El rendimiento y los mecanismos de bloqueo de WebDAV dependen del servicio de origen, por lo que no conviene tratarlo a ciegas como una capa de distribución de archivos de alta concurrencia.
Estos controladores requieren completar la autorización según la interfaz actual de OpenList y la documentación oficial. El inicio de sesión, los tokens de refresco, las unidades familiares, las unidades compartidas y las políticas regionales pueden cambiar según la plataforma, así que no copies cookies ni parámetros de tutoriales antiguos directamente en producción.
Tras una autorización correcta, monta primero un directorio de prueba y luego verifica:
- Si la lista de archivos está completa;
- Si los nombres de archivo en chino se muestran correctamente;
- Si las vistas previas de vídeo e imagen funcionan;
- Si los enlaces directos funcionan como se espera en un navegador sin sesión iniciada;
- Si los registros filtran información de autorización cuando falla una descarga.
Monta solo cuentas y archivos a los que tú o tu equipo tengáis autorización de acceso, y cumple los términos de servicio y las normas de derechos de autor de las nubes de origen.
OpenList puede servir como punto de entrada WebDAV, permitiendo que sistemas o aplicaciones accedan a directorios remotos. Al usarlo, ten en cuenta:
- No uses la cuenta de administrador como usuario de WebDAV;
- Crea un usuario separado de bajo privilegio para WebDAV;
- Accede por HTTPS;
- Establece permisos de directorio más estrictos para las operaciones de subida y borrado;
- Prueba primero archivos pequeños y luego archivos grandes y transferencias reanudables;
- No expongas el puerto WebDAV directamente al escaneo de internet.
Si quieres proporcionar un directorio multimedia a Jellyfin, un reproductor o una herramienta de descarga, es preferible que la aplicación acceda a un montaje local estable o a S3, en lugar de hacer pasar todo el tráfico por el proxy de OpenList. La reproducción a través del proxy consume ancho de banda de salida y conexiones del VPS; si hay tirones en horas punta, revisa al mismo tiempo la nube de origen, la ruta del VPS y la salida pública.
La capa de acceso de OpenList no es una CDN. Los siguientes tipos de tráfico son los que más fácilmente disparan la factura:
- Gran cantidad de reproducción de vídeo en línea;
- Enlaces directos públicos rastreados por motores de búsqueda o scripts;
- Descargas de carpetas empaquetadas;
- Subidas de visitantes que se reenvían repetidamente;
- Varios usuarios descargando al mismo tiempo desde el mismo VPS.
Se recomienda separar por uso:
- Pon imágenes públicas y archivos estáticos en almacenamiento de objetos con CDN;
- Accede a los archivos privados mediante inicio de sesión o enlaces temporales;
- Permite el panel de administración solo desde orígenes fijos;
- Establece límites de velocidad y tiempos de caducidad para las descargas anónimas;
- Configura alertas de tráfico tanto en el VPS como en el almacenamiento de objetos.
Puedes contrastar con vnStat, los gráficos de tráfico del proveedor de nube y los registros de OpenList. El artículo del sitio Monitorización de tráfico de VPS y alertas de exceso es útil para seguir investigando anomalías de ancho de banda.
Como mínimo, haz copia de:
- El directorio de datos
/etc/openlist; compose.yaml;- La configuración del proxy inverso;
- El dominio y los registros DNS;
- La lista de controladores de almacenamiento;
- Las notas de recuperación de autorizaciones de nubes;
- Temas personalizados, scripts y tareas externas.
Copiar solo el directorio de datos de OpenList no equivale a copiar los archivos de las nubes. OpenList guarda sobre todo índices, configuración e información de autorización; los archivos reales siguen en el disco local o en el almacenamiento en la nube de origen.
Antes de actualizar, registra la imagen actual:
docker inspect openlist --format '{{.Config.Image}}'
docker compose config > compose.before-upgrade.yaml
Luego haz copia del directorio de datos:
sudo tar -czf /opt/openlist-data-$(date +%F).tar.gz /etc/openlist
Copia el archivo a otra máquina o al almacenamiento de objetos y luego descarga la nueva versión. No reconstruyas latest en producción sin copia de seguridad. Tras actualizar, comprueba primero el inicio de sesión, las listas de almacenamiento, los enlaces directos, WebDAV y las descargas, y luego decide si mantener la nueva versión.
Al revertir, restaura tres partes a la vez:
- La imagen anterior que funcionaba;
- El
/etc/openlistde antes de la actualización; - El proxy inverso y las variables de entorno.
Si solo reviertes la imagen pero mantienes una estructura de datos ya migrada, puede arrancar correctamente pero no leer la configuración. Antes de una actualización formal, ensaya una vez en un VPS temporal o en un directorio de prueba.
Comprueba el estado del contenedor, la escucha de puertos y las peticiones locales:
docker compose ps
ss -lntp | rg '5244|5245'
curl -I http://127.0.0.1:5244
Si el puerto está vinculado solo a la máquina local, el acceso público debe pasar por el proxy inverso. Comprueba si el upstream del proxy está escrito como la dirección interna del contenedor, la dirección del host o un puerto incorrecto.
Revisa primero los registros de OpenList y los errores del controlador de origen, y luego prueba con un archivo pequeño. Las causas comunes incluyen tokens caducados, ruta raíz incorrecta, respuesta 403 del origen, firmas de tiempo caducadas, permisos insuficientes en el almacenamiento de objetos o conexiones de salida restringidas.
Confirma primero el navegador, el controlador de origen y la codificación real del archivo, y luego revisa la versión y los registros del controlador. No renombres en lote los archivos originales de inmediato; reproduce el problema en un directorio de prueba y conserva las rutas originales.
Comprueba HTTPS, usuario, contraseña, ruta y si el proxy inverso admite los métodos WebDAV. Algunos proxies solo permiten GET/POST por defecto y pueden bloquear PROPFIND, PUT, DELETE. Conecta primero un cliente de escritorio a un directorio de prueba y luego abre el directorio de producción.
Prueba por separado el enlace directo de la nube de origen, la velocidad del VPS al origen, la salida pública del VPS y la ruta del cliente. No mires solo la CPU del VPS. En descargas a través de proxy, el ancho de banda, el número de conexiones, los límites del origen y los costes de salida del almacenamiento de objetos suelen ser más críticos que la CPU.
OpenList puede conectarse a muchos servicios de almacenamiento, pero "técnicamente montable" no significa "se puede compartir públicamente sin más". Antes de publicarlo, confirma:
- Que las cuentas y archivos están dentro del ámbito autorizado para ti o tu equipo;
- Que la compartición, la reproducción en línea y las descargas cumplen los términos de la plataforma de origen;
- Que los archivos con derechos de autor tienen un uso legítimo;
- Que no se usa el servicio para eludir controles de acceso, límites de descarga o restricciones regionales;
- Que los directorios públicos tienen autenticación, enlaces con caducidad y registros de acceso activados;
- Que no se entregan cookies, tokens ni archivos privados de cuentas de terceros a administradores no confiables.
Si el objetivo es la colaboración de archivos en equipo, prioriza un sistema con miembros, auditoría, revocación y control de versiones, en lugar de exponer directamente la raíz de una nube.
Los usuarios individuales pueden empezar con un VPS de 2 núcleos, 2 GB y NVMe de 40 GB ejecutando OpenList, Caddy y unos pocos controladores de almacenamiento. Cuando crezca el volumen de archivos, empiece la reproducción en línea o accedan varias personas, amplía memoria, disco y ancho de banda, y migra los archivos grandes al almacenamiento de objetos.
El orden de puesta en marcha recomendado es:
- Fijar la versión de OpenList y persistir
/etc/openlist; - Escuchar solo en el puerto local;
- Acceder mediante un dominio dedicado y HTTPS;
- Crear un usuario de bajo privilegio y un almacenamiento de prueba;
- Configurar límites de velocidad, alertas de tráfico y copias de seguridad externas;
- Verificar con archivos pequeños, archivos grandes, WebDAV y un simulacro de recuperación;
- Solo entonces abrir la compartición de equipo o pública.
OpenList es más adecuado como "punto de entrada unificado y capa de acceso". Siempre que planifiques con antelación la autorización, la red, las copias de seguridad y los límites de coste, puede hacer que las múltiples nubes y el almacenamiento autoalojado sean más fáciles de gestionar.