Searching for how to filter WAF allowlist and denylist logs by rule ID usually starts with a practical problem: an expected request is missing, or a policy change appears to have no effect. Before narrowing a search to a rule identifier, verify that the request actually reaches the WAF.
The supplied SafeLine documentation explains application configuration, an attack list, and a detail view. It does not document a rule ID filter, separate allowlist and denylist log views, or the fields available in those records. This guide therefore uses a documented troubleshooting path: correct a domain that still points directly to the origin, then confirm protection through the blocking page and attack details.
The concrete misconfiguration: DNS still points to the origin
Consider an illustrative deployment for an application at portal.example.com. An administrator adds the application to SafeLine but leaves its DNS record pointing to the original application server. The administrator then sends a test request and looks for evidence that a particular policy handled it.
The configuration mistake is the DNS destination. SafeLine operates as an HTTP/HTTPS reverse proxy: it receives application traffic, filters it, and forwards safe traffic to the upstream application. Its application setup instructions explicitly say to resolve the configured domain to the IP address of the server running SafeLine. A client that instead connects directly to the origin bypasses that intended path. Source: Protecting an application
In this scenario, changing a log filter cannot repair the traffic path. Missing results also cannot establish that an allowlist matched, a denylist failed, or a particular rule was disabled.
Establish a baseline before changing anything
Record the hostname, request path, approximate request time, and destination IP observed by the test client. Keep this evidence with the troubleshooting notes so that the before and after requests can be compared.
Next, inspect the application's configuration. SafeLine documents three relevant inputs: Domain identifies the application hostname or address, Port identifies the port SafeLine listens on, and Upstream identifies the real application address to which traffic is forwarded. For HTTPS applications, the instructions also specify selecting the SSL option. Source: Application configuration
Compare the client's resolved address with the intended SafeLine server address. If it still resolves to the origin, you have a concrete explanation to investigate before making policy changes. Confirm the result from the same client that will perform the verification request; a DNS change alone is weaker evidence than observing the corrected destination.
Correct the destination and verify the result
Update the domain's DNS destination to the SafeLine server IP, following the documented application setup. Preserve the intended upstream address in the application configuration so that forwarded requests can reach the application. Source: Application setup
Once the test client resolves the hostname to the intended destination, use an application you own and are authorized to test. The official guide provides sample attack requests, including SQL injection and path traversal examples, and instructs readers to substitute their protected website domain. It identifies the resulting blocking page as evidence that SafeLine defended against the test attack. Source: Try to attack your application
The confirmation should include two observations:
- The controlled test displays SafeLine's blocking page.
- The corresponding attack appears in the web console's attack list, where clicking "detail" opens the specific attack information.
Both the attack list and the "detail" action are documented in the official application guide. Source: Attack inspection
Match the entry to your controlled test using whatever identifying information the actual detail screen exposes. Do not assume that it contains a rule ID. Save the observed screen and test notes as evidence of the corrected traffic path. This confirms the documented attack test, but it does not independently prove an allowlist or denylist decision.
Decide whether rule ID filtering is the next step
After establishing that the request reaches SafeLine, inspect the filtering controls and record fields available in your deployed version. If you need a rule ID workflow, obtain documentation that explicitly describes that identifier and its relationship to policy decisions. The supplied sources do not establish those capabilities, so there is no supported filter expression, API call, or command to provide here.
Does the supplied documentation explain filtering allowlist and denylist logs by rule ID?
No. It documents viewing an attack list and opening attack details. It does not describe a rule ID search control or separate allowlist and denylist log filtering. Source: Attack inspection
Why check DNS before investigating policy rules?
The documented setup requires the application domain to resolve to the SafeLine server. If your client still connects directly to the origin, its request does not follow that configured reverse proxy path. Source: Application setup
Which screen confirms this fix?
For the official controlled attack test, use the blocking page together with the corresponding attack list entry and its detail view. These observations support the conclusion that the test reached protection after the routing correction. Source: Attack verification
Does an absent attack entry prove that a request was allowed?
No. An empty search result alone does not establish the request's route or policy outcome. First verify the destination, reproduce a controlled test, and inspect the documented attack view before drawing conclusions about a specific rule.
SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.