2026-06-02

SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark

Analice SNI vs ALPN en protocolos de enlace TLS. Diagnostice fallas de negociación HTTP/2, respaldo h2 vs http/1.1, extensiones ClientHello, respuestas ServerHello ALPN y problemas de terminación de proxy en PCAP de Wireshark.

Muchos incidentes de "HTTP/2 no funciona" son en realidad problemas de negociación de TLS ALPN. Los usuarios buscan "TLS ALPN pcap", "HTTP2 alternativo a HTTP/1.1", "ALPN h2 no negociado", "extensión ClientHello ALPN", "protocolo seleccionado ServerHello" y "por qué mi navegador usa HTTP/1.1" cuando un punto final debería admitir HTTP/2 pero el tráfico disminuye.

La cirugía PCAP es útil porque la evidencia ALPN reside en el apretón de manos TLS. Si la captura incluye ClientHello y ServerHello, a menudo puede probar si el cliente ofreció "h2", si el servidor lo seleccionó, si un proxy terminó TLS o si la conexión nunca tuvo la oportunidad de negociar HTTP/2.

¿Qué hace ALPN?

ALPN significa Negociación de protocolo de capa de aplicación. Permite que el cliente y el servidor acuerden un protocolo de aplicación durante la configuración de TLS.

Valores ALPN comunes:

h2 para HTTP/2 sobre TLS.
http/1.1 para HTTP/1.1.
Otros identificadores de protocolo para sistemas especializados.

Si el cliente no ofrece h2, el servidor no puede seleccionarlo. Si el servidor no selecciona h2, la conexión no utilizará HTTP/2 incluso si el servidor admite HTTP/2 en otro lugar.

Síntomas comunes

Las fallas de ALPN aparecen como:

El navegador utiliza HTTP/1.1 en lugar de HTTP/2.
La conexión gRPC falla.
CDN funciona pero el origen no.
Protocolo de degradación de proxy inverso.
El equilibrador de carga finaliza TLS y reenvía HTTP/1.1.
La aplicación móvil dice error de protocolo.
Las métricas del servidor no muestran tráfico h2.
HTTP/2 funciona con un nombre de host pero no con otro.

Estos síntomas a menudo se depuran en la capa HTTP, pero la respuesta puede estar en la negociación TLS.

ClienteHola evidencia

ClientHello puede mostrar si el cliente ofreció ALPN y qué protocolos anunció.

Preguntas útiles:

¿Está presente la extensión ALPN?
¿La oferta incluye h2?
¿También incluye http/1.1?
¿El SNI está presente y es correcto?
¿Qué versión de TLS se ofrece?
¿Se realiza la captura antes de que un proxy finalice TLS?

Si h2 está ausente en ClientHello, el servidor no puede elegir HTTP/2. El motivo puede ser la configuración de la biblioteca del cliente, una pila TLS antigua, una opción HTTP/2 deshabilitada o un cliente proxy que abre una nueva conexión ascendente.

ServidorHola evidencia

El lado del servidor debe seleccionar un protocolo de la lista ALPN del cliente.

Problemas:

El servidor selecciona solo http/1.1.
El servidor omite la respuesta ALPN.
El protocolo de enlace del servidor falla antes de la selección de ALPN.
Las rutas de certificado o SNI no coinciden con un host virtual predeterminado.
El terminador TLS admite h2 en el lado público pero no en el lado ascendente.

La evidencia de paquetes puede separar el soporte del servidor del enrutamiento y el comportamiento del proxy.

SNI y ALPN juntos

SNI y ALPN suelen estar conectados. El nombre de host seleccionado por SNI puede determinar qué configuración de certificado, host virtual y protocolo se aplican.

Ejemplo de fallo:

El cliente ofrece h2.
El cliente envía un SNI incorrecto.
El servidor devuelve el certificado predeterminado.
El host virtual predeterminado no habilita HTTP/2.
La conexión vuelve a http/1.1.

En este caso, el problema no es "HTTP/2 roto globalmente". Es enrutamiento de nombre de host.

