UDP a través de SOCKS5: seis pruebas, un perfil, una dirección IP

¿Te gustaría probar Octo Browser con descuento?
Usa el código promocional OCTOBLOG para obtener un 30% de descuento en cualquier suscripción. Esta oferta es válida solo para nuevos usuarios.

Entorno de prueba

• Navegador: Octo Browser 3.1.3 (Chromium 152).

• Perfil: Quick honorable-bar · ID 8dd7332…

• Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.

• Dirección IP de salida: 68.59.118.110 · Estados Unidos · Comcast · residencial.

• Fecha y hora: 10 de septiembre de 2026, 12:04–12:11.

Cómo interpretar las capturas de pantalla

Las seis capturas corresponden a una única sesión continua, no a seis pruebas independientes. Esto se aprecia en tres detalles a los que conviene prestar atención antes de examinar los resultados:

1. En la parte superior de cada captura aparece la misma fila del perfil: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225 y, junto a él, la etiqueta UDP 68.59.118.110. Octo muestra la dirección IP de salida para UDP en una línea independiente: es precisamente la dirección que debería aparecer en todas las pruebas siguientes.

2. Las pestañas no se cerraron. En la primera captura solo hay una; en la última hay seis, y los títulos de las pruebas anteriores siguen visibles en la barra de pestañas.

3. Las horas del área de notificación siguen una secuencia continua: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.

No hubo ninguna posibilidad de reconfigurar el perfil entre las pruebas.

Paso 1. Una llamada a través del proxy: Twilio Network Test

10 de septiembre, 12:04. Una pestaña: la sesión acaba de empezar.

Esta es la herramienta oficial de diagnóstico de Twilio, un importante proveedor de servicios de telefonía y videocomunicación. Los desarrolladores la utilizan para comprobar si la conexión de un cliente permite realizar llamadas desde el navegador. No busca fugas ni tiene en cuenta los navegadores antidetección: simplemente realiza una llamada real.

Todas las comprobaciones se superaron, incluida TURN UDP Connectivity. Esto significa literalmente que los paquetes UDP enviados desde el navegador llegaron a los servidores de Twilio y regresaron.

Después, la prueba realizó dos llamadas reales con códecs diferentes, PCMU y Opus. En el registro de la derecha aparecen sus identificadores, cero paquetes perdidos y las valoraciones finales de calidad: Great y Good.

Conviene leer también las notas de los apartados TCP y TLS. Twilio indica allí que Twilio Voice no funciona a través de TCP. Es decir, las dos llamadas que se realizaron utilizaron UDP: no había otra posibilidad.

Conclusión: dos llamadas de voz reales pasaron a través del proxy SOCKS5 sin perder ningún paquete.

Paso 2. QUIC funciona y utiliza la dirección del proxy: BrowserLeaks

10 de septiembre, 12:04. Ya hay dos pestañas; Twilio sigue abierto a la izquierda.

Esta es la prueba pública de QUIC de BrowserLeaks. Responde a dos preguntas diferentes, y necesitamos ambas respuestas: si el navegador admite QUIC, es decir, si el tráfico UDP funciona, y desde qué dirección nos ve el servidor a través de QUIC, es decir, por dónde sale ese tráfico UDP.

El paso 1 ya demostró que UDP funciona, pero se trataba de otro tipo de tráfico UDP. Twilio comprobó WebRTC, que utiliza UDP para las llamadas. QUIC utiliza UDP para la navegación web habitual y es la base de HTTP/3, el protocolo que utilizan Google y YouTube para comunicarse con el navegador. Son tecnologías distintas: que una funcione no significa que la otra también lo haga.

La captura muestra dos resultados. QUIC Connection: True significa que se ha establecido una conexión a través de UDP. IP Address: 68.59.118.110 es la misma dirección que Octo muestra como salida UDP en la fila del perfil.

Conclusión: la conexión QUIC se ha establecido correctamente y el servidor ha visto la conexión desde la dirección IP del proxy.

Paso 3. Cuatro canales, una sola dirección: WebRTC Detection Check

10 de septiembre, 12:05. Tercera pestaña; las dos pruebas anteriores siguen abiertas a la izquierda.

Los dos primeros pasos demostraron que UDP funciona y que la dirección utilizada por QUIC es correcta. Esta prueba compara las direcciones de todos los canales a la vez y comprueba por separado que el navegador no esté simulando el funcionamiento de WebRTC en lugar de utilizar una conexión real.

En el bloque IP Sources aparecen cuatro filas, que corresponden a cuatro formas distintas de determinar nuestra dirección IP: una petición HTTP convencional (TCP), un servidor STUN (UDP), un retransmisor TURN a través de UDP y el mismo retransmisor TURN a través de TCP.

Las cuatro filas muestran 68.59.118.110, la dirección IP del proxy. Es decir, la dirección obtenida mediante UDP coincide con la obtenida mediante TCP.

Debajo aparece el bloque Detection Flags, que incluye siete comprobaciones independientes para detectar si el navegador está falseando los resultados. Las siete muestran NO:

• WebRTC Blocked: WebRTC no está desactivado, sino que funciona.

• UDP/TCP Mismatch: no hay discrepancias entre las direcciones obtenidas mediante UDP y TCP.

• Candidates Spoofed: los candidatos ICE que el navegador presenta a la otra parte no están falsificados.

