Условия и вопрос расследования
Эта процедура отвечает на вопрос «почему правило сработало, но клиент получил ответ» и на обратный случай «почему Count не спас от блокирования». Сначала закрепите конкретный requestId, период, web ACL и защищаемый ресурс. Нужен журнал обработки, а не только счётчик метрики. Сохраните конфигурацию правила и групп на момент запроса: снимок текущего состояния может описывать уже другой режим. В карточке не предлагается менять политику; диагностика выполняется чтением доступных данных.
Как найти совпадение
В копии JSONL ищите action=COUNT внутри nonTerminatingMatchingRules, включая соответствующие массивы вложенных групп. Пример jq выбирает обе формы и оставляет общий action вместе с деталями. Перед применением сверьте формат файла и наличие обёртки доставки. Не ищите только верхнеуровневое action=COUNT: для обычной обработки здесь нужен итоговый завершающий исход. После отбора сузьте результаты до одного ACL и интервала, иначе одинаковый ruleId из другой среды создаст ложную связь.
Пример и допустимый вывод
Синтетический запрос /catalog совпал с DemoObservation. Это совпадение помечено COUNT, а итоговый action=ALLOW и terminatingRuleId=Default_Action. Значит, в данном примере оценка продолжилась и завершилась действием по умолчанию. Запись не подтверждает, что приложение успешно обработало запрос или что пользователь выполнил бизнес-операцию. Для этого нужен ответ обслуживающей системы. Если итоговый action был бы BLOCK, причиной остановки следовало бы считать указанное завершающее правило, сохраняя COUNT как предшествующий контекст.
Правило и группа — разные уровни
Проверьте, изменено ли действие отдельного правила через RuleActionOverrides или в Count превращён только результат целой группы. Во втором случае внутренняя оценка группы могла остановиться на первом завершающем правиле, а наружу вернулся Count. Поэтому нельзя заключать, что все последующие правила внутри группы тоже были проверены. Старое ExcludedRules и нынешний механизм overrides также требуют различать по конфигурации. Официальное описание разделяет эти режимы; в заметке укажите найденный уровень, не объединяя всё словом «тестовый режим».
Следующая проверка
Сравните общий исход с HTTP-наблюдением клиента и журналом приложения. Соберите несколько запросов одного сценария, сохраняя время, ресурс и идентификатор: два соседних запроса могут иметь разные решения. Для оценки ложного срабатывания сравните условия правила с ожидаемыми данными приложения и действовавшими исключениями. Совпадение сигнатуры, деловой ущерб и фактический доступ к данным оформляйте разными выводами. Предложение изменить правило должно рассматриваться отдельно с владельцем; эта инструкция не выполняет переключение Count/Block.
Если COUNT-срабатывание не найдено
Сначала проверьте вложенные группы, период, точный ruleId и редактирование конфигурации. Раннее завершающее правило могло не дать нужному правилу выполниться. Кроме того, фильтр отправки может исключать Count-записи, а доступная выборка не обязана охватывать весь трафик. Сверьте доставку и хранение журнала. При отсутствии данных запишите, какой участок цепочки неизвестен, и не заменяйте его выводом «совпадений не было». Пустой результат представленного jq также может означать другой формат экспорта, а не неисправность WAF. Ошибка чтения файла, отказ в доступе или ошибка разбора JSON не являются пустой выборкой. Для этого шага нужны права чтения выданной копии; при их отсутствии запросите доступную копию у владельца источника, сохранив сообщение об ошибке.