Reseña de Heritrix: fidelidad WARC y coste operativo del rastreo de archivo

Heritrix es el rastreador de archivo de código abierto de Internet Archive — la línea de software que está detrás de la Wayback Machine, en producción desde hace dos décadas. Su misión es capturar con fidelidad lo que entrega un sitio y guardarlo en archivos WARC que puedan reproducirse años después. Por dentro, es un motor Java en el que cada rastreo es un grafo de beans de Spring escrito en XML, y todo el ciclo del trabajo se gestiona mediante una API REST. No es un scraper: no hay sintaxis de selectores, ni mapeo de campos, ni filas al final.

Probé la versión 3.16.0 con un entorno local controlado y conté lo que realmente escribió, registro por registro. Lo que más destaca es la completitud: veinte URI obtenidas generaron sesenta y un registros WARC, con un digest del contenido y una IP de captura en cada respuesta, además de cada solicitud enlazada a la respuesta a la que pertenece, sin tocar ni un solo ajuste de configuración. Operarlo es justo lo contrario: 41 MB, 114 JAR (lib/ contiene 142 archivos; los otros 28 son textos LICENSE y NOTICE incluidos), y unos 750 líneas de configuración antes de la primera captura — aunque aquí todos los rastreos se ejecutaron sin interfaz gráfica, únicamente con curl.

El resultado de almacenamiento dejó ver un valor predeterminado menos obvio. Dos URLs del entorno devolvían contenido idéntico byte a byte, y el perfil estándar capturó y archivó ambas por completo: dos registros de respuesta y cero registros de revisit, a pesar de asignar a ambas respuestas el mismo digest del payload. La deduplicación por content-digest funciona cuando se añaden sus procesadores de historial; no viene activada en el perfil por defecto, y ahorra almacenamiento, no ancho de banda.

Qué es realmente Heritrix

Archivar no es extraer datos, y esa confusión de categorías conviene despejarla. Heritrix no te entrega filas. No hay CSV al final. Su salida es la conversación HTTP en sí —cabeceras, cuerpos y metadatos de captura— guardada en un formato pensado para preservación, y es la implementación de referencia de toda esa clase de trabajo. Pedirle una lista de precios de productos es como pedirle a un taquígrafo judicial un resumen.

Cifras actuales al 27 de julio de 2026: el repositorio tiene 3.285 estrellas y 36 incidencias abiertas, y 3.16.0 es la última versión publicada, el 2026-07-03. Precisamente esa fue la compilación que probé, así que aquí no hay ninguna queja por una versión antigua. La licencia tiene un matiz: el archivo LICENSE es Apache-2.0 sin más, pero el detector de GitHub devuelve "Other" porque algunos archivos de terceros incluidos llevan sus propios términos. Si Heritrix va a integrarse en un producto comercial, merece que alguien del área legal le dedique cinco minutos, en lugar de confiar en la insignia de la barra lateral.

Hay un hecho estructural que condiciona todo lo demás: Heritrix no conduce un navegador. Obtiene recursos por HTTP y extrae enlaces de los bytes recibidos. Su equivalente moderno en archivado, Browsertrix Crawler, hace justo lo contrario: usa Chromium real y registra lo que el navegador hizo de verdad. Ambos escriben WARC, pero esta reseña solo midió la ruta de Heritrix sin navegador; no comparó la escala ni el rendimiento de ninguno de los dos sistemas.

Cadenas, beans y SURT: cómo se monta de verdad un rastreo

Por dentro, un trabajo de Heritrix es un contexto de aplicación Spring. No está "configurado con Spring" — es un grafo de beans de Spring, escrito en XML, y cada parte del rastreo es un bean que puedes sustituir.

The frontier gestiona la cola de URI, particionada por host. Esa partición es la razón por la que la cortesía se comporta como lo hace, y más adelante se ve por qué importa.

Las cadenas de procesadores hacen el trabajo en tres etapas: una cadena de candidatos (¿debe programarse esta URI descubierta?), una cadena de captura (DNS, robots, obtención HTTP, extracción de enlaces) y una cadena de disposición (escritura en WARC, actualización de estado). Añadir una capacidad a Heritrix suele significar insertar un bean de procesador en el punto correcto de la cadena correcta, que es exactamente como activé la deduplicación.