• TURN UDP Blocked y TURN TCP Blocked: la retransmisión funciona en ambas direcciones y a través de ambos protocolos.

• Relay Spoofed: el retransmisor es real.

Lo importante es la combinación de estos resultados. El primer indicador confirma que WebRTC funciona; los otros seis indican que no se está falseando nada. No es posible ocultar un problema desactivando WebRTC, porque eso quedaría reflejado inmediatamente en la primera fila.

Conclusión: cuatro canales independientes (HTTP, STUN, TURN UDP y TURN TCP) muestran la misma dirección IP. Ninguna de las siete comprobaciones de bloqueo o falsificación ha dado un resultado positivo.

Paso 4. 3.000 solicitudes mediante HTTP/3: NGINX QUIC Sandbox

10 de septiembre, 12:07. Cuarta pestaña.

Este es un entorno de pruebas de los propios desarrolladores de NGINX. Envía un lote de solicitudes y distribuye los resultados en tres contadores: cuántas se enviaron mediante QUIC, cuántas mediante HTTP convencional y cuántas no llegaron a completarse.

El paso 2 demostró que se podía establecer una conexión QUIC. Aquí se realizan tres mil solicitudes consecutivas. Esto ya no comprueba solo si el protocolo funciona, sino si la conexión soporta una carga considerable.

Los resultados son los siguientes:

• Total requests: 3000

• Success with QUIC: 3000

• Success with HTTP: 0

• Failed requests: 0

El progreso llega a 3000/3000 y el área de visualización inferior aparece completamente en verde. Según la leyenda, el verde representa QUIC, y no hay celdas de otros colores.

Merece especial atención el contador Success with HTTP. En esta prueba, registra las solicitudes que no pudieron enviarse mediante QUIC y recurrieron al HTTP convencional. Su valor es cero.

Conclusión: las 3000 solicitudes se enviaron mediante QUIC. No hubo ningún cambio al HTTP convencional ni solicitudes fallidas.

Paso 5. WebTransport utiliza la misma dirección: wtcheck.top

10 de septiembre, 12:10. Quinta pestaña.

WebTransport es otra tecnología del navegador que permite intercambiar datos mediante QUIC, es decir, a través de UDP. La página realiza dos solicitudes y muestra sus resultados uno al lado del otro: la dirección desde la que llega una petición convencional por TCP y la dirección de la conexión mediante WebTransport.

Este es el tercer método distinto que ponemos a prueba para comprobar cómo se transmite el tráfico UDP: en el paso 1 utilizamos WebRTC; en los pasos 2 y 4, QUIC y HTTP/3; y ahora, WebTransport. Cada nueva prueba reduce la posibilidad de objetar que “ese protocolo concreto funciona, pero los demás no”.

Ambos campos muestran 68.59.118.110. No hace falta comparar capturas diferentes: los dos valores aparecen en la misma página.

Conclusión: la conexión WebTransport procede de la misma dirección IP que la petición TCP convencional realizada desde esa misma página.

Paso 6. El DNS se resuelve a través del proxy: BrowserLeaks

10 de septiembre, 12:11. Sexta pestaña; todas las pruebas anteriores siguen abiertas a la izquierda.

El DNS es un canal independiente del resto del tráfico que hemos comprobado. Un proxy puede estar perfectamente configurado y, aun así, el navegador puede consultar al servidor DNS del proveedor local para averiguar cuál es la dirección de un sitio web.

Esto tiene dos consecuencias: el proveedor local puede ver el historial de navegación y el sitio web puede comparar la ubicación geográfica del servidor DNS con la de la dirección IP de salida y detectar una discrepancia.

La prueba comprueba qué servidores DNS han intervenido en la resolución de los nombres de dominio. La captura muestra la dirección 68.59.118.110, el proveedor Comcast y el resultado Found 77 Servers, 1 ISP.

En la parte visible de la lista aparecen servidores de resolución del rango 69.241.83.x, y todos muestran Comcast en el campo ISP.

La cifra clave es 1 ISP. Todos los servidores DNS pertenecen al mismo proveedor que la dirección IP de salida del proxy. Ninguna solicitud se envió a un servidor DNS ajeno.

Conclusión: los 77 servidores DNS pertenecen al proveedor del nodo de salida. La resolución de DNS se realiza a través del proxy y no interviene el servidor DNS local.

Cómo repetir las pruebas por tu cuenta

Crea un perfil y configura en él tu proxy SOCKS5 compatible con UDP. Inicia el perfil y abre los seis enlaces siguientes. Comprueba la dirección IP: en todas las pruebas debe coincidir con la que Octo muestra en la fila del perfil al lado de la etiqueta UDP.

• networktest.twilio.com — llamada mediante WebRTC. Comprueba si UDP llega a los servidores de telefonía.

• browserleaks.com/quic — comprueba si QUIC funciona y desde qué dirección IP se establece la conexión.

• ipbinding.notsosmart.dev — compara las direcciones obtenidas mediante HTTP, STUN, TURN UDP y TURN TCP, e incluye indicadores de falsificación.

• quic.nginx.org/quic.html — comprueba si la conexión soporta una carga considerable: 3.000 solicitudes mediante HTTP/3.

• wtcheck.top — comprueba si la dirección de WebTransport coincide con la de una petición TCP.

• browserleaks.com/dns — comprueba a quién pertenecen los servidores DNS que han intervenido en la resolución de direcciones.