Informe del incidente de octubre de AdGuard para Windows: Post Mortem

Recientemente, algunos usuarios de AdGuard para Windows han estado experimentando problemas con su aplicación. Después de lanzar la versión 7.22, descubrimos que la actualización causaba fallos ocasionales al cargar páginas en los navegadores. Aunque el problema se mitigó rápidamente en Chrome, persistió por más tiempo en Firefox, ya que el error resultó ser poco común y difícil de reproducir, provocado por una combinación inusual de factores que no fueron detectados durante las pruebas.

A la fecha de esta publicación, hemos lanzado un hotfix — AdGuard para Windows v7.22.1 — que resuelve el problema por completo. Asegúrate de que tu aplicación esté actualizada a la última versión para una experiencia fluida. Si usas AdGuard en otras plataformas, no necesitas hacer nada; todo debería funcionar con normalidad.

Lamentamos sinceramente las molestias y esperamos que este incidente no afecte tu experiencia general con AdGuard. Fue un caso aislado que no volverá a ocurrir. Además de resolver el problema técnico, revisamos nuestros procesos internos y ya implementamos varias mejoras para evitar situaciones similares en el futuro.

A continuación mostramos la línea de tiempo de los eventos que llevaron al incidente, seguida de más detalles técnicos y las medidas que estamos tomando para prevenir que algo así vuelva a suceder.

Línea de tiempo de los eventos

2 de octubre

Lanzamos AdGuard para Windows v7.22.

4 de octubre

Un usuario abrió un issue en GitHub reportando problemas al cargar páginas y, eventualmente, un error Timed out después de actualizar a la versión 7.22.

6 de octubre

Nuestro equipo de QA comenzó a investigar el problema, pero no pudo reproducirlo. Ese mismo día el equipo escaló el problema a los desarrolladores y comenzaron las discusiones internas.

16 de octubre

A medida que más usuarios se unían a la discusión en GitHub, los reportes y votos positivos se acumularon. Lamentablemente, en esta etapa, el equipo de QA no siguió las pautas internas de escalamiento para issues de este nivel. Tuvimos grandes dificultades para reproducir el error, en parte por la inconsistencia de los reportes de los usuarios. Esto llevó al equipo a suponer que el problema había sido introducido un par de versiones atrás y que, por lo tanto, no requería un hotfix. Como resultado, se pospuso para la siguiente versión programada y, aunque la tarea fue marcada como P1: Crítica, no se escaló correctamente y se perdió tiempo valioso.

30 de octubre

Después de 24 días, el problema volvió a surgir internamente, revelando su verdadero impacto en los usuarios. Una vez que logramos reproducirlo, pudimos estimar el daño con mayor precisión. Inmediatamente comenzamos a trabajar en un hotfix (v7.22.1). Sin embargo, gran parte del tiempo y esfuerzo se dedicó a reproducir el error de manera consistente y comprender su causa principal. Varias hipótesis fueron probadas y descartadas durante el proceso.

Durante la investigación, también descubrimos un error de Firefox relacionado con conexiones QUIC, que ralentizaba aún más la carga de páginas y complicaba la depuración. Además, se identificó otro problema relacionado con la falta de filtrado de conexiones QUIC cuando AdGuard se ejecutaba junto a AdGuard VPN en modo de compatibilidad con Wintun deshabilitado.

1 de noviembre

Identificamos parcialmente la causa del problema y encontramos una forma de reproducirlo. Se implementó una corrección en DnsLibs, nuestro motor de filtrado DNS, y se lanzó una versión nocturna para pruebas.

5 de noviembre

Detectamos la causa principal: un error en el componente de detección de bucles de enrutamiento de CoreLibs, el motor de filtrado de AdGuard. El problema fue corregido rápidamente y se lanzó una segunda versión nocturna.

6 de noviembre