Scope es una pila de DecideRules que opera sobre SURT — Sort-friendly URI Reordering Transform, que reescribe http://www.example.com/a como http://(com,example,www,)/a para que los prefijos de host queden ordenados en jerarquías. El scope predeterminado se genera a partir de los prefijos SURT de tus seeds. Las reglas aceptan y rechazan en secuencia; gana la última coincidencia.

El escritor WARC está en la cadena de disposición, y la cortesía vive en the frontier como tres números: delayFactor, minDelayMs, maxDelayMs. La obediencia a robots es una cadena de política en el fetcher.

Y todo eso se puede manejar mediante una API REST, que terminó siendo más importante de lo que esperaba.

La configuración es la parte más pesada de toda la experiencia

Lo que despliegas antes de la primera captura:

La mayor parte de esa configuración no la tocarás nunca. Pero no puedes omitirla, y hay dos campos obligatorios antes de que el rastreador haga nada: tu seed y metadata.operatorContactUrl. El valor estándar es un marcador de posición, y no empezará a rastrear hasta que lo sustituyas por una URL real que identifique a quien ejecuta el rastreo.

Ese requisito crea un punto de responsabilidad: el operador debe proporcionar una URL de contacto antes de que el rastreador arranque. No demuestra que la identidad sea correcta, que el rastreo esté autorizado o que cumpla las normas aplicables, pero sí hace que la información de contacto forme parte del trabajo y no de una costumbre opcional.

Dos hallazgos de configuración me sorprendieron de verdad.

Funcionó con un JDK más nuevo que el mínimo de la documentación. La documentación de primeros pasos pide Java 17 o superior. Heritrix 3.16.0 arrancó, sirvió su API REST y completó cada rastreo de este entorno en OpenJDK 26.0.1, sin --add-opens, sin --enable-preview ni trucos con el Security Manager. Ese resultado corresponde a un macOS arm64 concreto, no a una matriz de compatibilidad, pero confirma que esta versión probada no quedó limitada a JDK 17 en este equipo.

Nunca hace falta tocar la interfaz web. Todo el ciclo del trabajo va por REST, y automatizé todo con curl: crear el trabajo, PUT del archivo de beans, compilar, lanzar, reanudar, hacer polling hasta que el estado del controlador fue FINISHED, terminar y limpiar. Esa es la respuesta real a "¿se puede operar Heritrix en una canalización?": sí, sin navegador ni clics. Muchos artículos muestran capturas de la interfaz Jetty e insinúan que esa es la forma de uso. Es una comodidad, no una obligación.

Una nota de despliegue específica de este equipo: este Mac usa un proxy HTTP de sistema a través de Surge. El cliente Java de Heritrix heredó ese proxy y envió incluso el tráfico del entorno 127.0.0.1 a través de él, lo que produjo respuestas 503 pese a la lista de excepciones del sistema y a NO_PROXY. Iniciar la JVM con -Djava.net.useSystemProxies=false cambió la ejecución de 2×503 a 18×200. Fue una interacción con el entorno, no un defecto de Heritrix; ese parámetro solo importa cuando no conviene heredar la configuración de proxy del sistema.

Qué termina realmente en el archivo

Ejecuté el perfil estándar por defecto sobre un entorno controlado —un servidor local con un conjunto conocido de endpoints, incluidas páginas HTML, una cadena de profundidad de tres niveles, un robots.txt y un sitemap, y rutas deliberadamente configuradas con 404 y 500— y luego analicé el WARC registro por registro, en lugar de confiar en una línea de resumen.

Veinte URI obtenidas produjeron sesenta y un registros:

Una proporción limpia 1:1:1 de respuesta, solicitud y metadatos por URI, de serie y sin que yo configurara nada. Y la completitud de cada registro se mantuvo bajo inspección:

Y el estado HTTP se conservó tal cual, incluidos los feos: 200 OK, 404 Not Found y 500 Internal Server Error aparecen como líneas de estado reales en las respuestas almacenadas, en lugar de descartarse como fallos.

Ese último punto separa el archivado del scraping más que ningún otro. Un scraper trata un 500 como un error que reintentar o saltar. Un archivador lo trata como lo que el servidor dijo en ese momento, que es un hecho que merece conservarse. La salida de Heritrix describe esa estructura de registros; lo que no había visto en ningún sitio era la multiplicidad medida y el enlace 20/20 sobre un conjunto de endpoints conocido. Se sostiene.

El resultado de la deduplicación, medido en ambos sentidos

