Captura de paquetes en Windows en la práctica — pktmon, netsh trace y Wireshark: cuándo usar cada uno

«La comunicación de la aplicación de negocio con el servidor falla unas cuantas veces al mes. En el log de la aplicación solo aparece “tiempo de espera agotado”. Tampoco hay ningún error a esa hora en el log del servidor. Se desconoce la condición de reproducción» — en las consultas de investigación de fallos, este patrón aparece con muchísima frecuencia.

En el log de la aplicación solo queda lo que la aplicación «decidió escribir». Aunque se conozca el resultado —tiempo de espera agotado—, si no hubo respuesta a la solicitud de conexión (SYN), si la conexión se estableció pero el servidor guardó silencio a mitad de camino, si se cortó a la fuerza con un RST, o si el paquete siquiera llegó al destino, todo eso solo queda registrado un nivel por debajo del log: en el paquete que realmente circuló por el cable. Si observar el acceso a archivos y al registro un nivel más abajo es lo que hace Process Monitor, la captura de paquetes es el medio para observar la comunicación un nivel más abajo.

flowchart TB
    accTitle: El paquete, un nivel por debajo del log de la aplicación
    accDescr: El log de la aplicación solo conserva lo que decidió escribir, y si no hubo respuesta al SYN, si hubo silencio tras establecerse la conexión, si se cortó con RST o si el paquete llegó al destino solo queda registrado en el paquete real que circuló por el cable
    log["Log de la aplicación"] --> dec["Solo queda lo que decidió escribir"]
    dec --> to["El resultado es solo «tiempo de espera agotado»"]
    to -->|Ver un nivel más abajo| pkt["Paquete real que circuló por el cable"]
    pkt --> q1["¿Sin respuesta al SYN?"]
    pkt --> q2["¿Silencio tras establecerse?"]
    pkt --> q3["¿Cortado con RST?"]
    pkt --> q4["¿Llegó al destino?"]

Figura 1: en el log solo queda el resultado; el detalle del tiempo de espera solo se conserva un nivel más abajo, en el paquete.

Aquí es donde suele detenerse el avance por la restricción típica de «no se puede instalar Wireshark en el servidor del cliente». No es raro encontrarse con entornos donde la gestión de cambios o la política de seguridad no aprueba añadir software para la investigación, y hacerlo no resulta realista. Sin embargo, Windows trae de serie dos medios de captura de paquetes: pktmon y netsh trace. Si captura con la herramienta estándar del sistema operativo y luego se lleva el archivo obtenido a su propio equipo para leerlo con Wireshark, con este reparto de tareas puede ver los paquetes incluso en entornos donde no se puede instalar software.

Este artículo, dirigido a responsables de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones Windows, organiza cuándo usar pktmon, netsh trace y Wireshark, junto con el procedimiento práctico de cada uno. Explicamos, con base en fuentes primarias vigentes a agosto de 2026, desde la trampa del tráfico de bucle invertido y el criterio para decidir si capturar en el cliente o en el servidor, hasta cómo abordar el problema de no ver el contenido con TLS y el cotejo con el log de la aplicación.

1. Ante todo, la conclusión

• «Capturar con la herramienta estándar, leer con Wireshark» es la forma básica de trabajar en el campo. Aunque no se pueda instalar software en el servidor del cliente, pktmon y netsh trace están disponibles de forma estándar en Windows. El log capturado se convierte a formato pcapng y se analiza con el Wireshark local.¹²
• pktmon es la herramienta de captura de paquetes incluida de serie desde Windows 10 / Windows Server 2019 en adelante. Se usa con cuatro pasos —registro de filtro → inicio → detención → conversión— y su ventaja exclusiva es que permite saber en qué componente de la pila de red se descartó el paquete (el motivo del descarte).³⁴
• netsh trace es una herramienta estándar más antigua que permite capturar reuniendo un conjunto de proveedores ETW como «escenario». Además de los paquetes, también quedan registrados los eventos internos de los componentes de Windows, y con persistent=yes se puede capturar incluso a través de un reinicio.⁵⁶
• La salida de ambas herramientas está en formato ETL y no se puede abrir directamente en Wireshark. pktmon se convierte a pcapng con pktmon etl2pcap, y netsh trace, con la herramienta de código abierto de Microsoft etl2pcapng.¹²
• El propio Microsoft recomienda el flujo «primero pktmon; si no basta, netsh trace; y para el análisis de protocolo, Wireshark». El criterio de uso de este artículo sigue el mismo orden que esa recomendación oficial.⁷
• Por defecto, pktmon solo registra los primeros 128 bytes de cada paquete. Si piensa leer el contenido en Wireshark, no olvide especificar --pkt-size 0 (registrar el paquete completo) al iniciar la captura.⁸
• El tráfico dirigido a localhost no aparece en una captura normal. Esto se debe a que no pasa por la NIC. En Wireshark, use el adaptador de bucle invertido de Npcap; con las herramientas estándar, use la captura dentro de la pila de pktmon.⁹
• Aunque no se vea el contenido con TLS, se puede saber mucho. El establecimiento de la conexión, el éxito del handshake TLS, el RST y quién guardó silencio se pueden ver aunque esté cifrado. El descifrado mediante SSLKEYLOGFILE es un método limitado al entorno de desarrollo.¹⁰
• La captura contiene el propio contenido de la comunicación. Parta de la base de que puede incluir credenciales e información personal, e incorpore al procedimiento tanto la captura mínima necesaria como el filtrado antes de entregarla fuera de la empresa.

2. Las tres herramientas de captura y cuándo usar cada una

Primero, resumimos el papel de las tres herramientas en una tabla.

En una frase, pktmon y netsh trace son herramientas para «capturar», y Wireshark es la herramienta para «leer». Wireshark también tiene función de captura, pero no se puede usar en entornos donde no se puede instalar. A la inversa, también es posible convertir a texto el ETL de las herramientas estándar y leerlo así, pero examinarlo a simple vista, sin filtro de visualización ni análisis TCP, es un suplicio. «Capturar en el sitio con la herramienta estándar, convertir a pcapng y leer con el Wireshark local» es el camino más corto en entornos con restricciones.

