Huella TLS

La huella TLS identifica a un cliente por la forma de su handshake TLS — el orden de los cifrados, las extensiones, los grupos admitidos —, cosas que todas difieren entre un navegador real y un cliente HTTP programado. Ocurre antes de que tu línea de petición se envíe siquiera.

No se arregla con una cabecera User-Agent. La cabecera está en la petición; la huella está en la conexión.

El modo de fallo no es un bloqueo

Esta es la parte que atrapa a la gente. Una huella que no coincide a menudo no produce un 403. Produce una respuesta correcta a la que le faltan los datos.

Medido en una plataforma grande:

Las dos son HTTP 200. Las dos devuelven una página real. A una de ellas le falta lo único que querías. Nada en tu código da error — y por eso este caso concreto está documentado en la página de la ruta y no enterrado en un documento de resolución de problemas.

Por qué se hace así

Un bloqueo duro es fácil de detectar y fácil de rodear. Servir una página más ligera a los clientes que no son navegadores le sale más barato a la plataforma, es más difícil de notar, y degrada a los scrapers calladamente en lugar de provocarlos. Desde el lado de la plataforma es el mejor diseño.

Qué significa para tu pila

• Un cliente HTTP solo con cabeceras no sirve. Necesitas algo que reproduzca el handshake de un navegador, o un navegador sin interfaz.
• El ancho de banda sube, no baja. La página que contiene los datos es a menudo tres o cuatro veces más grande que la que no — 960 KB contra 268 KB en el caso de arriba. Ese es el verdadero coste de la recolección.
• Tus comprobaciones de salud tienen que buscar el dato, no el estado. Un monitor que afirma 200 se queda en verde durante todo este fallo.

La regla general

Cualquier cosa que pueda devolver una página sin los datos necesita un campo ancla — un valor que tiene que estar presente para que la respuesta cuente como respuesta. Los códigos de estado no son una comprobación de completitud, y tratarlos como tal es la versión más común de un fallo silencioso.