Mi entorno servía /dup/one y /dup/two con cuerpos idénticos byte a byte. URLs distintas, mismo contenido: justo el caso para el que existe la deduplicación por content-digest. Lo ejecuté dos veces: una con el perfil estándar, y otra tras insertar la cadena de historial de digest (BdbContentDigestHistory, más ContentDigestHistoryLoader en la cadena de captura y ContentDigestHistoryStorer después del escritor WARC).

De serie, ambas respuestas recibieron el mismo digest, pero ningún procesador de historial actuó sobre él y ambos payloads se escribieron completos. Al añadir la cadena, la segunda captura pasó a ser un registro WARC revisit que apunta al digest del payload idéntico, que es exactamente para lo que sirve la especificación WARC 1.1 cuando define los revisits.

Nada de esto es un secreto. La página Duplication Reduction Processors dice que skipIdenticalDigests tiene valor predeterminado false y que la deduplicación independiente de la URL necesita esos beans loader y storer. No es un comportamiento oculto descubierto por casualidad; como casi todo lo medido aquí, es comportamiento documentado de Heritrix con una cifra real asociada. La brecha está entre la documentación y lo que la gente cree, y en mi experiencia la creencia suele ser "Heritrix deduplica" y punto, sin asterisco de configuración.

Dos corolarios que conviene interiorizar:

La deduplicación ocurre al escribir, no al transferir. Esto es más un mecanismo que algo medido aparte, pero se deduce directamente de cómo funcionan los digests de contenido: solo puedes comparar un digest después de que los bytes hayan llegado, así que la segunda URL se obtiene del origen igual. Activar la cadena reduce lo que guardas, no lo que transfieres ni lo que el servidor destino tiene que entregar. Quien presupone la deduplicación como ahorro de cortesía o de ancho de banda lo está entendiendo al revés.

Las estimaciones de almacenamiento basadas en "ya deduplicará" pueden fallar mucho. Si vas a archivar un sitio con mucha duplicación de plantillas —PDF espejados, páginas de destino repetitivas, variantes de vista para impresión de los mismos artículos— y dimensionas discos suponiendo que los cuerpos idénticos se colapsan, el perfil estándar puede consumir bastante más almacenamiento de lo previsto. El entorno de dos URLs demuestra el comportamiento por defecto, no su efecto a escala de millones de URI; ese efecto depende de la tasa de duplicados, el tamaño del payload y el diseño del recrawl.

Scope y robots hicieron exactamente lo que prometen

La palabra de un rastreador sobre lo que no obtuvo vale muy poco, así que ambas cosas se midieron con un contador de accesos del lado del servidor —el propio servidor destino contando las solicitudes, independientemente de lo que Heritrix registrara.

Scope. Mientras tanto, el host dentro de scope se rastreó con normalidad, así que la disciplina del scope funcionó y no fue que el rastreo estuviera roto. Conviene una salvedad: aquí solo ejecuté la rama del scope predeterminado, no un control positivo con un scope ampliado, así que léelo como confirmación del diseño documentado y no como una prueba de doble vía.

Robots. El enlace siempre era accesible; solo la política de robots lo suprimió. La obediencia es real y la vía de escape también, y esa es la combinación correcta: algunos mandatos de archivado legítimamente deben anteponerse a robots, y eso debería exigir escribir deliberadamente ignore en un archivo de configuración.

Cortesía: 57,7 segundos para rastrear veinte páginas locales

Un solo número decide si Heritrix encaja en tu proyecto.

Mismo entorno, mismo tratamiento de tres ejecuciones, en un único host local con latencia inferior al milisegundo:

El retardo resultante cae justo en el suelo de minDelayMs: en un origen submilisegundo, delayFactor × tiempo_de_captura es insignificante y el mínimo domina por construcción. La relación entre las dos filas no es útil porque el denominador con cortesía cero son solo decenas de milisegundos y varía de una ejecución a otra. El resultado estable es el suelo absoluto: el Heritrix por defecto esperó unos tres segundos entre solicitudes al mismo host en este entorno, convirtiendo un rastreo de veinte páginas en aproximadamente un minuto de tiempo real.

