iceslab
Panel de administración multi-nodo para proxy self-hosted que ejecuta binarios reales de cada protocolo en lugar de empaquetarlos a través de Xray-core.
Ficha actualizada 23 sept 2026, 8:06 · upstream 23 sept 2026, 6:39 · release v0.2.0
Qué es iceslab
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Iceslab es una interfaz de administración self-hosted que gestiona múltiples protocolos de proxy en tiempo real. Diferencia clave respecto a Xray-core: ejecuta el binario nativo del protocolo real (Hysteria 2, Xray REALITY, AmneziaWG, NaiveProxy, Shadowsocks 2022, MTProto, Mieru) en lugar de empaquetarlos todo por capas. Esto permite control granular sobre cada protocolo, uso de mTLS para comunicación entre panel y nodos, y configuración DPI-aware sin necesidad de SSH a los nodos.
El sistema soporta múltiples protocolos simultáneamente mediante un modelo de "node-agent": una instancia del agente se instala en el servidor VPS y gestiona la conexión con cada protocolo. Los nodos se conectan al panel mediante mTLS (protocolo de autenticación mutua), eliminando la necesidad de SSH para aplicar configuraciones.
Se implementa un sistema de cuotas por usuario basado en URL única: se pueden desactivar, revocar o limitar el tráfico sin tocar el protocolo subyacente. Cada cliente puede usar cualquier formato de suscripción (clash, sing-box, xray-json, wireguard, base64) a través de una sola URL.
El panel incluye telemetría en tiempo real del escudo (CPU, RAM, disco), gestión de usuarios con límites por HWID, bot Telegram y autenticación 2FA para el administrador. Es completamente self-hosted bajo licencia AGPL v3.0: los nodos y datos son propiedad del usuario.
La instalación se realiza mediante Docker Compose en Ubuntu 22.04+ o Debian 12+, con un comando único que despliega todo (panel, backend, frontend, Caddy con TLS automático). Para pruebas locales sin TLS se puede ejecutar directamente el binario del panel.
- Gestionar múltiples protocolos de proxy en una sola instancia VPS sin necesidad de múltiples servidores dedicados
- Implementar políticas de tráfico diferenciadas por usuario mediante URL única y cuotas sin modificar la capa protocolaria
- Configurar redes adversas con rutas predefinidas, self-stealing (Xray REALITY) y cascadas multi-nodo (multi-hop)
- Gestionar equipos de usuarios (squads) como límites de acceso por grupo o proyecto
- Monitoreo en tiempo real del escudo con alertas de CPU, RAM y disco, junto con telemetría de uso de memoria por protocolo
- Implementación de autenticación mutua (mTLS) entre panel y nodos para evitar conexiones SSH inseguras
- Gestión de usuarios con límites personalizados por HWID mediante el panel centralizado
- Soporta 7 protocolos nativos en binarios reales: Hysteria 2, Xray REALITY, AmneziaWG, NaiveProxy (fork de Caddy), Shadowsocks 2022, MTProto y Mieru
- Motor SingBox integrado para TUIC, AnyTLS y ShadowTLS sin necesidad de reimplementaciones desde cero
- Comunicación segura entre panel y nodos mediante mTLS en lugar de SSH
- Configuración DPI-aware con recetas predefinidas para redes adversas (Xray REALITY self-steal)
- Un solo URL por usuario: se puede desactivar, revocar o limitar tráfico sin tocar el protocolo subyacente
- Instalación idempotente mediante Docker Compose en Ubuntu 22.04+ y Debian 12+
- El motor SingBox no está confirmado en producción real (solo compilado unitariamente)
- ShadowTLS no soporta el formato de link share con URL "://"
- Xray REALITY requiere que se cree la entrada inbound del panel antes de ejecutar el nodo
- AmneziaWG depende de un kernel DKMS específico y puede fallar en VPSs con hardware incompatible
- NaiveProxy requiere al menos 2 GB de RAM para compilar
- El uso de mTLS introduce una capa adicional de complejidad técnica que no está documentada exhaustivamente
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Instalación: usar Docker Compose con el comando `bash scripts/iceslab.sh` (o `install-iceslab.sh`). Se recomienda configurar un A-record en DNS apuntando a la IP del VPS. Para pruebas locales sin TLS, ejecutar directamente el binario del panel. En producción, se debe desplegar el backend y frontend separadamente para escalar horizontalmente. El nodo agent se instala una sola vez con `--protocol <nombre>` o sin flag (solo bootstrap). Se recomienda usar un A-record en lugar de IP directa por seguridad DNS. Para múltiples protocolos en un solo nodo, crear primero el agente con `--with-singbox` y luego desplegar cada protocolo como binding independiente.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.