A console login only proves that the management service answered. It does not prove that public clients are being filtered. SafeLine is a self-hosted web application firewall placed in front of a web application so that it can filter and monitor HTTP traffic and block malicious HTTP and HTTPS requests before they reach the app, following policies that separate malicious traffic from safe traffic (https://docs.waf.chaitin.com/en/home). The application guide describes the same idea in proxy terms: SafeLine is developed based on nginx, receives traffic for the original website, cleans malicious attack traffic, and forwards the remaining traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A working test has to show that your hostname is on that path, that a documented attack is blocked, and that the console recorded the same attempt.
Confirm the application path first.
Protection is configured in the web admin console on the Applications page. Choose Add Application, then enter Domain, Port, and Upstream. Domain is the domain name, hostname, or IP of the original app. Port is what SafeLine will listen on, such as 80 or 443, and HTTPS apps need the SSL option checked. Upstream is the real address SafeLine uses to forward traffic (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The guide then tells you to resolve that domain to the IP address of the server where SafeLine is located and to access the protected application through that domain.
Use that sequence as the first half of the test:
- The hostname in your test URL must be the Domain you configured.
- Public DNS for that hostname must point at the SafeLine server, not at the upstream host.
- The port in the test must be the listener you set. If clients use HTTPS, the SSL option has to be enabled or you are testing a different service than production.
- Upstream must be the origin you intend to protect. A successful page load after cutover only shows that forwarding works. It does not show that filtering works.
Keep the admin URL out of this path check. After installation, the web console is opened at https://<safeline-ip>:9443/ (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Reaching that page shows that the management plane is up. It says nothing about whether a visitor to your public site ever touches the proxy.
Send the published samples, then match them to the attack list.
The application guide gives five cases and says to replace the example host with your website domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Run them only against the application you added:
- SQL injection:
/?id=1+and+1=2+union+select+1
- XSS:
/?id=<img+src=x+onerror=alert()>
- Path traversal:
/?id=../../../../etc/passwd
- Code injection:
/?id=phpinfo();system('id')
- XXE:
/?id=<?xml+version="1.0"?><!DOCTYPE+foo+SYSTEM+"">
The documented success signal is the blocking page. After each request, open the SafeLine web console, find the attack list, and click detail. Count the test as passed only when both signals refer to the same attempt: the browser was blocked, and the detail view exists for that request. One signal without the other is incomplete. A normal origin response means the request was not cleaned on that path, so go back to Domain, Port, SSL, Upstream, and DNS before you change anything else.
Do not stretch these five URLs into a claim about every control.
The introduction lists many attack types that a WAF of this kind is typically used to address, including SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abused (https://docs.waf.chaitin.com/en/home). The same page lists core capabilities: defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list adds rate limiting against DoS attacks, bruteforce attempts, traffic surges, and other abuse; CAPTCHA challenges that allow human users and block crawlers and bots; an authentication challenge that blocks visitors who do not enter the password; and dynamic protection that encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Those are product facts, not extra test steps. The only click-by-click attack samples in the supplied application guide are the five URLs above. A pass on those URLs supports the web-attack blocking check. It does not prove that rate limiting, CAPTCHA, authentication challenge, dynamic protection, or an access list is enabled. Mark those items untested unless you have a documented procedure for them.
A sample-set score is a different question from a cutover test. The home documentation publishes an effect evaluation on 33669 samples. In that table, SafeLine Balance is listed at 71.65 percent detection, 0.07 percent false positive, and 99.45 percent accuracy, while SafeLine Strict is listed at 76.17 percent detection, 0.22 percent false positive, and 99.38 percent accuracy (https://docs.waf.chaitin.com/en/home). Use those figures only as published evaluation results. They do not inspect your DNS, your listener, or your upstream. The supplied pages also do not provide a procedure for switching between Balance and Strict, so do not treat the table as a tuning guide.
When you record the result, store the hostname, port, SSL choice, the five URLs you requested, whether each one returned the blocking page, and whether attack-list detail opened for each one. If you compare by requesting the upstream directly, do that from an admin network you control and treat the response as an origin-only observation. Close that direct path to the public Internet afterward. The documented design is that clients pass through the WAF before reaching the server (https://docs.waf.chaitin.com/en/home). A WAF you can bypass is not a WAF you have tested.
Does opening the console mean the WAF is working?
No. The console address https://<safeline-ip>:9443/ is the management page described in the install guide (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Filtering starts only after an application is added and clients reach SafeLine on the configured domain and port (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
Which requests are the documented way to test blocking?
Use the five samples in the application guide, pointed at your own protected domain: SQL injection, XSS, path traversal, code injection, and XXE. The guide treats the blocking page as evidence that the attack was defended, and it tells you to inspect the attack list and open detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
What should I check if the payload is not blocked?
Check the path before you assume a detection miss. The application must use the hostname you requested, listen on that port, have SSL selected for HTTPS, forward to the intended upstream, and have DNS pointed at the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A normal page from the origin means that request did not pass through the cleaning proxy.
Do the sample URLs prove rate limits and bot checks?
No. Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection are documented separately (https://docs.waf.chaitin.com/en/home). The published attack exercise does not include steps for those controls, so a blocked XSS URL is not evidence that they are on.
Can the published accuracy table replace a live test?
No. The 33669-sample evaluation reports SafeLine Balance and SafeLine Strict metrics (https://docs.waf.chaitin.com/en/home). It is not a test of your hostname. Keep the live blocking page and the matching attack-list detail as the cutover evidence.
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.