Las pruebas mostraron que las primeras correcciones resolvían la mayoría de los problemas con conexiones TCP, pero aún persistían algunos problemas relacionados con UDP. Para minimizar el impacto en los usuarios, decidimos lanzar las correcciones en dos fases. Primero, una tercera versión nocturna abordó estos problemas adicionales, incluyendo ajustes finales en las librerías y actualizaciones de las instrucciones del controlador. Después preparamos y probamos exhaustivamente el parche v7.22.1, que se lanzó ese mismo día.

Detalles técnicos

El error

El error en AdGuard para Windows v7.22 causaba congelamientos ocasionales e impredecibles al cargar ciertas páginas en Firefox. No afectó tanto a los usuarios de Chrome. El problema comenzó después de que CoreLibs v1.19 introdujera protección contra bucles de enrutamiento, un mecanismo diseñado para evitar que el tráfico se redirija hacia sí mismo.

El error tenía dos causas principales. Primero, un fallo de programación excluyó un puerto de la verificación del bucle, lo que hacía que algunas conexiones legítimas —como solicitudes del navegador— fueran bloqueadas. Esto se activaba por solicitudes internas del propio AdGuard, como las OCSP. Después de tales solicitudes, la siguiente conexión del navegador se interrumpía.

Segundo, la verificación se aplicaba en el lugar equivocado, a conexiones ya establecidas, lo que provocaba bloqueos innecesarios.

¿Por qué necesitamos protección contra bucles de enrutamiento?

Un bucle de enrutamiento ocurre cuando el tráfico regresa a la misma aplicación que lo generó. Esto puede causar lentitud y alto uso de CPU. Aunque normalmente no ocurren, pueden aparecer debido a interacciones con otros programas. Para prevenirlos, AdGuard rastrea conexiones salientes por su dirección de origen y termina cualquier conexión que regrese a esa misma dirección.

¿Por qué afectó tan poco a Chrome?

Porque solo se interrumpía la conexión inmediatamente posterior a una solicitud interna, y Chrome vuelve a intentar automáticamente la conexión tras un fallo. Firefox, en cambio, no reintenta solicitudes tras errores de red, lo que hacía el problema mucho más evidente.

¿Y en Linux y Android?

El problema no se detectó en la etapa de CLI con la versión 1.19. En Linux solo ocurría en modo automático y principalmente en Firefox, así que muy pocos usuarios cumplieron esas condiciones. Tampoco apareció en AdGuard para Android v4.12, aun usando CoreLibs 1.19, porque las direcciones de entrada y salida eran distintas, evitando la condición que desencadenaba el error.

El diagnóstico

El diagnóstico fue particularmente difícil. AdGuard abre pocas conexiones de servicio y los intentos repetidos de reproducir el fallo reutilizaban solicitudes OCSP cacheadas, lo que impedía que el error apareciera. Además, el problema afectaba solo una conexión descendente a la vez. Chrome reintenta automáticamente, mientras que Firefox no.

Un error adicional de Firefox descubierto en el proceso

Durante la investigación encontramos que una parte de los reportes tenía otros síntomas, presentes incluso en versiones anteriores de AdGuard. Así descubrimos un error en Firefox para Windows relacionado con conexiones HTTP/3.

En resumen: Firefox intenta conexiones HTTP/3 inmediatamente cuando un sitio anuncia soporte, incluso si aún no están disponibles. AdGuard actualmente no filtra HTTP/3 de forma predeterminada, por lo que HTTP/3 queda bloqueado cuando el filtrado HTTPS está habilitado. Esto provoca pausas de 20–30 segundos antes de que Firefox reasigne las solicitudes a HTTP/2.

AdGuard ahora modifica los registros DNS de tipo HTTPS para ocultar el parámetro h3 cuando el filtrado HTTP/3 está deshabilitado, evitando retrasos innecesarios.

La corrección

La solución se aplicó en dos fases.

Primero, corregimos la lógica de coincidencia de conexiones para incluir correctamente el puerto. Esto resolvió la mayor parte del problema, aunque persistían falsos positivos por la reutilización de puertos en Windows. Una versión nocturna del 5 de noviembre ayudó a la mayoría de los usuarios.

