Empieza con una línea base, elige una sola degradación, usa el filtro más estrecho que responda a la pregunta, ejecuta una acción repetible, registra evidencias del cliente y del servidor, selecciona Stop y repite la línea base. Cuando el escenario esté claro, enlaza una guía específica de latencia, pérdida de paquetes, ancho de banda u orden de paquetes.
01
Qué cubre esta guía de pruebas de red de Clumsy
La primera decisión correcta es la pregunta de la prueba, no un porcentaje llamativo.
Clumsy cambia el tráfico de Windows seleccionado mediante WinDivert. Sus módulos retrasan, descartan, duplican, reordenan, modifican o limitan paquetes coincidentes para observar aplicaciones reales bajo condiciones repetibles. No crea un enrutador virtual ni diagnostica a un ISP.
Este centro complementa el tutorial de configuración en seis pasos: ayuda a elegir el escenario, decidir qué registrar y abrir la receta más estrecha. Diagnostica primero el fallo real y luego simula una condición conocida.
Usa Clumsy solo en un dispositivo, aplicación y ruta que sean tuyos o estén autorizados. Un filtro amplio puede afectar acceso remoto, actualizaciones, llamadas y pestañas no relacionadas. La prueba debe poder revertirse, observarse y repetirse.
- Un flujo de trabajo de una aplicación propia o autorizada.
- Una condición y un valor documentado por ejecución.
- Una línea base medida antes y después de la degradación.
- Evidencias del cliente, servidor y usuario cuando una solicitud puede tener efectos secundarios.
02
Elige el escenario correcto de prueba de red en Windows
Relaciona la condición con el comportamiento que necesitas observar. Esta guía de pruebas de red de Clumsy mantiene clara la elección. No combines Lag, Drop y Throttle al principio: si falla el flujo, no sabrás la causa. Empieza con el perfil mínimo y crea una ejecución de límite solo si hace falta.
La guía de emuladores de red explica emulación frente a simulación. Usa el estrangulamiento del navegador para una pestaña o un proxy para reglas HTTP; usa Clumsy cuando una aplicación de Windows necesite condiciones reales de paquetes sin cambios de código.
| Pregunta | Empieza con | Evidencia que debes recoger |
|---|---|---|
| ¿La interfaz explica una respuesta lenta? | Lag de 200-300 ms en un destino | Confirmación inmediata, estado de carga, tiempo de espera y cancelación |
| ¿Los reintentos se recuperan del tráfico perdido? | Drop con una probabilidad baja | ID de solicitud, número de reintentos, reconexión y efectos duplicados |
| ¿Una transferencia grande sigue siendo utilizable? | Throttle o Bandwidth en una transferencia | Progreso, cola, cancelación y número final de bytes |
| ¿El cliente soporta entregas repetidas? | Duplicate en un registro de prueba seguro | Idempotencia y cantidad de registros del servidor |
| ¿Un flujo conserva la secuencia? | Out of order en un flujo desechable | Números de secuencia, búfer, reensamblado y registro de recuperación |
03
Prepara una línea base antes de cambiar paquetes
Una prueba controlada con Clumsy comienza con un comportamiento normal que luego se puede comparar.
Escribe una pregunta observable. Por ejemplo: «Con 300 ms añadidos en la API de staging, la página debe confirmar el clic, conservar los filtros y mostrar un resultado sin duplicar la solicitud». Anota compilación, host o puerto, estado esperado y acción de recuperación. «Empeorar la red» es demasiado vago.
Ejecuta la acción sin Clumsy y registra tiempo de respuesta, carga, código de estado, ID de solicitud, registro del servidor o tamaño de transferencia. Pausa descargas ajenas y usa datos de staging para escribir.
Verifica el archivo antes de solucionar problemas. El release oficial jagt/clumsy 0.3 es un ZIP portátil Win64/Win32 con firmas A/B/C. El manual oficial cubre filtros y dirección; no uses una compilación modificada desconocida.
- DefineEscribe una pregunta, destino, condición y criterio de aprobación.
- Línea baseEjecuta la acción exacta en condiciones normales y guarda la evidencia para comparar.
- VerificaConserva en el registro el archivo oficial, la arquitectura y el checksum.
- ProtegeUsa datos de staging o una cuenta desechable para operaciones con efectos secundarios.
04
Limita el filtro y la dirección
El filtro es el límite del experimento. Una regla para todos los paquetes puede romper aparentemente autenticación, monitorización, soporte remoto y otras aplicaciones. Empieza con un destino, protocolo o puerto conocido. Una expresión de puerto puede incluir varias aplicaciones: explica su alcance en el registro.
La dirección cambia la observación: el retraso saliente prueba la solicitud y el entrante prueba carga y tiempo de espera. Empieza con una dirección y crea otra ejecución si importan ambos sentidos.
Si no puedes explicar qué coincide, no pegues el filtro desde un foro o vídeo. Selecciona Stop, simplifica la expresión y guarda filtro, dirección y hora con el resultado.
| Elección de alcance | Cuándo resulta útil | Error habitual |
|---|---|---|
| Host o servicio conocido | Un endpoint de staging es el objetivo | Suponer que el host cubre todas las dependencias |
| Protocolo y puerto | El flujo tiene un límite de transporte claro | Afectar a otras aplicaciones que comparten el puerto |
| Solo entrante | La pregunta es el tiempo de respuesta o renderizado | Olvidar que la ruta de solicitud sigue normal |
| Solo saliente | La pregunta es el retraso de solicitud o el envío | Tratar el retraso añadido como latencia total de ida y vuelta |
| Todo el tráfico | Prueba desechable y aprobada para todo el sistema | Ejecutarla en un equipo de trabajo o conexión compartida |
05
Ejecuta una condición y reúne evidencias
Una buena prueba produce una comparación, no solo una pantalla lenta.
Activa un módulo e introduce un valor documentado. Lag suele ser la primera condición más clara porque retrasa los paquetes sin descartarlos. Un retraso de 200-300 ms es un buen comienzo; auméntalo solo para una prueba de límite. Selecciona Start y repite la acción de la línea base sin cambiar el valor.
Observa la primera confirmación y la respuesta final. Comprueba progreso, cancelación, estado del formulario y el primer temporizador. Añade ID de solicitud, hora, códigos de estado y registros del servidor cuando la operación pueda repetirse. Una respuesta ausente no demuestra que el servidor no terminara la solicitud.
Mantén cada ejecución corta y con nombre. Guarda versiones de aplicación, Windows y Clumsy, origen del archivo, filtro, dirección, valores, línea base, resultado y recuperación para no confundir una degradación temporal con un fallo permanente.
- ConfirmaRevisa el filtro, la dirección y la lista de módulos justo antes de Start.
- EjecutaRealiza una acción conocida con una condición y un valor registrado.
- ObservaCaptura la respuesta del usuario, los tiempos del cliente y la evidencia del servidor.
- DeténSelecciona Stop antes de cambiar un valor o pasar a otro escenario.
- ComparaRepite la acción de línea base y registra si volvió el comportamiento normal.
06
Pasa del centro a una receta específica de Clumsy
Cuando la pregunta esté clara, usa la guía específica más pequeña. La guía de latencia cubre retrasos y tiempos de espera; la de pérdida de paquetes cubre Drop y reintentos. Usa las guías de ancho de banda y paquetes desordenados para transferencia y secuencia.
Una receta debe indicar qué cambia, qué no demuestra y cómo recuperar. Para una conexión real, usa la guía de diagnóstico de pérdida en Windows antes de simular; para un controlador, consulta Error Code 3.
| Necesidad | Siguiente página | Mantener separado |
|---|---|---|
| Entender la primera ejecución | Cómo usar Clumsy | No amplíes el filtro solo para obtener un efecto mayor |
| Probar un retraso fijo | Simulador de latencia | No llames al retraso un límite de ancho de banda |
| Probar paquetes ausentes | Simulador de pérdida de paquetes | No deduzcas un fallo del servidor por una respuesta perdida |
| Probar una transferencia lenta | Limitación de ancho de banda | No combines varias tasas en una ejecución |
| Probar el orden | Paquetes fuera de orden | No mezcles Drop antes de confirmar el comportamiento de secuencia |
07
Recupera, documenta los límites y elige otra herramienta
La recuperación forma parte de la prueba. Esta guía de pruebas de red de Clumsy la considera obligatoria. Selecciona Stop al terminar, cierra Clumsy si corresponde y repite la línea base. Confirma el objetivo y otra acción normal. Si sigue inestable, comprueba Clumsy, otras herramientas o VPN y el alcance del filtro. Detén el experimento si desconoces la línea base.
Clumsy no es un laboratorio completo. Usa un simulador para routers virtuales, un proxy para reescritura HTTP, el navegador para una pestaña o un controlador programable para perfiles multiplataforma.
No uses esta guía para hacer trampas, saltarte sistemas antitrampas, ocultar un lag switch o interrumpir servicios de terceros. Una afirmación segura es concreta: añade 250 ms a un endpoint de staging, observa el estado de carga, verifica la política de reintentos y demuestra la recuperación después de Stop.
Una sesión de Clumsy termina solo cuando se detiene la degradación, se repite la acción de línea base y se guarda la evidencia de recuperación junto con el filtro y los valores del módulo.
Preguntas frecuentes
Preguntas frecuentes sobre pruebas de red de Clumsy
¿Cuál es la mejor primera prueba con Clumsy?
Usa una aplicación no crítica, un filtro estrecho y Lag de 200-300 ms. Registra el comportamiento normal, observa una acción y demuestra la recuperación después de Stop.
¿Debo diagnosticar la pérdida de paquetes antes de simularla?
Sí. Compara una muestra con la puerta de enlace local y un destino externo. Después usa Clumsy para reproducir una pérdida controlada en una aplicación autorizada.
¿Por qué debe ser estrecho el filtro de Clumsy?
Un filtro estrecho limita el alcance del impacto y facilita explicar y recuperar el resultado. Una regla amplia puede afectar al acceso remoto, las actualizaciones, las llamadas y aplicaciones no relacionadas.
¿Cuál es la versión oficial actual de Clumsy?
El release oficial jagt/clumsy comprobado es 0.3, publicado el 21 de octubre de 2023. Usa el historial oficial y la página de 0.3 para verificar archivos, no un número mayor de un mirror.