Una forma concreta de sentirlo: supón que una biblioteca universitaria necesita archivar un sitio gubernamental de 50.000 páginas antes de que se retire, y todo está en un único host. Con un suelo de 3 segundos por host, eso son 150.000 segundos de espera impuesta — unos 42 horas, o cerca de un día y tres cuartos, antes incluso de contar el tiempo de captura. Es una aritmética basada en mi suelo medido de 3.036 ms: 50.000 x 3,036 s = 151.800 s = 42,2 h; incluso con el mínimo configurado de 3.000 ms son 41,7 h, que redondea a 42, no a 41. No es un rastreo medido, pero sí la cuenta que necesita tu plan de proyecto.

Para ser justos, la cortesía de Heritrix es por host, porque the frontier organiza las colas por host. Un rastreo amplio sobre miles de dominios se paraleliza entre esas colas y no hereda ese techo de forma global. Mi entorno era un único host, que es el peor caso para este número concreto. Si tu objetivo de archivado es un sitio grande y único, ese peor caso es tu caso.

Y es una característica. Ese retardo es lo que hace que un rastreador de archivo sea algo que el propietario de un sitio tolera en lugar de bloquear. Ajustarlo a la baja es una decisión sobre el servidor de otra persona, y la herramienta hace esa decisión explícita en vez de ser agresiva por defecto.

Lo que no probé

Estas mediciones cubren la disciplina del rastreo en un entorno controlado, y nada más. Fuera de ese límite:

• Deduplicación entre rastreos y recrawl. Solo medí la deduplicación por content-digest dentro de un mismo rastreo. Conservar una base de datos de historial de URI entre rastreos separados (FetchHistoryProcessor + PersistLog) es otro mecanismo, y no lo ejercité.
• Escala y estabilidad a largo plazo. No hubo frontier de un millón de URI, ni checkpoint y restauración, ni ejecución de varios días. Mi entorno mide disciplina, no resistencia.
• Captura renderizada con JavaScript. La captura por defecto de Heritrix no usa navegador, y eso es lo que medí. Los comportamientos opcionales basados en navegador no se probaron aquí.
• Cortesía en un origen con alta latencia. La latencia local es submilisegundo, así que minDelayMs dominó por construcción. No está aislado en mis datos cómo escala delayFactor frente a un servidor real lento.
• Cobertura de sitemap. Se solicitó robots.txt y se siguió la directiva de sitemap, pero no verifiqué por separado la recuperación de cada entrada <loc>.

Qué conviene dejar explícito antes del primer trabajo de producción

El perfil estándar es largo, pero las decisiones que cambian el significado de un archivo son bastante compactas. Empieza por el scope. Las seeds generan prefijos SURT por defecto, y las DecideRules pueden ampliarlas o reducirlas en secuencia. Revisa el orden final de reglas con URLs representativas dentro y fuera de scope, y luego verifica el resultado con tráfico del lado del servidor u otro registro de solicitudes independiente. Un informe de rastreo por sí solo no puede demostrar que un host excluido nunca fue contactado.

Después, decide qué significan para la colección la política de robots y la identidad del operador. El valor por defecto probado obedeció la regla de disallow del entorno, mientras que cambiar robotsPolicyName a ignore hizo que la ruta bloqueada se obtuviera. Ese cambio es mecánicamente simple e institucionalmente importante. Registra quién lo aprobó y por qué, junto con un operatorContactUrl funcional; la URL obligatoria da al propietario del sitio una vía de vuelta al operador, pero no aporta la justificación de autorización.

La planificación de almacenamiento necesita su propia decisión explícita. Si los cuerpos idénticos deben convertirse en registros revisit, añade y revisa los procesadores de historial de content-digest antes de dimensionar el archivo. La cadena probada afectó a la representación después de la captura, así que el tráfico al origen sigue teniendo que presupuestarse para ambas URLs. La deduplicación entre rastreos es un mecanismo aparte y no debería inferirse de este resultado de dos URLs y un solo rastreo. Un pequeño rastreo de validación con cuerpos duplicados conocidos es una forma barata de confirmar que el grafo de beans desplegado produce los tipos de registro esperados.

Por último, trata la cortesía como un parámetro de planificación y no como un ajuste de última hora. En el entorno local de un solo host, minDelayMs dominó el tiempo total. Un proyecto real debería calcular el suelo por host configurado frente al número de hosts objetivo y el plazo de la colección, y luego probarlo con latencias representativas. Los rastreos amplios y los de un solo sitio estresan de forma distinta el frontier particionado por host; esta reseña solo midió el segundo caso. Mantén también el ciclo REST en el runbook: compilar, lanzar, reanudar, hacer polling, terminar y limpiar son estados separados que vale la pena observar en automatización.