Sin embargo, aún había rastros del problema. Windows puede reutilizar un puerto menos de un segundo después de liberar un socket, lo que provocaba falsos positivos adicionales cuando conexiones no relacionadas compartían dirección y puerto.

Aunque nadie reportaba problemas nuevos, muchos usuarios aún podían verse afectados. Esto llevó a la segunda fase, que abordó estos casos y resultó en el hotfix final v7.22.1, que resolvió el problema por completo.

Medidas de prevención

Este problema no se detectó antes principalmente debido a la dificultad de reproducirlo en condiciones normales de prueba, combinada con una atención insuficiente a los comentarios de los usuarios.

Actualmente estamos actualizando nuestros procesos de QA y desarrollo, con un enfoque particular en combinar una supervisión más estricta, mayor automatización y pruebas y comunicación más rigurosas dentro de los equipos. Con esto, buscamos evitar incidentes similares en el futuro y garantizar la confiabilidad de AdGuard para todos los usuarios.

Cambios en el flujo de trabajo del equipo de QA

El equipo de QA comenzará a prestar más atención a la cantidad de comentarios y votos positivos en los Issues de GitHub. Para minimizar el factor humano, este monitoreo no dependerá únicamente de la revisión manual: se introducirán mecanismos de automatización para rastrear la actividad y el número de votos en los issues públicos. Si este enfoque resulta efectivo, podrá ampliarse y aplicarse a todos los equipos de QA en todos los proyectos de AdGuard.

Se llevará a cabo una sesión informativa adicional basada en nuestras Triage Guidelines, y se introducirá una práctica obligatoria para la evaluación interna de issues en Jira. Este proceso requerirá una justificación basada en nuestras Triage Guidelines estructuradas, lo que ayudará a garantizar consistencia y transparencia en las decisiones de priorización.

El equipo también preparará una lista de preguntas de diagnóstico para los usuarios, lo que facilitará identificar y analizar problemas relacionados con el filtrado basados en la retroalimentación de los usuarios.

Finalmente, se implementarán varias pruebas automatizadas nuevas para evitar que problemas similares vuelvan a ocurrir. Se está desarrollando un script de pruebas de rendimiento para evaluar la velocidad de filtrado de páginas en distintos navegadores. Una vez que se defina una referencia de rendimiento, todas las versiones posteriores se medirán en relación con ella. Actualmente, las pruebas automatizadas solo se utilizan en Google Chrome, pero planeamos extenderlas también a Firefox. Además, se crearán pruebas para medir la velocidad de carga de un conjunto definido de páginas “problemáticas” en estos navegadores. Esta lista se basará en sitios conocidos por generar problemas y continuará ampliándose, comenzando con aquellos identificados durante la investigación de este incidente —por ejemplo, discord.com.

Cambios en el flujo de trabajo del equipo de desarrollo

Los equipos de desarrollo dedicarán más atención a agregar nuevas pruebas —incluyendo pruebas de integración— para las nuevas funcionalidades cuando sea posible, con el fin de reducir la probabilidad de que aparezcan errores en lanzamientos futuros. También se pondrá mayor énfasis en proporcionar documentación técnica detallada para las nuevas funciones y en asegurar que todos los equipos involucrados estén debidamente informados sobre la necesidad de probar la nueva funcionalidad en busca de posibles problemas y casos límite.

Al integrar nuevas versiones de CoreLibs en los productos, los equipos ahora esperarán la aprobación explícita del equipo de CoreLibs antes de continuar. En este momento, este proceso de integración se lleva a cabo de forma algo “aislada”, lo que aumenta el riesgo de que se pasen por alto problemas.

Conclusión

Queremos disculparnos nuevamente con todos los usuarios afectados por este incidente y agradecer sinceramente a quienes proporcionaron retroalimentación y nos ayudaron a navegar esta situación tan complicada. En adelante, también seremos más rápidos y transparentes al comunicarnos con nuestros usuarios sobre cualquier problema crítico que pueda tener un impacto significativo.