flowchart TB
    accTitle: Capturar con la herramienta estándar, leer con Wireshark
    accDescr: Muestra que en el sitio se captura el ETL con pktmon o netsh trace, se convierte a pcapng con la herramienta correspondiente y se analiza con el Wireshark local, repartiendo así las tareas
    pk["pktmon（estándar）"] --> etla["Archivo ETL"]
    ns["netsh trace（estándar）"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analizar con el Wireshark local"]

Figura 2: en el sitio se captura el ETL con la herramienta estándar, se convierte a pcapng y se lee con el Wireshark local.

La guía de investigación de pérdida de paquetes de Microsoft también sigue el mismo esquema: primero capturar y acotar la causa con pktmon; si no basta, avanzar hacia el rastreo a nivel de componente con algo como netsh trace start scenario=InternetClient; y analizar el comportamiento del protocolo con Wireshark, en ese orden.⁷

Además, como base para leer qué se refleja en el paquete, comprender más rápido depende de poder imaginar la superposición de capas —Ethernet, IP, TCP y datos de la aplicación—. Esa disección por capas está ilustrada en «Imaginar con claridad el modelo OSI».

3. pktmon en la práctica — filtro → inicio → detención → conversión

El flujo básico de pktmon consta de cuatro pasos. Ejecútelos en una terminal con permisos de administrador.

:: 1. Primero registrar el filtro para acotar el objetivo (servidor 192.168.10.20, TCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Iniciar la captura. Registra el paquete completo y sobrescribe con un búfer circular de 1 GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Reproducir el evento. Mientras se espera, se puede verificar el tráfico y los descartes con counters
pktmon counters --drop-reason

:: 4. Detener y convertir a pcapng para usar en Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Eliminar el filtro registrado (los filtros quedan hasta que se borran explícitamente).
::    Nota: filter remove no admite especificar un nombre y elimina "todos" los filtros registrados.
::    En un entorno con filtros de otra investigación, verifique antes con pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Procedimiento básico de pktmon
    accDescr: Muestra el flujo de acotar el objetivo con el registro de filtros, iniciar la captura, reproducir el evento, detenerla, convertir a pcapng con etl2pcap y finalmente eliminar los filtros registrados
    fa["1. Acotar con filter add"] --> st["2. Iniciar con start --capture"]
    st --> re["3. Reproducir el evento"]
    re -.-> ct["Verificar tráfico y descartes con counters"]
    re --> sp["4. Detener con stop"]
    sp --> cv["Convertir a pcapng con etl2pcap"]
    cv --> rm["5. Limpiar con filter remove"]

Figura 3: pktmon empieza por el registro de filtros y, tras capturar, detener y convertir, termina eliminando los filtros de forma explícita.

Estos son los puntos que conviene tener presentes.

• Los filtros se registran antes de iniciar la captura. La documentación de Microsoft también recomienda encarecidamente aplicar filtros antes de empezar, porque capturar todo el tráfico genera demasiado ruido. Los filtros se pueden especificar por dirección IP, puerto, dirección MAC, protocolo, ID de VLAN, etc., y se pueden registrar hasta 32. Varios filtros funcionan con una condición OR: «se registra si coincide con cualquiera de ellos».³
• Los filtros de pktmon no distinguen origen de destino. -i 192.168.10.20 significa «el paquete cuyo origen o destino es esta dirección». Para acotar por dirección, hágalo después de la conversión, con el filtro de visualización de Wireshark.³
• El tamaño de paquete por defecto es de 128 bytes. Esto basta si solo va a analizar cabeceras, pero si necesita leer también los datos de la aplicación, registre el paquete completo con --pkt-size 0.⁸
• Por defecto, el log está en modo circular (búfer circular), con un tamaño predeterminado de 512 MB. Puede cambiar el límite con --file-size, y si usa --log-mode real-time se muestra en pantalla en tiempo real sin generar un archivo de log. Confirmar primero, con la vista en tiempo real, que «se ve el tráfico buscado» antes de lanzar la captura definitiva evita quedarse en blanco.⁸

flowchart TB
    accTitle: Cómo actúan los filtros de pktmon
    accDescr: Muestra que varios filtros registrados actúan con una condición OR (se registra si coincide con cualquiera de ellos), que la dirección especificada no distingue origen de destino, y que la dirección del tráfico se acota después, con el filtro de visualización de Wireshark tras la conversión
    f1["Filtro 1"] --> orc["Se registra si coincide con cualquiera"]
    f2["Filtro 2"] --> orc
    f3["Filtro 3（máximo 32）"] --> orc
    orc --> rec["Se registra en el log de captura（condición OR）"]
    rec -.-> nodir["No distingue origen de destino"]
    nodir -.-> ws["La dirección se acota después con Wireshark"]

Figura 4: varios filtros funcionan con condición OR, y la dirección (origen o destino) se acota después con Wireshark tras la conversión.

3.1. La ventaja exclusiva de pktmon — saber dónde se descartó

El valor exclusivo de pktmon frente a Wireshark es que captura los paquetes no en un único punto de la NIC, sino en varios puntos dentro de la pila de red, y puede informar dónde se descartaron y por qué motivo. Como se sabe hasta qué componente llegó el paquete y dónde desapareció, se puede llegar a la causa sin ir a tientas, gracias a motivos de descarte como «MTU no coincide» o «filtro de VLAN».⁴

flowchart TB
    accTitle: pktmon captura en varios puntos dentro de la pila
    accDescr: Muestra que pktmon captura paquetes en varios puntos dentro de la pila de red, no solo en un punto de la NIC, por lo que puede informar hasta qué componente llegó el paquete y dónde se descartó, junto con el motivo
    pin["Paquete"] --> p1["Capturado en el punto 1"]
    p1 --> p2["Capturado en el punto 2"]
    p2 --> p3["Descartado en el punto 3"]
    p3 -.-> rz["Informa el lugar y el motivo del descarte"]
    rz -.-> ex["Ejemplo: MTU no coincide o filtro de VLAN"]

Figura 5: al capturar en varios puntos dentro de la pila, se sabe hasta dónde llegó y dónde se descartó, junto con el motivo.

• Con pktmon list puede consultar la lista y los ID de los componentes de red monitoreados (NIC, pila de protocolos, controladores de filtro, etc.).
• Con pktmon counters --drop-reason puede listar, por componente, los contadores de paso/descarte y el motivo de descarte más reciente. Resulta útil como acotamiento inicial antes de analizar el log.¹¹
• Al convertir a texto con pktmon etl2txt, los paquetes descartados se muestran con drop y dropReason (el motivo del descarte).³

La sospecha de que «se está descartando en algún punto del sistema operativo antes de llegar a la aplicación» no se resuelve solo con mirar Wireshark. Esta función resulta eficaz, por ejemplo, para acotar el caso en que el firewall descarta el tráfico por una regla de entrada mal configurada («El firewall de Windows y las aplicaciones de negocio»).

Hay una advertencia. Como pktmon registra el mismo paquete en varios puntos dentro de la pila, al convertirlo tal cual a pcapng puede verse el mismo paquete duplicado. Esto se debe a que el formato pcapng no conserva la información de «en qué componente se capturó», así que, si el objetivo es leerlo en Wireshark, lo habitual es acotar el punto con --component-id de pktmon etl2pcap al convertir (o separar solo los descartes en otro archivo con --drop-only).¹

flowchart TB
    accTitle: Por qué el mismo paquete se ve duplicado al convertir a pcapng
    accDescr: Muestra que pktmon registra el mismo paquete en varios puntos de la pila y que, como pcapng no conserva la información de qué componente lo capturó, puede verse duplicado; la práctica habitual es acotar el punto con component-id o separar solo los descartes con drop-only al convertir
    same["Mismo paquete registrado en varios puntos"] --> conv["Se convierte a pcapng tal cual"]
    conv --> lost["No se conserva la información del punto de captura"]
    lost --> dup["El mismo paquete se ve duplicado"]
    dup --> c1["Acotar el punto con --component-id"]
    dup --> c2["Separar en otro archivo con --drop-only"]

Figura 6: como la información del punto de captura no se conserva en pcapng, lo habitual es acotar el punto antes de convertir.

4. netsh trace en la práctica — escenarios, ETL y captura que sobrevive al reinicio

netsh trace es un mecanismo de captura de rastreo que lleva más tiempo en Windows que pktmon. Su característica es que puede activar de golpe, bajo la unidad de «escenario», todo el conjunto de proveedores ETW relacionados con ese problema.⁶

:: Lista de escenarios disponibles y verificación de los proveedores que incluye cada escenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Iniciar la captura. Incluye captura de paquetes, con búfer circular de 1 GB
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproducir el evento y luego detener (el proceso de fusión tarda un poco)
netsh trace stop

• Al añadir capture=yes se activa la captura de paquetes, y puede acotar el objetivo con un filtro de captura como ipv4.address=192.168.10.20. La lista de filtros se puede consultar con netsh trace show capturefilterHelp.⁶
• Al detener, además del archivo ETL se genera un archivo .cab. Este .cab incluye información del sistema, como la configuración del adaptador y la compilación del sistema operativo, por lo que también sirve para recopilar información del entorno.⁶
• Solo se puede ejecutar una sesión de rastreo a la vez. Antes de iniciar otra captura, verifique con netsh trace show status que no haya una sesión abierta.⁶
• Al añadir persistent=yes, la sesión se mantiene a través de un reinicio. Para eventos como «la comunicación falla solo un instante justo después del reinicio» o «la conexión de un servicio falla al arrancar», donde no da tiempo a iniciar la captura de forma manual, netsh trace es la herramienta insustituible.⁵

flowchart TB
    accTitle: Captura por escenario de netsh trace
    accDescr: Muestra que al iniciar especificando un escenario se activa de golpe todo el conjunto de proveedores ETW, que con capture=yes también se capturan paquetes, y que al detener se generan un archivo ETL y un archivo .cab
    sc["Iniciar especificando un escenario"] --> pv["Activar el conjunto de proveedores"]
    sc -->|capture=yes| pc["También captura paquetes"]
    pv --> re["Reproducir el evento"]
    pc --> re
    re --> sp["Detener con stop"]
    sp --> etl["Archivo ETL"]
    sp --> cab[".cab（información del sistema）"]

Figura 7: al iniciar por escenario se activa de golpe el conjunto de proveedores, y al detener se generan el ETL y el .cab.

4.1. Convertir el ETL a un formato legible por Wireshark — etl2pcapng

El ETL de netsh trace no se puede abrir tal cual en Wireshark. Con la herramienta de código abierto etl2pcapng, que Microsoft publica en GitHub, puede convertir a pcapng los paquetes contenidos en el ETL capturado con netsh trace start capture=yes.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

Al convertir, etl2pcapng escribe el PID del proceso implicado en cada paquete como comentario del paquete. Como se puede verificar en Wireshark «de qué proceso es la comunicación», resulta útil para acotar en entornos donde varias aplicaciones del mismo servidor se comunican a la vez.²

Cabe señalar que el lado de los eventos ETW (los eventos internos de Windows registrados por los proveedores del escenario) no se convierte a pcapng. Si necesita leer también los eventos, conviértalos a texto u otro formato con netsh trace convert input=C:\temp\nettrace.etl, o ábralos con Windows Performance Analyzer u otra herramienta similar.⁵⁷

flowchart TB
    accTitle: La lectura del ETL de netsh trace se divide en dos caminos
    accDescr: Muestra que los paquetes del ETL se convierten a pcapng con etl2pcapng y se leen en Wireshark, y que los eventos ETW no se convierten a pcapng, por lo que se leen con netsh trace convert o Windows Performance Analyzer
    etl["ETL de netsh trace"] --> pk["Paquete"]
    etl --> ev["Evento ETW"]
    pk -->|etl2pcapng| pc["Convertir a pcapng"]
    pc --> ws["Leer en Wireshark"]
    pc -.-> pid["El PID queda como comentario"]
    ev -.-> no["No se convierte a pcapng"]
    no --> alt["Leer con convert o WPA"]

Figura 8: del ETL, los paquetes se convierten a pcapng para leerse, y los eventos ETW se leen por otro medio. </content>

5. Introducción a la lectura en Wireshark — filtros de visualización y análisis TCP

Al abrir el pcapng capturado, primero elimine el ruido con filtros de visualización. A continuación, una tabla con los más usados.¹²¹³

tcp.analysis.* son marcadores de análisis que Wireshark determina automáticamente rastreando los números de secuencia de TCP. Como puede detectar de forma mecánica retransmisiones, ACK duplicados, reordenamientos y ZeroWindow, entre otros, lo habitual al empezar a leer es escribir primero tcp.analysis.flags para listar «los puntos que parecen un problema».¹³

En la investigación de tiempos de espera, se buscan en orden los siguientes patrones.

1. ¿Se completó el triple apretón de manos? ¿Están los tres disparos SYN → SYN/ACK → ACK? Si se repite el SYN sin obtener respuesta, o no llegó al destino o se descartó en silencio por el camino (patrón típico de un firewall).
2. ¿De qué lado vino el RST? Un RST inmediato en respuesta al SYN indica que nadie está escuchando en el puerto de destino; un RST después de establecida la conexión indica que uno de los dos la cortó a la fuerza. La IP de origen del RST es la prueba directa de «quién cortó».
3. ¿Continúan las retransmisiones? Que se repita la retransmisión del mismo segmento es señal de que al emisor no le llega la confirmación (ACK). No se puede determinar solo con la captura de un lado si se perdieron los datos de ida o el ACK de vuelta (por eso resulta útil «capturar en ambos lados», del capítulo siguiente). Profundizamos en retransmisiones y tiempos de espera en «La retransmisión TCP detiene la comunicación de una cámara industrial: causa y diagnóstico».
4. ¿Aparece ZeroWindow? Es señal de que la aplicación receptora no está leyendo los datos del socket y el búfer de recepción está lleno. Es un motivo para sospechar del diseño de la aplicación receptora, y no de la red («El malentendido de poder recibir con Receive cada unidad enviada con Send en TCP»).

flowchart TB
    accTitle: Orden de patrones a buscar en la investigación de tiempos de espera
    accDescr: Muestra el flujo de verificar en orden el establecimiento del triple apretón de manos, la presencia y origen del RST, la continuidad de las retransmisiones y ZeroWindow, para acotar la causa
    hs{"¿Hubo respuesta al SYN?"} -->|No| ng["Sospecha de descarte antes de llegar（típico de un FW）"]
    hs -->|Sí| rs{"¿Se envió un RST?"}
    rs -->|Sí| who["El origen del RST es quien cortó"]
    rs -->|No| rt{"¿Continúan las retransmisiones?"}
    rt -->|Sí| ack["Señal de que no llega el ACK"]
    rt -->|No| zw{"¿Aparece ZeroWindow?"}
    zw -->|Sí| app["Señal de que la app receptora no lee"]

Figura 9: al buscar los patrones en el orden handshake, RST, retransmisión y ZeroWindow, se acota dónde investigar a continuación.

Antes de leer paquete por paquete, también resulta útil ver el panorama general con la función de estadísticas. [Estadísticas] → [Conversaciones (Conversations)] es un listado de «qué par de IP y de puertos habló, desde cuándo hasta cuándo y cuánto», que permite identificar la comunicación objetivo y filtrar después solo esa conversación. [Estadísticas] → [Gráfico de E/S (I/O Graph)] es un gráfico de tráfico en el eje temporal que muestra de un vistazo patrones como «desde este momento hubo silencio en una sola dirección». Si hace clic derecho en la conversación TCP objetivo y elige [Seguir] → [Flujo TCP], puede leer de corrido, en texto plano, solo los intercambios de esa conexión.

flowchart TB
    accTitle: Ver el panorama con estadísticas antes de acotar la conversación
    accDescr: Muestra el flujo de listar en Conversations qué comunicación habló cuándo y cuánto para identificar la conversación objetivo, detectar con I/O Graph el intervalo en que hubo silencio, filtrar solo la conversación objetivo y leerla de corrido con TCP Stream
    ov["Ver el panorama con estadísticas"] --> cv["Lista de conversaciones en Conversations"]
    ov --> io["Ver el tráfico en I/O Graph"]
    cv --> flt["Filtrar solo la conversación objetivo"]
    io -.-> mute["Se identifica cuándo hubo silencio"]
    flt --> fs["Leer de corrido con TCP Stream"]

Figura 10: antes de leer paquete por paquete, se observa el panorama con estadísticas y se lee de corrido tras acotar la conversación objetivo.

6. La trampa del tráfico de bucle invertido — lo dirigido a localhost no pasa por la NIC

Al intentar investigar la comunicación entre aplicaciones dentro del mismo PC —por ejemplo, la conexión de la aplicación de negocio a un servicio intermedio en localhost:8080— es una trampa clásica quedarse atascado porque «Wireshark no muestra nada».

La causa es clara: el tráfico dirigido a localhost (127.0.0.1) no pasa por la NIC física, sino que se devuelve por la ruta de bucle invertido interna del sistema operativo. No aparece desde el principio en una captura normal dirigida al adaptador físico.⁹

flowchart TB
    accTitle: Por qué el tráfico dirigido a localhost no aparece en la captura
    accDescr: Muestra que el tráfico dirigido a localhost no pasa por la NIC física, sino que se devuelve por la ruta de bucle invertido interna del SO, por lo que no aparece en una captura normal dirigida al adaptador físico
    app["Aplicación"] --> stack["Pila de red"]
    stack -->|Destino externo| nic["NIC física"]
    nic --> seen["Aparece en la captura normal"]
    stack -->|Destino localhost| lo["Se devuelve dentro del SO"]
    lo -.-> miss["No aparece en la captura normal"]
    lo -.-> alt["Capturar con el bucle de Npcap o con pktmon"]

Figura 11: como el tráfico a localhost se devuelve antes de llegar a la NIC, no aparece desde el principio en la captura del adaptador físico.

Hay dos formas de abordarlo.

• Si captura con Wireshark: seleccione como objetivo de captura el «Adapter for loopback traffic capture» que ofrece Npcap. Como el instalador de Wireshark para Windows (3.0 en adelante) incluye Npcap, en cualquier entorno donde ya esté instalado Wireshark se puede usar sin trabajo adicional.⁹
• Si captura con las herramientas estándar: como pktmon captura en varios puntos dentro de la pila de red y no fuera de la NIC⁴, también sirve para observar el tráfico de bucle invertido. Para asegurarse, antes de lanzar la espera de la reproducción real, confirme en ese entorno, con la vista en tiempo real de pktmon start -c -m real-time, que el tráfico de bucle invertido buscado realmente se ve.

Además, tenga cuidado con dos confusiones habituales.

• «localhost» a veces se resuelve al ::1 de IPv6. Es el patrón en el que la aplicación se conecta al ::1 de IPv6, pero quien investiga solo mira 127.0.0.1 (IPv4) y concluye erróneamente que «no hay comunicación». Aplique el filtro de visualización a ambas direcciones, como ip.addr == 127.0.0.1 || ipv6.addr == ::1, o indique de forma explícita la dirección de destino en la configuración de conexión de la aplicación.⁹
• El tráfico dirigido a la propia IP real tampoco sale por el cable. Si desde el mismo PC con 192.168.10.5 se conecta a 192.168.10.5, aunque el destino sea una IP real, se devuelve dentro del sistema operativo. Tenga presente que «especificar una IP real» no siempre implica que pase por la NIC.

flowchart TB
    accTitle: La confusión de que localhost se resuelve a IPv6
    accDescr: Muestra que la app puede conectarse resolviendo localhost a ::1（IPv6）, y que si quien investiga solo mira 127.0.0.1 concluye erróneamente que no hay comunicación, por lo que conviene filtrar ambas direcciones o indicar el destino de forma explícita
    app["La app se conecta a localhost"] --> v6["En realidad se resuelve a ::1（IPv6）"]
    look["Quien investiga solo mira 127.0.0.1"] --> none["No aparece nada en pantalla"]
    v6 --> none
    none --> fix1["Filtrar ambas direcciones"]
    none --> fix2["Indicar el destino con la dirección explícita"]

Figura 12: localhost se resuelve a ::1 y, al mirar solo 127.0.0.1, se concluye erróneamente que «no hay comunicación»; tenga cuidado con esa confusión.

7. Dónde capturar — un lado, ambos lados y la sincronía horaria

El valor de la captura depende de «dónde se capturó». A continuación, un criterio orientativo.

Con la captura de un solo lado solo se sabe «el hecho visto desde esa posición». Aunque en el lado del cliente sigan las retransmisiones, no se puede distinguir si el paquete enviado se perdió en el trayecto o si llegó al servidor pero se perdió la respuesta. Al capturar en ambos lados y cotejar, se determina quién guardó silencio, por ejemplo, «el cliente envió, pero no llegó al servidor». En los casos donde se quiere delimitar con certeza la responsabilidad (la aplicación, el sistema operativo, el equipo de red o la contraparte), vale la pena planificar desde el principio la captura en ambos lados.

flowchart TB
    accTitle: Qué se sabe con la captura de un lado y con la de ambos lados
    accDescr: Muestra que con la captura de un solo lado no se puede distinguir si el paquete de ida se perdió o si se perdió la respuesta de vuelta, y que al capturar en ambos lados y cotejar se determina cuál de los dos guardó silencio
    one["Captura de un solo lado"] --> fact["Solo el hecho visto desde esa posición"]
    fact --> und["No distingue si se perdió la ida o la vuelta"]
    both["Captura simultánea en ambos lados"] --> mt["Cotejo"]
    mt --> fix["Se determina cuál guardó silencio"]
    mt -.-> pre["Requiere sincronía horaria entre ambas máquinas"]

Figura 13: con un solo lado solo se conoce el hecho observado; solo al cotejar ambos lados se determina con certeza la delimitación de responsabilidad.

7.1. El requisito previo para cotejar es la sincronía horaria

Para cotejar las capturas de ambos lados, los relojes de las dos máquinas deben estar alineados. Antes de empezar a capturar, verifique y registre el desfase horario.

:: Verificar el estado de la sincronía horaria (origen de sincronía y última hora sincronizada)
w32tm /query /status

:: Medir la diferencia horaria con el servidor remoto (5 muestras)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart es un comando que muestra el desfase horario entre el propio equipo y el equipo remoto, y sirve como base para corregir, al cotejar, algo como «el reloj del servidor estaba desfasado +0,8 segundos».¹⁴ En entornos con un desfase grande, corregir primero la sincronía horaria antes de capturar termina siendo el camino más rápido.

flowchart TB
    accTitle: Procedimiento para verificar la diferencia horaria antes de cotejar
    accDescr: Muestra el flujo de verificar con w32tm el estado de la sincronización horaria propia, medir con stripchart la diferencia horaria con el servidor remoto y registrarla como base de corrección al cotejar, y que en entornos con gran desfase conviene corregir primero la sincronización antes de capturar
    st["Verificar el estado de sincronía con query"] --> mc["Medir la diferencia horaria con stripchart"]
    mc --> rc["Registrar el desfase"]
    rc --> use["Base de corrección al cotejar"]
    mc -.-> big["Si el desfase es grande, corregir la sincronía antes"]

Figura 14: antes de capturar, mida y registre la diferencia horaria, para usarla como base de corrección al cotejar.

7.2. Para lo que «no se sabe cuándo ocurrirá», el búfer circular

Para eventos sin condición de reproducción conocida, lo básico es dejar la captura corriendo con un búfer circular y detenerla cuando ocurra el evento.

• pktmon: por defecto está en modo circular. Especifique el límite (en MB) con --file-size, y los paquetes más antiguos se sobrescriben primero.⁸
• netsh trace: se especifica como maxSize=1024 filemode=circular.⁵
• Wireshark: en [Captura] → [Opciones] → [Salida] puede configurar «múltiples archivos + búfer circular». Como va rotando por tamaño de archivo o por tiempo y conserva solo los N más recientes, puede dejarla corriendo mucho tiempo sin superar un límite de uso de disco.¹⁵

En cualquier caso, comparta con el personal del sitio la práctica de anotar la hora en que ocurrió el evento antes de detener la captura. Como el búfer circular va perdiendo el pasado cuanto más se espera, si el procedimiento entre la ocurrencia y la detención es largo, se sobrescribe el tramo clave.

flowchart TB
    accTitle: Operación de espera con el búfer circular
    accDescr: Muestra que, para eventos sin condición de reproducción conocida, se deja capturando con búfer circular y se espera, se anota la hora al ocurrir el evento y se detiene con rapidez, y que si la detención se retrasa se sobrescriben los paquetes antiguos y se pierde el tramo clave
    st["Iniciar captura con búfer circular"] --> wt["Esperar dejándola correr"]
    wt --> ev["Ocurre el evento"]
    ev --> memo["Anotar la hora del evento"]
    memo --> sp["Detener con rapidez"]
    wt -.-> ow["Se sobrescriben los paquetes antiguos"]
    ow -.-> late["Si se retrasa la detención, se pierde el tramo clave"]

Figura 15: como el búfer circular va perdiendo el pasado cuanto más se espera, anote la hora del evento y detenga la captura de inmediato.

8. El problema de no ver el contenido con TLS — lo que se sabe aunque no se vea

Hoy en día, gran parte de la comunicación de negocio es TLS (HTTPS). Se suele pensar que «si está cifrado, capturar es inútil», pero la mayor parte de lo que se necesita saber en una investigación de tiempos de espera se puede conocer aunque siga cifrado.

• Si se estableció la conexión TCP (triple apretón de manos)
• Hasta dónde avanzó el handshake TLS: si se devolvió el ServerHello en respuesta al ClientHello, o si se cortó durante el handshake con un RST o una alerta
• El nombre de host de destino que va en el ClientHello (SNI) y la versión de TLS negociada
• Después de establecerse la conexión, quién dejó de enviar: la posición sin respuesta, las retransmisiones, el RST o un cierre normal (FIN)

En otras palabras, para acotar entre «no conecta», «se corta a mitad de camino» o «no llega respuesta», casi no hace falta descifrar el contenido. Esto es porque lo que se pierde con el cifrado es «de qué se habló», mientras que «quién guardó silencio y cuándo» permanece.

flowchart TB
    accTitle: Qué se ve y qué no se ve en la captura de TLS
    accDescr: Muestra que lo único que el cifrado oculta es el contenido de los datos de la aplicación, y que el establecimiento de la conexión TCP, el éxito o fracaso del handshake TLS, el SNI y la versión de TLS, y el RST o quién guardó silencio se pueden ver aunque siga cifrado
    tls["Captura de comunicación TLS"] --> vis["Lo que se ve"]
    tls --> hid["Lo que no se ve"]
    vis --> v1["Establecimiento de la conexión TCP"]
    vis --> v2["Éxito de TLS y SNI"]
    vis --> v3["RST y quién guardó silencio"]
    hid --> h1["Contenido de los datos de la app"]

Figura 16: el cifrado solo hace perder el contenido; el esqueleto de la comunicación se puede leer aunque siga en TLS.

Aun así, si necesita el contenido, Wireshark cuenta con un mecanismo para descifrar TLS usando la clave de sesión volcada mediante la variable de entorno SSLKEYLOGFILE. Sin embargo, solo lo admiten algunas implementaciones, como los navegadores Firefox, Chrome y Edge basado en Chromium, o bibliotecas de la familia OpenSSL; el SChannel estándar de Windows (aplicaciones que usan WinHTTP o WinINET) no es compatible con este mecanismo.¹⁰ Dado que volcar la clave de sesión a un archivo implica que quien tenga ese archivo puede descifrar toda la comunicación, debería considerarse un método para reproducción y depuración en el entorno de desarrollo, no una herramienta para usar en producción.

flowchart TB
    accTitle: Mecanismo y limitaciones del descifrado con SSLKEYLOGFILE
    accDescr: Muestra que con la clave de sesión volcada mediante SSLKEYLOGFILE se puede descifrar TLS en Wireshark, pero que solo lo soportan algunas implementaciones como Firefox o la familia Chrome con SChannel no compatible, y que como quien tiene la clave puede descifrar toda la comunicación, es un método limitado al entorno de desarrollo
    env["Configurar SSLKEYLOGFILE"] --> key["Volcar la clave de sesión a un archivo"]
    key --> ws["Descifrar y leer en Wireshark"]
    key -.-> risk["Quien tiene la clave descifra todo"]
    risk -.-> dev["Limitado al entorno de desarrollo"]
    env -.-> sup["Solo lo soportan algunas implementaciones de TLS"]
    sup -.-> sch["SChannel no es compatible"]

Figura 17: volcando la clave de sesión se puede descifrar, pero los implementos compatibles son limitados y, por la naturaleza de la clave, es un método restringido al entorno de desarrollo.

Cabe señalar que, en la comunicación a través de un proxy interno, el destino que aparece en la captura es el servidor proxy, y el TLS circula dentro de un túnel CONNECT. El problema previo de a qué proxy se dirige la aplicación en primer lugar se organiza en el artículo hermano publicado el mismo día, «Proxy interno y aplicaciones Windows — organizando la resolución de proxy de WinINET, WinHTTP y .NET».

9. Cotejo con el log de la aplicación — alinear los tiempos en el mismo eje

En realidad, pocas veces la captura por sí sola llega a una conclusión. Lo decisivo en la práctica es alinear una línea del log de la aplicación con un intercambio de paquetes en el mismo eje temporal.

El procedimiento queda así.

1. Identifique la hora del evento a partir del log de la aplicación (por ejemplo: excepción de tiempo de espera a las 10:23:41). Si el valor de tiempo de espera es de 30 segundos, el inicio debería rondar las 10:23:11.
2. Cambie la visualización de la hora en Wireshark en [Ver] → [Formato de visualización de hora] → [Fecha y hora], y acote el intervalo correspondiente con el filtro de visualización (también se puede acotar por hora, como en frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. En ese intervalo, verifique el orden del capítulo 5 (handshake → RST → retransmisión → ZeroWindow). Si logra cotejar hasta «se envió el SYN 30 segundos antes de la hora de tiempo de espera del log, y a partir de ahí solo hubo retransmisiones del SYN», el «tiempo de espera» del log se convierte en el hecho observado de que «en este punto de captura no llegó absolutamente ninguna respuesta» (no se puede determinar solo con este punto de captura si el SYN no llegó al destino o si el SYN/ACK de respuesta se perdió en el camino de vuelta; si necesita determinarlo, cotéjelo con la captura del lado del servidor).
4. Corrija siempre el desfase entre la hora de la captura y la del log (la diferencia horaria medida en el apartado 7.1, la notación de zona horaria del log). Un error de unos segundos al cotejar puede hacer que se culpe a una comunicación equivocada.

flowchart TB
    accTitle: Procedimiento para cotejar el log de la app con los paquetes
    accDescr: Muestra el procedimiento de identificar la hora del evento en el log de la app, calcular hacia atrás la hora de inicio a partir del valor de tiempo de espera, acotar el intervalo correspondiente en Wireshark y verificar los patrones en orden, y corregir el desfase horario para alinearlos en el mismo eje temporal
    lg["1. Identificar la hora en el log"] --> rev["Calcular el inicio desde el valor de espera"]
    rev --> flt["2. Acotar el intervalo con el filtro de visualización"]
    flt --> chk["3. Verificar los patrones del capítulo 5"]
    chk --> adj["4. Corregir el desfase horario"]
    adj --> done["La palabra del log se convierte en un hecho observado"]

Figura 18: a partir de la hora del log se acota el intervalo, se verifican los patrones, se corrige el desfase horario y se alinean en el mismo eje.

Al entregar los resultados de la investigación a un tercero (proveedor, operador de línea, responsable de red del cliente), quitar el ruido con un filtro antes de entregar es tanto una cortesía como una medida de seguridad. Si acota con el filtro de visualización de Wireshark solo la conversación objetivo y guarda con [Archivo] → [Exportar paquetes especificados] solo los «paquetes mostrados», puede generar un pcapng pequeño con solo el alcance necesario.

Por último, una advertencia sobre el manejo. El archivo de captura contiene el propio contenido de la comunicación. Puede incluir credenciales de protocolos en texto claro, cookies o claves de API de HTTP, el contenido de correos o formularios, e información personal. Decida de antemano, junto con el procedimiento de captura, estos tres puntos.

• Captura mínima necesaria: acote el objetivo con el filtro previo a la captura (capítulos 3 y 4) y reduzca también el período al mínimo. No haga «capturar todo por si acaso» en el entorno del cliente
• Filtrado antes de entregar: exporte solo la conversación objetivo y no incluya comunicaciones de terceros ajenos. Si queda alguna parte sensible, acuerde con el destinatario el enmascarado u otro medio de entrega
• Conservación y eliminación: defina el lugar de conservación, el plazo y la eliminación del archivo capturado, y bórrelo al finalizar la investigación

flowchart TB
    accTitle: Tres decisiones antes de entregar el archivo de captura
    accDescr: Muestra que, como la captura contiene el propio contenido de la comunicación, hay que acotarla al mínimo necesario con el filtro y el período previos a la captura, extraer solo la conversación objetivo antes de entregarla sin incluir comunicaciones ajenas, y definir el lugar y el plazo de conservación para borrarla al terminar la investigación, tres puntos que se deciden junto con el procedimiento de captura
    cap["La captura contiene el contenido de la comunicación"] --> p1["Capturar lo mínimo necesario"]
    cap --> p2["Extraer solo lo objetivo antes de entregar"]
    cap --> p3["Definir el plazo de conservación y borrar"]
    p2 -.-> exp["Acotar con el filtro de visualización y exportar"]

Figura 19: decida junto con el procedimiento de captura los tres puntos: captura mínima, filtrado antes de entregar, y conservación y eliminación.

10. Resumen

• Un nivel por debajo del «tiempo de espera» del log de la aplicación está el hecho del paquete que realmente circuló por el cable. Según si no hubo respuesta al SYN, si se cortó con RST, si continuaron las retransmisiones o si fue ZeroWindow, cambia el lugar donde investigar a continuación.
• Incluso en sitios donde no se puede instalar Wireshark, se puede capturar con las herramientas estándar de Windows pktmon y netsh trace. Capturar con la herramienta estándar y leer con el Wireshark local es el reparto de tareas básico.
• pktmon consta de cuatro pasos: registro de filtro → pktmon start --capture → pktmon stop → pktmon etl2pcap. Por defecto se trunca a 128 bytes, así que, si necesita leer el contenido, no olvide --pkt-size 0. Conocer el punto y el motivo del descarte es una ventaja exclusiva de pktmon.
• netsh trace permite capturar agrupando proveedores ETW por escenario, y con persistent=yes sobrevive a un reinicio. El ETL se convierte a pcapng con etl2pcapng para leerlo.
• En Wireshark, empiece a leer por tcp.analysis.flags y busque los patrones en el orden handshake, RST, retransmisión y ZeroWindow. Observar el panorama con Conversations e I/O Graph antes de acotar es más rápido.
• Lo dirigido a localhost no pasa por la NIC, así que no se captura de forma normal. Use el adaptador de bucle invertido de Npcap o la captura dentro de la pila de pktmon.
• Capturando en ambos lados y cotejando se determina «quién guardó silencio». Su requisito previo es la sincronía horaria (w32tm). Para eventos sin condición de reproducción conocida, espere con un búfer circular.
• Incluso con TLS se ve el esqueleto de la comunicación. Considere el descifrado (SSLKEYLOGFILE) un método limitado al entorno de desarrollo, y trate el propio archivo de captura como confidencial, incorporando a la operativa la captura mínima, el filtrado y la eliminación.

Se suele pensar que la captura de paquetes es «una herramienta de especialistas en redes», pero en realidad es una herramienta de investigación del lado de la aplicación, que solo cobra sentido al cotejarla con el log de la aplicación. La próxima vez que una investigación se detenga en la palabra «tiempo de espera», vaya a ver ese nivel más abajo.

Artículos relacionados

• La retransmisión TCP detiene la comunicación de una cámara industrial: causa y diagnóstico
• El malentendido de poder recibir con Receive cada unidad enviada con Send en TCP — diseño de recepción para tratarlo como flujo de bytes
• Imaginar con claridad el modelo OSI — disecar una solicitud HTTP en sus siete capas
• Guía práctica de Process Monitor (ProcMon) — identifique en 10 minutos «no se lee la configuración» o «ACCESS DENIED»
• El firewall de Windows y las aplicaciones de negocio — registre las reglas de entrada con el instalador
• Proxy interno y aplicaciones Windows — organizando la resolución de proxy de WinINET, WinHTTP y .NET

Áreas de consultoría relacionadas

En KomuraSoft LLC atendemos investigaciones de fallos originados en la comunicación, como «la comunicación de la aplicación de negocio falla de vez en cuando y no se conoce la causa» o «se quiere acotar un error de conexión que solo ocurre en el entorno del cliente». Nos encargamos de todo el proceso de forma continua: desde el diseño de la captura de paquetes (dónde, qué y cuánto capturar), el análisis en Wireshark y el cotejo con el log de la aplicación, hasta la corrección del lado de la aplicación.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cómo puedo capturar paquetes en un servidor del cliente donde no se puede instalar Wireshark?

Con las herramientas estándar de Windows, pktmon o netsh trace, puede capturar sin necesidad de instalar software adicional. Con pktmon, registre un filtro en una terminal con permisos de administrador, inicie la captura con pktmon start --capture y deténgala con pktmon stop. El archivo ETL obtenido se puede convertir a formato pcapng con pktmon etl2pcap, de modo que el análisis se realiza con el Wireshark local, tras llevarse el archivo a su propia empresa. Este reparto de tareas —capturar con la herramienta estándar y leer con Wireshark— es la forma básica de trabajar en entornos con restricciones de instalación.

¿Debería usar pktmon o netsh trace?

Si el sistema operativo admite pktmon (Windows 10 / Windows Server 2019 o posterior), se recomienda empezar por pktmon. Sus comandos son sencillos, permite ver hasta qué componente de la pila de red descartó el paquete (el motivo del descarte) y la conversión a pcapng se completa por sí sola. netsh trace resulta ventajoso cuando se captura en un sistema operativo antiguo que no incluye pktmon, cuando se quieren reunir también los eventos ETW de los componentes de Windows en forma de «escenario», o cuando se necesita capturar a lo largo de un reinicio con persistent=yes. La documentación de solución de problemas de Microsoft también recomienda este mismo orden: primero pktmon y, si no basta, netsh trace.

¿Por qué el tráfico dirigido a localhost (127.0.0.1) no aparece en Wireshark?

Porque el tráfico dirigido a localhost no pasa por la NIC física, sino que se devuelve por la ruta de bucle invertido interna del sistema operativo. No aparece desde el principio en una captura normal dirigida al adaptador físico. En Wireshark puede capturar el tráfico de bucle invertido seleccionando el «Adapter for loopback traffic capture» que ofrece Npcap. Como pktmon captura dentro de la pila de red, también sirve para observar el tráfico de bucle invertido. Además, es habitual confundirse cuando «localhost» se resuelve a ::1 de IPv6 y no aparece nada en la pantalla que se está mirando pensando en 127.0.0.1, así que verifique especificando la dirección de forma explícita.

¿Se puede ver el contenido de una comunicación HTTPS (TLS) en la captura de paquetes?

El contenido de los datos de la aplicación está cifrado y no se puede ver. Sin embargo, el «esqueleto de la comunicación» —el establecimiento y cierre de la conexión TCP, el éxito o fracaso del handshake TLS, el corte por RST, quién dejó de responder— se puede conocer aunque esté cifrado, por lo que la mayor parte de la investigación de tiempos de espera puede avanzar con TLS tal cual. Si además necesita el contenido, existe el descifrado mediante SSLKEYLOGFILE, pero solo lo admiten algunas implementaciones de TLS, como Firefox o la familia Chrome; el SChannel estándar de Windows no es compatible. Como es un mecanismo que vuelca información de clave privada, considérelo limitado, en todo caso, al entorno de desarrollo.

¿Es seguro enviar el archivo de captura obtenido a un servicio de soporte externo?

Enviarlo tal cual es peligroso. La captura contiene el propio contenido de la comunicación y puede incluir credenciales de protocolos en texto claro, cookies, claves de API e información personal. Primero, en la fase de captura, acótela al mínimo necesario con filtros y un período limitado, y antes de entregarla, extraiga solo la comunicación objetivo con el filtro de visualización de Wireshark y expórtela. Sobre lo que aún quede, debería decidir con el destinatario cómo tratar las partes sensibles (enmascararlas, entregarlas por otro medio) antes de enviarlo. También se recomienda decidir de antemano el plazo de conservación y la eliminación de los archivos capturados.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.