Pros y contras

Pros

• La completitud del archivo es excelente por defecto: 20/20 respuestas con digest del payload, IP de captura y enlace completo solicitud↔respuesta, sin necesidad de configurar nada.
• Conserva las respuestas de error como hechos: las líneas de estado 200, 404 y 500 se almacenan tal cual.
• La disciplina de scope quedó verificada con un contador del lado del servidor: cero capturas fuera de scope mientras el host dentro de scope se rastreaba con normalidad.
• La obediencia a robots realmente suprime la captura, con un escape deliberado mediante ignore para archivados obligatorios.
• Totalmente sin interfaz gráfica, vía REST: crear, compilar, lanzar, hacer polling y limpiar, todo con curl, sin clics en la UI.
• Funciona limpio en OpenJDK 26.0.1 sin banderas de JVM, lo que es una higiene Java moderna mejor de la que suelen ofrecer bases de código de veinte años.
• La URL obligatoria de contacto del operador evita que el rastreador se ejecute de forma anónima.
• Cada parte del rastreo es un bean intercambiable, por eso activar la deduplicación fueron tres inserciones de bean y no un fork.

Contras

• La deduplicación por content-digest está desactivada por defecto y escribe los payloads idénticos completos, una trampa real para la planificación de almacenamiento.
• El despliegue es pesado: distribución de 41 MB, 114 JAR, un motor Java más Jetty y una configuración de trabajo Spring de unas 750 líneas.
• La cortesía por defecto impone un suelo de unos 3 segundos por host; un rastreo de 20 URI en un solo host tardó 57,7 segundos.
• No hay renderizado JavaScript en la ruta por defecto, así que el contenido que solo existe del lado del cliente no se capturará.
• La superficie de configuración recompensa la experiencia y castiga el uso casual; no hay una vía de cinco minutos para hacer el primer rastreo.
• Nada en la salida es dato estructurado. Extraer campos de un WARC es otro proyecto distinto.

Quién debería usarlo y quién debería alejarse

Heritrix es para instituciones y equipos cuyo entregable es el archivo en sí. Bibliotecas, archivos nacionales, preservación legal y de cumplimiento, grupos de investigación que capturan la web como fuente primaria, cualquiera que necesite demostrar dentro de cinco años qué sirvió una URL en una fecha concreta. Si las palabras "WARC", "replay" y "provenance" ya forman parte de tu vocabulario, esta es la herramienta alrededor de la cual se construyó el resto de tu ecosistema, y su peso es el precio de esa interoperabilidad.

Su frontier particionado por host y su largo uso en archivado web lo convierten en un candidato plausible para rastreos amplios a través de muchos dominios. Eso es una consideración arquitectónica e histórica del proyecto, no un resultado de escala derivado de este entorno; el rendimiento sostenido, la recuperación de checkpoints y el comportamiento a un millón de URI siguen sin probarse aquí.

No lo elijas si quieres datos y no un archivo. Si tu objetivo es una hoja de cálculo de productos, listados o contactos, Heritrix hará un trabajo impecable capturando páginas que después tendrás que pasar por otra canalización para extraer — y además habrás pagado por un motor Java, una configuración Spring y un suelo de cortesía de 3 segundos. Tampoco lo elijas si tus objetivos son aplicaciones de una sola página renderizadas en cliente, donde un capturador sin navegador obtiene la carcasa y no el contenido; para eso, la herramienta correcta es un archivador basado en navegador. Y déjalo de lado si necesitas un primer resultado hoy, porque la curva de puesta en marcha es real.

Alternativas, y dónde encaja una API gestionada

Dentro del archivado, el equivalente moderno más directo es Browsertrix Crawler — un archivador basado en navegador que controla Chromium y registra lo que el navegador hizo. Puede capturar contenido generado por JavaScript que Heritrix no ve en sus respuestas HTTP por defecto, a cambio de mayor complejidad de despliegue y ejecución del navegador. Esta reseña no hizo un benchmark cara a cara, así que la decisión empieza por los requisitos de captura: si el estado lo genera el navegador, conviene un archivador con navegador; si se trata de recursos HTTP convencionales, Heritrix sigue siendo su vía natural.

Reseña relacionada: reseña de Browsertrix Crawler.

