Ayuda
¿Qué es la pérdida de paquetes y cómo se nota?
La pérdida de paquetes ocurre cuando los paquetes enviados no llegan al destino. Compara equipos, conexiones y pruebas repetidas; las respuestas ping ausentes no identifican por sí solas el fallo.
Hay pérdida de paquetes cuando un paquete enviado no llega a su destino. Voz entrecortada, saltos en un juego o transferencias detenidas pueden encajar, pero también tienen otras causas como el procesamiento del equipo o un error de la aplicación. Una descarga rápida no excluye pérdidas intermitentes. VMAXCHECK no proporciona una medición directa de pérdida de paquetes; la velocidad o la latencia no confirman ese diagnóstico.
Empieza con una comparación controlada
- Anota hora, duración, aplicación y si varios equipos fallan a la vez. Si la aplicación ofrece estadísticas de red, registra la pérdida y la dirección medida según su explicación.
- Compara Wi-Fi y Ethernet en el mismo equipo con poco tiempo de diferencia. Pausa tus transferencias grandes y copias de seguridad para la referencia, y observa por separado las condiciones que suelen causar el problema.
- Repite en un periodo tranquilo y durante el fallo con los mismos destinos y ajustes. Una prueba normal aislada no excluye un problema intermitente. Un patrón nocturno por sí solo no demuestra congestión.
- Compara otro equipo y otro servicio. Si solo falla una aplicación, comprueba también su estado. Mejorar con Ethernet orienta hacia el trayecto inalámbrico o el equipo, pero no demuestra pérdida de tramas Wi-Fi.
Haz pruebas ping limitadas y conserva los ajustes
En Windows, ping /n 50 1.1.1.1 envía 50 solicitudes de eco ICMP a un destino público. Utiliza un destino que responda; no es necesariamente el servidor de tu aplicación. Prueba también la dirección local del router indicada en los ajustes de red, sustituyendo el destino por esa dirección. Guarda los resultados por separado: envíos, respuestas recibidas o ausentes y tiempos de ida y vuelta. Repite con la misma cantidad, espera, tamaño y familia de direcciones. Evita esperas muy cortas o pruebas de envío masivo; esperar respuestas ausentes puede prolongar la prueba varios minutos.
Interpreta con cuidado las respuestas ausentes
- Dos respuestas ausentes de 50 solicitudes equivalen al 4 % de respuestas ICMP ausentes en esa muestra. No es una estimación fiable de todo el tráfico de aplicaciones. El router o el destino puede limitar o bloquear ICMP; la solicitud y la respuesta pueden fallar en distintas partes de la ida y vuelta.
- Si faltan respuestas del router y hay problemas en las aplicaciones, revisa primero el trayecto local. Un router que no responde sin síntomas coincidentes no basta para declarar averiada la conexión.
- Si el router responde mientras fallan varios destinos de Internet y aplicaciones, investiga el lado de Internet del router, el acceso y el trayecto más amplio. El resultado no señala al proveedor como único culpable.
- Los asteriscos en traceroute o la pérdida en un solo salto intermedio de pathping no demuestran un fallo de reenvío. Compara destino final, saltos posteriores y aplicaciones: un equipo puede limitar sus propias respuestas y seguir reenviando otros paquetes.
La latencia y la pérdida son distintas: un ping alto no es un recuento de paquetes perdidos. TCP puede retransmitir datos ausentes, con posibles retrasos o menor velocidad. UDP por sí mismo no garantiza la entrega; las aplicaciones pueden añadir recuperación propia. El efecto depende de la aplicación y de pérdidas aisladas o en ráfagas. Un porcentaje no es un umbral universal de aprobación, y una prueba breve sin respuestas ausentes no garantiza otros trayectos ni sesiones futuras.
Cambia lo pertinente y vuelve a comparar
- Para un problema limitado al Wi-Fi, revisa cobertura y competencia de radio. Con cable, compara un cable o puerto compatible que funcione y consulta las indicaciones oficiales del equipo y adaptador de red. Cambia una cosa cada vez.
- Si el problema acompaña tus transferencias grandes, páusalas, prográmalas o limítalas y compara. La gestión de colas compatible según el fabricante puede ayudar ante congestión, pero no repara todas las pérdidas.
- Guarda eventos del router y mediciones antes de reiniciarlo siguiendo su guía. Interrumpe a otros usuarios y llamadas; es una prueba, no una demostración de la causa. No empieces con un restablecimiento de fábrica ni desactivando protecciones.
- Repite las mismas pruebas y la aplicación afectada tras el cambio. Si solo sigue fallando un servicio, revisa su estado y soporte. Si fallan varios equipos y servicios, entrega las comparaciones al proveedor de red.
Facilita al soporte hora, duración, tipo de conexión, modelo del router, destinos y ajustes, envíos y respuestas ausentes, tiempos de ida y vuelta, equipos y aplicaciones, y cambios con Ethernet o menor carga. Elimina contraseñas, tokens y datos privados de los registros. Las observaciones reproducibles ayudan más que culpar al salto con mayor porcentaje o comprar un plan rápido por un solo resultado.