EMUNEL
Plataforma proxy multi-protocolo autoalojada con gestión centralizada de instancias, cuotas persistentes y panel móvil-first para VLESS, Trojan, Shadowsocks y VMess.
Ficha actualizada 22 sept 2026, 15:03 · upstream 22 sept 2026, 13:51 · release sin release detectada
Qué es EMUNEL
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
EMUNEL es una plataforma proxy multi-protocolo diseñada para autoalojamiento que permite gestionar múltiples instancias de proxy (VLESS, Trojan, Shadowsocks-AEAD, VMess) detrás de un único dominio HTTPS. Su arquitectura separa el plano de control (Console con FastAPI) del núcleo de relay (Core), con cuotas que se aplican en tiempo real al reenvío de paquetes y persisten incluso tras reinicios o redimensionamientos del contenedor.
La plataforma incluye una caja de herramientas de bypass para SNI Spoofing y REALITY, con 14 motores de pipeline hot-toggle que pueden activarse/desactivarse dinámicamente. El panel web está optimizado para móviles con modo oscuro, navegación inferior en dispositivos táctiles y polling exponencial para logs en tiempo real.
El despliegue soporta Railway (despliegue en un clic), Docker con Dockerfile incluido, o ejecución nativa con Python 3.11+. Soporta SQLite por defecto con opción de PostgreSQL para escalabilidad. Incluye 182 tests unitarios y documentación completa en docs/.
- Autoalojar proxy personal sin depender de servicios externos que puedan bloquear el tráfico
- Gestionar múltiples instancias de proxy desde un único panel con cuotas por usuario persistentes
- Implementar bypass de inspección DPI mediante SNI Spoofing y REALITY en dispositivos cliente
- Proveer configuraciones de proxy a usuarios finales con enlaces v2ray/sing-box/Clash Meta
- Cuotas de tráfico aplicadas en el núcleo del relay, no en dashboard: persisten tras reinicios y redimensionamientos
- 8 protocolos soportados (VLESS WS/xHTTP, Trojan, Shadowsocks-AEAD, VMess con runtime Xray)
- 14 motores de pipeline hot-toggle con estado persistente entre reinicios
- Panel móvil-first con navegación inferior y polling exponencial para logs en tiempo real
- Despliegue Railway en un clic sin variables de entorno requeridas (SQLite auto-provisionado)
- 182 tests unitarios pasando, incluyendo pruebas de estabilidad y volumen
- Requiere Python 3.11+ o Docker con imagen compatible
- El bypass SNI/REALITY se ejecuta en el dispositivo cliente, no en el servidor
- SQLite por defecto puede requerir volumen persistente para supervivencia de datos entre despliegues
- La arquitectura asume que el dominio HTTPS está resuelto y certificado correctamente
- No incluye Docker Compose nativo (solo Dockerfile)
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.
Para Railway: forka el repo, crea servicio desde root (Dockerfile auto-detectado), genera dominio, inicia con admin/admin. Para self-hosting: python3 -m venv .venv && .venv/bin/pip install -r requirements.txt; .venv/bin/python main.py. Adjunta volumen en /data para persistencia. Opcional: DATABASE_URL=postgresql://... para PostgreSQL. Port 8080 por defecto.
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.