People looking up how to whitelist an IP in SafeLine WAF usually have a scanner, an office gateway, a partner host, or a health check that keeps meeting a control. The official pages used for this article do not document a dedicated whitelist screen, rule syntax, or command for source addresses. They do document the request path, the controls SafeLine names, and how an application is placed behind the proxy. The useful response is a decision checklist. A missing procedure is not permission to invent a click path.
Read the path before you trust an address
SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet. Deployed in front of the application, it is a reverse proxy: clients pass through it before they reach the server. It filters, monitors, and blocks malicious HTTP and HTTPS traffic. The introduction also says it prevents unauthorized data from leaving the app by applying policies that separate malicious traffic from safe traffic. Those facts are stated at https://docs.waf.chaitin.com/en/home.
The application guide explains the same role in implementation terms. SafeLine is developed based on nginx. It receives traffic for the original website, cleans malicious attack traffic, and forwards safe and reliable traffic to the original application. You protect an app by adding it in the web console with a domain, hostname, or IP address, a listen port such as 80 or 443, and an upstream address, then resolving that domain to the SafeLine server. For HTTPS applications, the guide says to check the SSL option. See https://docs.waf.chaitin.com/en/GetStarted/AddApplication.
That DNS step changes the address question. After the domain points at SafeLine, an origin log can show the proxy rather than the browser, the scanner, or the probe. An exception has to name the hop. An address visible only on the origin is not automatically the client address that SafeLine evaluated. Write that distinction into the ticket before anyone discusses trust.
A named control is not a whitelist procedure
The introduction lists core capabilities that include defenses for web attacks, proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a Web Access Control List. That list is the closest documented reference to address-based policy, and it still is not a procedure. IP-based rate limiting is described as throttling traffic that exceeds defined limits so the application can resist DoS attacks, bruteforce attempts, traffic surges, and other abuse. A throttle does not mean the source is trusted. The Web Access Control List is named, but these pages do not define match fields, actions, or an IP whitelist workflow. Repeating the capability name does not create a supported configuration step.
Nearby features are also easy to misread as an allowlist. A CAPTCHA challenge is documented to allow human users while blocking crawlers and bots. An authentication challenge blocks visitors who do not enter the password. Dynamic protection encrypts HTML and JS code on each visit. Those descriptions are on https://docs.waf.chaitin.com/en/home. A challenge page or a slow client may call for one of those controls. None of the descriptions say that a favorite address must be exempted first.
Checklist for an exception request
Record the owner, the application, the exact address, the reason, and an expiry. A stable address is not an identity. Shared NAT pools, VPN exits, and cloud hosts can present one address for many users or jobs. If the requester cannot name an owner and a date to remove the exception, the request is not ready.
Classify the symptom before choosing a control. A security block, a CAPTCHA challenge, a password challenge, and a rate limit are different outcomes. For a blocked attack, the application guide tells you to use the web console, review the attack list, and open detail. That is the documented inspection path. A browser timeout is not, by itself, evidence of a false positive. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication.
Keep the scope inside what these pages support. They do not describe a per-address bypass that turns attack detection off for one client and leaves it on for everyone else. If the build you run has a screen these pages do not specify, confirm it in documentation for that build before you publish an internal runbook. Until that confirmation exists, do not promise a whitelist integration or a sample rule.
Leave detection in place for every other client. Documented coverage includes 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 abuse, among others. An opening created for one monitor must not become a global disable. The coverage list is from https://docs.waf.chaitin.com/en/home.
Match the ticket to the narrow documented control. Excess volume maps to IP-based rate limiting. Automated clients map to the CAPTCHA challenge. Visitors who should already know the password map to the authentication challenge. Beside that choice, record the application domain, listen port, and upstream. Those are the settings the application guide actually specifies. Changing who you trust does not change where clean traffic is forwarded.
Close the ticket with a rollback and a negative test. The application guide includes sample probes for SQL injection, XSS, path traversal, code injection, and XXE, and it says a blocking page means the attack was defended. Use those probes only on an application you are authorized to test, and only from an address that should still be inspected. Then confirm the trusted client can finish its real task. One successful status code is not that confirmation.
Do not search the install guide for an allow command. That page covers a Linux host, Docker, Docker Compose, the web console, and the resetadmin command that prints the initial administrator account. It does not document IP whitelist syntax. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy. If a console you are logged into later shows an access-control form, verify it against the running build. Bind any rule you create to one application, one reason, and one expiry, and remove it when the ticket closes.
Does SafeLine document how to whitelist an IP?
No. These pages name a Web Access Control List and IP-based rate limiting, but they do not document whitelist fields, sample rules, or commands. Treat that gap as a decision checklist, not as a guessed click path.
Is IP-based rate limiting the same as an allowlist?
No. The documented behavior is throttling traffic that exceeds defined limits. That is a ceiling, not an instruction to skip inspection for a preferred address.
Should a monitoring probe skip attack detection?
Not on the evidence in these pages. SafeLine is documented to clean malicious traffic and forward safe traffic to the upstream application. A probe that must send attack-like payloads needs an owner, a written scope, and an expiry. A detection bypass is not described here.
Where do I confirm that a request was blocked?
Use the web console attack list and open detail, which is the inspection path in the application guide. On an authorized test, a blocking page is the documented sign that the attack was defended.
Why does DNS placement change an IP exception?
The application guide tells you to resolve the protected domain to the SafeLine server. SafeLine then forwards cleaned traffic to the upstream address. Origin logs can show the proxy instead of the client, so the exception has to name which hop it applies to.
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.
- SafeLine website: https://ly.cyberserval.tech/bvK1BAV
- Demo: https://demo.waf.chaitin.com:9443/statistics
- Official docs: https://docs.waf.chaitin.com/en/home
- GitHub: https://github.com/chaitin/SafeLine
- Pro offer: https://cyberserval.tech/landing/lto
Top comments (0)