Un sistema de negocio que simplemente no carga, y otro que carga para todos excepto para el puñado de solicitudes que una sola regla sigue devorando, llegan a la mesa de ayuda pareciendo el mismo ticket. No son la misma falla, y no se solucionan de la misma manera. Aquí está cómo distinguirlos rápidamente, los filtros de registro y rutas de menú exactos a revisar en cada etapa, y las causas que explican la mayoría de estos tickets.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Ambos parecen la misma página en blanco para quien reportó el ticket — la diferencia solo aparece cuando uno va a buscarla.
Una aplicación web detrás de un WAF puede volverse inalcanzable por razones que no tienen nada que ver con sus reglas de seguridad — una ruta rota hacia el servidor de origen, una negociación SSL que el navegador del cliente no puede completar, o el propio WAF funcionando a máxima carga. También puede volverse inalcanzable, o parcialmente inalcanzable, porque una de sus propias reglas de protección está haciendo exactamente lo que se configuró para hacer: bloquear una solicitud que parece un ataque pero no lo es. Tratar el segundo problema como el primero, o al revés, desperdicia los primeros veinte minutos de casi todos estos tickets.
A continuación, el árbol de fallas en el que se basa esta nota, las comprobaciones de cada rama con los filtros de registro y rutas de menú exactos a usar, las causas que aparecen una y otra vez tras las primeras comprobaciones, y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.
La inaccesibilidad relacionada con el WAF se divide en exactamente dos formas: el sitio está realmente caído, o el conjunto de reglas está deteniendo tráfico que debería permitirse.
Ubicar primero el síntoma en este árbol ahorra mucho retroceso más adelante — indica cuál de las secciones siguientes aplica realmente a lo que está viendo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Si el sitio está realmente caído se responde con las mismas comprobaciones operativas que haría para cualquier servicio web — CPU, conectividad, el protocolo de enlace TLS. Si una regla es responsable solo se manifiesta en tres registros específicos, y solo si la regla se configuró para escribir en ellos, que es exactamente la trampa alrededor de la cual se construye la siguiente sección.
Tres lugares distintos a revisar, tres soluciones distintas — y un ajuste que decide si siquiera verá una entrada de registro de lo que acaba de pasar.
Antes de tocar cualquier regla, descarte las causas que no tienen nada que ver con la política de seguridad del WAF.
Status > System Overview -- CPU / memory usage at the time of the fault
Status > Historical Data -- filter: Web Traffic / Web Connections / New Web Connections / Web Requests
System > System Maintenance > Packet Capture
interfaces: Lo, business (protect)
match: the failing GET/POST -- compare client-to-WAF vs WAF-to-origin
// origin sends RST -> server is refusing the request, not a WAF issue
// WAF sends RST to client -> block is happening on the WAF side, check Branch B
System > System Maintenance > Running Mode Switch
bridge passthrough / physical passthrough -- confirms whether the WAF is the variableSi el cliente realmente ve una página de bloqueo, el rastro en el registro suele existir — solo hay que buscar en el lugar correcto.
Sin página de bloqueo, sin entrada de registro evidente, y el dueño del negocio jura que nada cambió — esto casi siempre es una regla configurada para bloquear sin registrar.
Log > Application-Layer Protection Log -- Custom Query, filter by server / client IP
Log > Traffic Control Log
Log > CC Protection Log
// no block entry in any of the three logs, but disabling the rule group fixes it:
Policy > Rule Groups > Search Rule
action = "Block, No Alert" OR action = "Drop, No Alert"
-> change action to "Detect Only" // makes the WAF start logging what it blocks
// once a block entry exists:
Alert Details > Triggered Rule ID > [rule page] > "Add Current URL to Whitelist"
// overlapping whitelist paths -- longer, more specific URL must be listed ABOVE the shorter one
/api/v1/order/query/detail <- list first
/api/v1/order/query <- shorter, overlapping path, listed afterUna vez que las ramas anteriores le han indicado dónde está el problema, estas cuatro causas explican la mayor parte de lo que realmente falla.
SÍNTOMAEl equipo de negocio insiste en que nada cambió, los tres registros de protección no muestran nada en el momento de la falla, y sin embargo deshabilitar el grupo de reglas lo soluciona al instante.
CAUSALa acción de una regla puede configurarse como «Bloquear, sin alerta» o «Descartar, sin alerta» — ambas detienen la solicitud exactamente como una regla de bloqueo normal, pero ninguna escribe una entrada en el registro de protección de capa de aplicación. Desde el punto de vista del registro, no pasó nada; desde el punto de vista del cliente, el sitio está roto.
SOLUCIÓNVaya a Política > Grupos de reglas > Buscar regla, filtre específicamente estas dos acciones, y cámbielas a «Solo detectar» durante la resolución de problemas para que el WAF comience a producir las entradas de registro que realmente necesita ver.
SÍNTOMAEl acceso de negocio parece una falla de red — intermitente, difícil de reproducir, ninguna regla parece estar involucrada — y por más que filtre los registros no encuentra nada.
CAUSACuando la dirección de la interfaz de gestión del WAF cae en la misma subred que la interfaz de negocio o la IP de un sitio protegido, ambas pueden interferir entre sí de maneras que se presentan como un problema de conectividad genérico en lugar de algo que los registros de seguridad llegarían a capturar.
SOLUCIÓNMantenga la interfaz de administración, la interfaz de negocio y la dirección IP de cada sitio protegido en subredes distintas entre sí. Esta es una comprobación de diseño de red, que se hace una vez, no una corrección por cada incidente.
SÍNTOMAUna URL específica — generalmente una que es consultada o actualizada con frecuencia por una integración real o un usuario activo — se vuelve intermitentemente inalcanzable, mientras el resto del sitio funciona bien.
CAUSALa protección CC (anti-inundación) se activa por patrones de frecuencia de solicitudes, y un patrón de acceso legítimo pero frecuente a una ruta puede parecer idéntico a un ataque automatizado desde el punto de vista de la regla.
SOLUCIÓNAgregue una condición de coincidencia exacta para esa ruta específica en la regla CC para que solo proteja lo que necesita, y agregue la IP de origen conocida como buena a la lista blanca de IP de origen CC en lugar de relajar el umbral de tasa de la regla para todo el sitio.
SÍNTOMAUna URL que debería estar en lista blanca sigue siendo bloqueada, aunque claramente aparece en la lista blanca — y otra URL más corta que comparte el mismo prefijo no se bloquea en absoluto.
CAUSALa coincidencia se ejecuta de arriba hacia abajo en la lista blanca, y la primera entrada coincidente gana. Cuando una URL en lista blanca es un prefijo de otra, o está de otro modo contenida en ella, listar la más corta primero hace que intercepte tráfico destinado a la entrada más larga y específica debajo de ella.
SOLUCIÓNColoque la URL más larga y específica por encima de la más corta que se superpone en el orden de la lista blanca, de modo que la entrada deseada coincida primero.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Un bloqueo explícito muestra al cliente un 403 o una página de bloqueo, y — asumiendo que la acción de la regla sea un «Bloqueo» normal — escribe una entrada en el registro de protección de capa de aplicación que puede filtrar de inmediato. Un bloqueo silencioso usa la acción «Bloquear, sin alerta» o «Descartar, sin alerta»: la solicitud falla exactamente igual desde el lado del cliente, pero no se produce ninguna entrada de registro en absoluto, por lo que a menudo se confunde con un problema de red o de backend.
Desde la entrada de bloqueo en el registro de protección de capa de aplicación, abra los Detalles de alerta y haga clic hasta el ID de regla específico desencadenado. En la página de esa regla, «Agregar URL actual a la lista blanca» agrega esa URL solo para esa regla específica — el grupo de reglas sigue protegiendo todo lo demás exactamente igual que antes.
Ambas están disponibles. Cada regla individual tiene su propia lista blanca de URL, accesible desde la página de esa regla. Por separado, Grupos de reglas > Lista blanca de URL muestra la lista blanca global para todo el grupo de reglas, y permite revisar cada entrada de lista blanca a nivel de regla debajo de él en un solo lugar.
La coincidencia se ejecuta de arriba hacia abajo y se detiene en la primera coincidencia. Cuando una URL en lista blanca está contenida dentro de otra — por ejemplo, una ruta más larga que es un subconjunto de una más corta — liste primero la URL más larga y específica, o nunca tendrá la oportunidad de coincidir antes que la entrada más corta encima de ella.
Antes de tocar cualquier regla, descarte las causas que no tienen nada que ver con la lógica de reglas: la propia ruta de red del PC cliente, un navegador que no admite TLS 1.1/1.2, una discrepancia en la negociación SSL entre el WAF y el servidor de origen, el WAF y el origen simplemente no pudiendo comunicarse, o el WAF funcionando bajo suficiente carga como para retrasar el proxy. Solo una vez descartadas estas causas tiene sentido empezar a filtrar los registros de protección.
Esta nota se basa en los filtros de registro y rutas de menú del WAF Huawei — registro de protección de capa de aplicación, registro de control de tráfico, registro de protección CC, y búsqueda de grupo de reglas — además de los casos de campo que los respaldan. Si su WAF es de otro fabricante, las rutas de menú exactas cambian, pero el orden de diagnóstico subyacente — descartar primero las causas de red y TLS, luego verificar si el registro siquiera estaba configurado para mostrar el bloqueo — se aplica directamente. No cubre en profundidad el ajuste de reglas específico de gestión de bots ni las protecciones a nivel de gateway API.
Cuéntenos si es un 403 duro o una falla silenciosa, junto con la entrada de registro — o el hecho de que no la hay — y le ayudamos a interpretarla.