Send the check to the Filter itself, before DNS or a traffic copy is changed:
curl -i http://%WAF SERVER%/mikiri-waf-test
Filter answers 403 /var/log/mikiri-waf/filter/filter.log contains CRL ID 1 in the PATH zone. The same check is described in Primary configuration.
If the answer is not 403, go through the causes below in order.
Filter analyzes a request only when Nginx passes that request to the application. A return 301, return 403, or another answer produced by Nginx itself is not analyzed.
Open the virtual host that received the request. The test URL must fall into a location that is proxied, not into a location that answers by itself.
While the host is listed in waf_host_dm, the Filter records the event and does not block. Remove the host from that option when the check is meant to prove blocking. Leaving the host there keeps the Filter in monitoring. The cutover sequence is in Inline protection.
A request processing rule with wl set to true for this host and for the PATH zone suppresses the block. Review the rules in Request processing rules. A host listed in waf_host_wl is not blocked either.
waf_product_key and waf_api_url in /etc/nginx/mikiri-waf/filter/global/waf.conf must point at a license that verifies and at a reachable API. After a change, restart Nginx and mikiri-waf-mla.
Then read:
/var/log/mikiri-waf/filter/filter.log
/var/log/mikiri-waf/mla/mla.log
/var/log/mikiri-waf/api/*.log
A line for CRL ID 1 with no 403 means the request was seen and then excluded or left in detection mode. No line at all means the request did not enter the Filter.