Terminación de proxy y balanceador de carga

Las implementaciones modernas a menudo dividen TLS:

client -> CDN or load balancer -> reverse proxy -> origin

Each segment may have different ALPN behavior. The public side may negotiate HTTP/2 while the upstream side uses HTTP/1.1. Or the reverse proxy may accept h2 from clients but downgrade to HTTP/1.1 when talking to the application.

When analyzing a pcap, identify which segment you captured. A trace on the origin server may not show the public client handshake at all.

gRPC and ALPN

gRPC usually requires HTTP/2. If ALPN does not negotiate h2, gRPC clients may fail with protocol errors, unavailable errors, or connection reset messages.

For gRPC troubleshooting, preserve:

DNS answer.
TCP handshake.
TLS ClientHello.
TLS ServerHello.
ALPN protocol selected.
Any TLS alert.
First HTTP/2 frames if decrypted or visible through logs.

Even without decrypting payload, ALPN can prove whether HTTP/2 was negotiated.

Fallback is not always failure

HTTP clients may intentionally fall back to HTTP/1.1 when:

Server does not advertise h2.
Client policy disables HTTP/2.
TLS version or cipher constraints are incompatible.
Proxy strips or terminates the connection.
ALPN extension is missing.
A middlebox interferes with handshake.

The diagnostic question is whether fallback was expected for that route.

Debug checklist

Use this workflow:

Capture from TCP handshake through TLS handshake.
Confirm SNI hostname.
Check ClientHello ALPN list.
Confirm whether h2 is offered.
Check ServerHello selected ALPN.
Compare certificate with SNI.
Identify CDN, proxy, or load balancer termination.
Compare public-side and origin-side captures if needed.
Check whether the client library enables HTTP/2.
Preserve the handshake when trimming the pcap.

Final diagnosis

TLS ALPN and HTTP/2 issues should be diagnosed from handshake evidence. The key facts are whether the client offered h2, whether the server selected it, whether SNI routed to the right virtual host, and whether a proxy changed protocol between network segments.

PCAP Surgery helps keep the exact handshake packets needed to prove HTTP/2 negotiation, fallback, or proxy termination behavior.

Respuesta basada en paquetes para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

Respuesta directa y límite de aceptación

La respuesta breve a «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark» es: Analice SNI vs ALPN en protocolos de enlace TLS. Diagnostice fallas de negociación HTTP/2, respaldo h2 vs http/1.1, extensiones ClientHello, respuestas ServerHello ALPN y problemas de terminación de proxy en PCAP de Wireshark. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en PCAP Surgery.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark

Convierta «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 2: Analice SNI vs ALPN en protocolos de enlace TLS. Diagnostice fallas de negociación HTTP/2,

Trate «Analice SNI vs ALPN en protocolos de enlace TLS. Diagnostice fallas de negociación HTTP/2, respaldo h2 vs http/1.1, extensiones ClientHello, respuesta» como una puerta de aceptación independiente para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 3: ¿Qué hace ALPN?

Convierta «¿Qué hace ALPN?» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 4: Síntomas comunes

Trate «Síntomas comunes» como una puerta de aceptación independiente para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 5: ClienteHola evidencia

Convierta «ClienteHola evidencia» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 6: ServidorHola evidencia

Trate «ServidorHola evidencia» como una puerta de aceptación independiente para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 7: SNI y ALPN juntos

Convierta «SNI y ALPN juntos» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 8: Terminación de proxy y balanceador de carga

Trate «Terminación de proxy y balanceador de carga» como una puerta de aceptación independiente para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 9: gRPC and ALPN

Convierta «gRPC and ALPN» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 10: Fallback is not always failure

Trate «Fallback is not always failure» como una puerta de aceptación independiente para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Analice SNI vs ALPN en protocolos de enlace TLS. Diagnostice fallas de negociación HTTP/2, respaldo h2 vs http/1.1, exte	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
¿Qué hace ALPN?	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas comunes	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ClienteHola evidencia	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ServidorHola evidencia	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: