Tu túnel dividido excluye el lanzador, no el juego

Añades el lanzador a la lista de exclusiones, la descarga pasa de lenta a rápida y la partida sigue aterrizando en un servidor lejano. Nada está roto. El lanzador y el juego son dos procesos con dos conjuntos de sockets, y excluir uno no dice nada del otro. La descarga se aceleró porque la descarga era el tráfico del lanzador; la partida es la conexión de otra cosa, abierta por un ejecutable que tu regla nunca ha visto.

Un instalador, muchos procesos

El software de juegos moderno es una pequeña constelación. Hay un cliente que te inicia sesión, un actualizador que descarga contenido, un lanzador que inicia el juego y un ejecutable del juego que puede generar un segundo proceso para el anti-trampas o para la capa de emparejamiento. Cada uno puede mantener sus propias conexiones hacia sus propios destinos.

Una regla de exclusión normalmente nombra uno de ellos. Cuál nombre depende enteramente del identificador que admite el cliente VPN, y eso es lo que los usuarios rara vez comprueban. Algunos clientes comparan una ruta de ejecutable, otros un identificador de paquete o bundle, y otros un nombre de proceso que dos binarios no relacionados pueden compartir. Lee la regla antes de leer la lista de procesos, porque la regla limita incluso lo que puedes expresar.

El síntoma, por tanto, no es «el túnel dividido está roto». Es «la regla cubre un proceso que no es el que lleva el tráfico que me importa», que es una afirmación mucho más estrecha y mucho más reparable. Una vez que lo dices así, el siguiente paso deja de ser una conjetura.

Encuentra el proceso que posee la conexión de la partida

Inicia el juego, entra en una partida y mira quién posee los sockets en lugar de lo que hay en pantalla. En Windows, la lista de procesos más una consulta de sockets por proceso lo responden en dos comandos:

Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess

El segundo comando imprime un id de proceso, no un nombre, así que une las dos salidas por id. La fila que buscas es la que tiene la dirección remota del servicio del juego, y el proceso que la posee es el ejecutable que tu regla debe nombrar.

En Linux la misma pregunta requiere un comando por tipo de socket, y vale la pena comprobar ambos, porque la conexión de una partida puede ser UDP mientras todo lo demás es TCP:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

Si el juego se ejecuta en un contenedor o en una capa de compatibilidad, el proceso que encuentres puede ser un shim en lugar del binario que instalaste. En ese caso, el identificador que importa es el que ve el cliente, que puede ser la ruta del shim, y ninguna cantidad de edición del archivo original lo afectará.

Haz coincidir el identificador que admite tu cliente

Lee la documentación del cliente sobre la regla de exclusión antes de añadir nada. Los tres modelos habituales se comportan de forma distinta, y uno de ellos es una trampa.

Las reglas de ruta son las más precisas y las más frágiles. Una actualización del lanzador que traslada el ejecutable deja la regla apuntando a un archivo que ya no se ejecuta, y el síntoma vuelve sin que nada cambie de forma evidente. Las reglas de paquete sobreviven a eso, y también pueden cubrir silenciosamente procesos auxiliares en los que nunca pensaste, lo que resulta cómodo o alarmante según el auxiliar.

Admita lo que admita el cliente, no añadas entradas para cada ejecutable que encuentres. Una lista montada por ensayo y error hasta que una sesión funcionó no se puede revisar, y acumulará silenciosamente excepciones para software no relacionado. Nombra el proceso que encontraste y anota para qué servía.

Prueba en la partida, no en una descarga

La velocidad de descarga del lanzador es la peor prueba posible, porque ejercita exactamente el proceso que ya estaba excluido. Usa lo que fallaba y comprueba la ruta en lugar de la pantalla de rendimiento del propio juego:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

El primer comando necesita la dirección a la que resolvió el servidor de la partida, que pueden darte el registro de conexiones del juego o tu cliente. Si la ruta nombra la interfaz física, la regla funciona. El segundo muestra si existe una sesión, lo que separa «excluido pero el servidor está caído» de «no excluido».

Mantén fijos la región y la red de acceso mientras pruebas. Una partida que aterriza en un centro de datos distinto en cada intento produce direcciones distintas, y acabarás persiguiendo un objetivo móvil en lugar de validar una regla. Dos ejecuciones con la misma dirección valen más que diez con diferentes.

Vuelve a comprobarlo tras la próxima actualización

Cualquier regla basada en rutas tiene una vida útil medida en ciclos de parches. Cuando el juego deje de respetar la exclusión un mes después, lo primero que hay que comprobar es si el ejecutable se movió, y lo segundo, si apareció un nuevo proceso auxiliar a su lado.

El modelo de exclusión de aplicaciones que documenta un cliente es una referencia razonable de cómo se describen estas reglas, aunque los detalles varían entre productos. Lee el tuyo, registra el identificador que usaste y anota la fecha. Ese registro es lo que convierte un misterio en una corrección de cinco minutos la próxima vez que el lanzador publique una actualización.

Si el cliente simplemente no puede expresar el límite que necesitas, una política más amplia aprobada es mejor que un montón de excepciones no documentadas. Amplio y entendido vence a estrecho y equivocado, sobre todo cuando la versión estrecha es la que todos creen que está en vigor.