People who search for how to whitelist an IP in SafeLine WAF usually expect a short console path. The pages used for this article do not document that path. They do not list an allow field, a match expression, or a command that exempts one address from inspection. They do document enough to make a careful decision. SafeLine is a self-hosted web application firewall. It works as a reverse proxy. Its core capabilities include attack defense, proactive bot defense, HTML and JavaScript encryption, IP-based rate limiting, and a Web Access Control List (https://docs.waf.chaitin.com/en/home). Until a cited page shows an IP allow action, the sound response is a checklist, not a guessed bypass.
SafeLine filters and monitors HTTP traffic between a web application and the Internet. Placed in front of an app, it receives client traffic first, blocks what its policies treat as malicious, and forwards traffic it treats as safe to the origin (https://docs.waf.chaitin.com/en/home). That is the opposite of a client-side proxy that hides who is browsing. An address someone hopes to trust still speaks HTTP or HTTPS. Calling it trusted does not move it behind the origin, and it does not make the request harmless. Any exception is a choice to weaken a control on the only hop these pages describe.
Write the request in one sentence before anyone edits policy. Ask whether the caller wants a false-positive review, a higher rate-limit ceiling, or a full inspection skip. Those are different controls. The home page lists defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse, among others. Rate limiting throttles traffic that exceeds defined limits and is described as a defense against denial-of-service attempts, brute force, traffic surges, and other abuse. A CAPTCHA challenge is aimed at bot attacks, while human visitors are allowed through. When authentication challenge is turned on, visitors must enter the password or they are blocked. When dynamic protection is turned on, HTML and JavaScript are encrypted on each visit (https://docs.waf.chaitin.com/en/home). An address that tripped one control is not automatically a candidate to skip the others. IP-based rate limiting is named beside Web Access Control List. These pages never say that either item is an IP whitelist, and they never show how to edit either one.
Confirm that the application is actually on SafeLine. In the Web Admin Console, an application is added with a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps use the SSL option. The domain must then resolve to the server where SafeLine runs, and clients should reach the site through that name (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If DNS still points at the origin, a policy note on the WAF changes nothing for that client, and the origin stays directly reachable. The deploy guide shows the console on the management port after installation, with 9443 as the documented example (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That is where applications and the attack list are reviewed. In these documents, it is not a whitelist screen.
Read the event that prompted the request. The application guide says a blocked attack shows a blocking page, and that operators check the attack list and open detail for the specific hit (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Compare that detail with the payload the caller claims to have sent. The same page gives sample probes for SQL injection, XSS, path traversal, code injection, and XXE, and says those should be blocked on a protected site. If the complained-about URL looks like one of those samples, allowing the source would hide an attack. A normal page load only shows that SafeLine forwarded something it considered safe. It does not prove that inspection is still active for everyone else.
Use this gate, and keep the notes with the change request:
- Record one source address and show that it is stable. An office NAT, a cloud egress, or a scanner pool is shared by many clients.
- Record the application domain, listen port, SSL choice, and upstream so the note cannot be applied to the wrong site.
- Attach the attack-list detail, not a generic timeout or a browser error page.
- Name the control in the way: attack defense, rate limiting, CAPTCHA, authentication challenge, or dynamic protection.
- Name an owner and an expiry. A permanent skip is a standing hole.
- Plan the revoke step and a retest from an address that must remain inspected.
If any line is missing, do not change policy. Ask the caller to use the protected domain, reproduce the request once, and send the detail view. That is slower than typing an address into an imagined allow box, and it is the only workflow these sources support. Do not treat a rate-limit complaint as permission to disable attack defense, and do not treat a shared egress address as a single trusted user.
After any access-control edit made outside these pages, prove the site still fails closed. From a source that should not be exempt, request one documented sample, such as the SQL injection or path traversal probe, against your own protected domain. You should see the blocking page, and a new row should appear in the attack list with detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If that check fails, revert before looking for a narrower exception. Then load an ordinary page and confirm the upstream still answers. Keep the exception note short enough that another operator can remove it without guessing why it was added.
The home page also points operators to community discussion, including a Discord FAQ channel, plus GitHub issues (https://docs.waf.chaitin.com/en/home). A chat reply is not a configuration reference. If a later document describes an IP allow action, follow that page rather than this checklist. Until then, identify the hop, read the detail, map the complaint to one named control, and refuse a blind whitelist.
No. The home page, the deploy guide, and the application guide do not show a whitelist field, command, or match rule. They name Web Access Control List and IP-based rate limiting without editing steps (https://docs.waf.chaitin.com/en/home).
Is Web Access Control List the same as an IP allowlist?
Not from these pages. It is listed as a core capability next to attack defense, proactive bot defense, HTML and JavaScript encryption, and IP-based rate limiting. No allow action, scope, or address format is specified.
Should a scanner or office NAT address skip inspection?
Not by default. One address can represent many users, and the documented attack samples are blocked on purpose. Consider a narrow, time-limited review only after one stable source matches one false positive in the detail view.
How do I confirm traffic passes through SafeLine?
Review the application entry: domain, listen port, SSL if required, and upstream. Resolve that domain to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If the origin address is still published directly, the WAF is not on the client path.
What should I retest after an access-control change?
From a source that must stay inspected, send a documented probe such as a SQL injection or path traversal sample to your protected domain. Expect the blocking page and a new attack-list detail. Then request a normal page so you know safe traffic still reaches the upstream.
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.