Para un problema de naturaleza distinta —no quieres un archivo, sino datos estructurados obtenidos de páginas— compara Heritrix con sistemas de extracción por su salida, en lugar de tratarlos como rastreadores equivalentes. Heritrix es gratuito y autogestionado: tú ejecutas la JVM, mantienes el archivo de beans, dimensionas los discos y ajustas la cortesía. Ese modelo encaja cuando la preservación es el entregable.

Divulgación: Thunderbit es el producto del editor y no se probó en este entorno de Heritrix. Pertenece a la categoría de extracción gestionada: su salida es contenido de páginas o registros estructurados, no archivos WARC pensados para preservación. Elige un archivador cuando necesites capturas reproducibles y procedencia; considera un servicio de extracción cuando el entregable sean filas o texto de documentos y la operación gestionada sea aceptable.

El archivado trae su propia cuestión de permisos, y no es la misma que la del scraping. Heritrix obedece robots.txt por defecto y exige que te identifiques antes de obtener un byte, lo cual es una buena base; pero un rastreo conforme a robots no es automáticamente un rastreo autorizado. Copyright, términos de servicio, datos personales y el mandato de tu propia institución se superponen encima, y la política ignore existe para organizaciones con base legal para usarla, no como un simple interruptor de conveniencia. Si vas a poner en marcha un programa de archivado, aclara el alcance de autorización antes de llenar los discos, y consulta el lado legal del web scraping y el archivado si es un terreno nuevo.

Prueba Thunderbit para extracción de datos web

Veredicto

¿Deberías usar Heritrix? Sí, si tu salida es un archivo y tienes a alguien dispuesto a aprender beans de Spring.

El entorno probado deja una decisión clara: el perfil estándar conservó de forma consistente la respuesta, la solicitud y los metadatos de captura; los controles de scope y robots afectaron las capturas del lado del servidor tal como estaban configurados; y todo el ciclo del trabajo se ejecutó por REST. Son propiedades útiles para una canalización de archivado, dentro del límite pequeño de un solo host que se probó aquí.

Los costes operativos también son claros: una distribución Java y una gran configuración Spring, un retardo por host configurado que dominó este rastreo local, y una deduplicación por content-digest que requiere procesadores de historial adicionales. Los equipos que necesitan fidelidad WARC pueden aceptar esos costes; los equipos que necesitan campos extraídos deberían empezar en otra categoría.

Antes de un rastreo de producción, verifica la cadena de deduplicación, los ajustes de cortesía, el scope, la política de robots, la identidad del operador y las hipótesis de almacenamiento frente a la configuración real del trabajo. El perfil estándar es un punto de partida, no una declaración implícita de esas decisiones operativas.

Prueba Thunderbit para extracción de datos web Get Started Free

Preguntas frecuentes

¿operatorContactUrl hace que un rastreo esté autorizado? No. Obliga a que el trabajo incluya una URL de contacto, lo que da a los operadores del sitio una vía de responsabilidad, pero no establece permiso, exactitud de identidad, estado de copyright ni cumplimiento normativo. Eso sigue siendo una decisión de despliegue ajena al rastreador.

¿La deduplicación por content-digest reduce las solicitudes al origen? No en la configuración probada aquí. Ambas URLs se obtuvieron antes de que sus digests de contenido pudieran compararse. La cadena de historial cambió cómo se representó el segundo payload en el almacenamiento WARC; no convirtió la segunda URL en una solicitud de red omitida.

¿Puede Heritrix funcionar sin su interfaz web? Sí. El ciclo probado —crear, subir la configuración, compilar, lanzar, reanudar, hacer polling, terminar y limpiar— se ejecutó a través de la API REST con curl. La interfaz Jetty integrada no fue necesaria.

¿El perfil estándar de Heritrix deduplica payloads idénticos? No en el entorno tal como se configuró. El perfil estándar almacenó ambas respuestas idénticas como registros completos de respuesta. Añadir la cadena de historial de content-digest cambió la segunda captura a un registro revisit, así que la deduplicación es una decisión de canalización que debes configurar y verificar, no un valor predeterminado automático.

¿Cómo debo elegir un retardo de cortesía? Toma los tiempos locales de aquí como una comprobación del mecanismo, no como una recomendación de producción. Fija el retardo según las reglas del sitio objetivo, el acuerdo con el operador, la capacidad del servidor, el propósito del rastreo y tu política de reintentos/concurrencia, y luego confirma en los logs los intervalos reales entre solicitudes al mismo host.