Telegram Desktop ha recibido una nueva forma fundamental de eludir bloqueos, que camufla el tráfico del mensajero como una visita normal a sitios web a través de una conexión segura. La tecnología experimental de proxy WEB, presentada el 21 de agosto de 2026, transmite datos MTProxy a través del transporte WebView basado en HTTPS o WebSocket, lo que hace que el flujo sea indistinguible de una navegación web legítima y abre una nueva perspectiva de acceso al servicio en condiciones restrictivas.
Cómo funciona el túnel invisible
La esencia de la innovación radica en el uso de un flujo multiplexado que se dirige a través del motor del navegador integrado en la aplicación. El cliente conserva el cifrado y la estructura de trama habituales de MTProxy, pero en lugar de conexiones TCP directas, envía todos los datos a través de una única sesión WebView. Un formato especial de tramas OPEN, DATA, WINDOW y CLOSE permite empaquetar múltiples conexiones lógicas de Telegram en un único canal seguro, que externamente parece una carga de página web estándar.
En el lado del servidor opera un retransmisor que recibe este flujo único y lo separa cuidadosamente en conexiones individuales para enviarlas al MTProxy estándar. El nodo intermedio no descifra el contenido ni conoce las direcciones de destino finales, actuando únicamente como un mero transportista. La carga útil permanece opaca en todas las etapas después de la transformación inicial por parte de la aplicación, lo que garantiza la confidencialidad incluso al pasar a través de nodos adicionales.
La doble vida de un nombre de dominio
El proxy WEB funciona en un dominio HTTPS normal, que continúa sirviendo un sitio web público completo. La página puente para el proxy se activa exclusivamente con la presencia de un parámetro especial, calculado en base a la configuración. Cualquier solicitud normal recibe la página de inicio estándar del recurso, lo que crea una cobertura fiable frente a los sistemas automáticos de detección.
La elección del método de transmisión de datos se fija rígidamente en la página intermedia generada para cada sesión concreta. El adaptador local convierte las conexiones TCP en flujos lógicos y los combina en el marco de una sola sesión de transporte, vinculada al dominio original. Esta arquitectura permite utilizar la infraestructura de los servicios de alojamiento web normales y las redes de entrega de contenido sin llamar la atención sobre la actividad del proxy.
Detalles técnicos de la implementación
La documentación completa para el despliegue y el protocolo se publica en el repositorio tproxy-server, donde se describen todos los matices de la configuración. El usuario especifica el nombre canónico del host y el secreto de MTProxy, a partir de los cuales, usando HMAC-SHA256, se deriva un identificador único para la posibilidad de conectarse al puente. Solo una solicitud GET exacta con un parámetro específico de 43 caracteres abre el acceso a la página especial; todas las demás solicitudes se manejan como visitas normales.
El enlace para la conexión tiene la forma https://t.me/webproxy?server=proxy.example.com&secret=... o utiliza el esquema tg://webproxy. El puerto 443 y el protocolo HTTPS son obligatorios y están fijados por la especificación del tipo de proxy WEB. El protocolo descrito asegura una tipificación estricta de las solicitudes y evita la activación accidental del puente.
Estado actual del proyecto
El desarrollo está en la fase de prueba de concepto e incluye una implementación para escritorio, un cliente experimental para Android y planes de soporte para iOS. Todas las plataformas utilizan la misma página intermedia, formato de tramas y componentes del servidor, lo que simplifica las pruebas y el desarrollo futuro. La unificación de las partes cliente y servidor permite realizar cambios operativamente y verificar hipótesis en diferentes sistemas operativos.
La aparición del proxy WEB demuestra una transición hacia métodos más sofisticados de integración con la infraestructura web legítima. El uso de mecanismos estándar de navegadores y protocolos seguros complica la tarea de los sistemas de filtrado, que deben elegir entre un bloqueo total del tráfico HTTPS y mantener la disponibilidad de servicios normales. El valor práctico de la tecnología estará determinado por su resistencia a métodos adaptativos de análisis de tráfico y su capacidad de escalar sin perder rendimiento.
Opinión de la IA
Desde el punto de vista del análisis de datos automatizado, el esquema de proxy WEB presentado estructuralmente repite la técnica anterior de camuflar el tráfico como HTTPS legítimo: "domain fronting", que se extendió a mediados de la década de 2010 y se describe como un método para ocultar el verdadero destinatario de una conexión mediante la no coincidencia del SNI y el Host HTTP. Los grandes proveedores de CDN con el tiempo limitaron esta posibilidad a nivel de infraestructura, lo que obligó a los desarrolladores a buscar caminos alternativos de camuflaje; en el caso de Telegram, ese camino ha sido el uso de una página puente parametrizada dentro de WebView. La situación demuestra la ciclicidad de la lucha entre la censura y las tecnologías de evasión: cada solución técnica funciona hasta que los sistemas de filtrado se adaptan al nuevo patrón de tráfico. ¿Permanecerá el proxy WEB resistente al análisis de las características temporales de los paquetes y el volumen de la sesión, o los desarrolladores tendrán que buscar nuevamente un nuevo nivel de camuflaje?
