When someone asks how to whitelist an IP in SafeLine, separate the policy question from the missing procedure. The introduction describes SafeLine as a self-hosted web application firewall that filters and monitors HTTP traffic between an application and the Internet. It sits as a reverse proxy, so clients pass through it before they reach the server (https://docs.waf.chaitin.com/en/home). That page lists web-attack defenses, proactive bot defense, HTML and JS code encryption, IP-based rate limiting, and a Web Access Control List. None of the supplied pages shows a whitelist screen, an allow-IP field, or a command that exempts a source address. The sound response is a decision checklist, not an invented click path.
SafeLine receives traffic for the original site, cleans malicious requests, and forwards the remaining traffic upstream. The application guide describes it as an HTTP and HTTPS reverse proxy developed based on nginx (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A familiar address does not prove that every request from it is safe. An office network, vendor, monitor, or build system can still send a bad query string, a broken header, or a sudden burst. An IP exception would weaken the cleaning step if a product documented one. These pages do not document it, so the practical work is to explain the failure with controls that are actually described.
Confirm that the client is reaching SafeLine before you discuss exceptions. In the web admin console, protection starts on the Applications page. Add the application with its domain, listen port, and upstream address. For HTTPS, check the SSL option. Resolve that domain to the server running SafeLine, then reach the site through the protected name (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If DNS still points at the origin, SafeLine never sees the client, and no access change on the firewall can explain the ticket. If a deliberate test produced the blocking page, that page means the attack was defended. Open the attack list and its detail view before anyone proposes an exception.
Record evidence before changing policy. Note the source IP, time, host header, method, path, and what the caller saw: a block page, a challenge, throttling, or a connection failure. Map that note only to behaviors in the supplied documents.
Attack filtering is the first map. Documented defenses include SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor traffic, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). A partner tool can trip those checks with a test parameter even when the owner is not hostile. Review the request content. Do not convert one bad payload into a permanent pass for the whole address.
Volume is the second map. IP-based rate limiting is a named core capability, and the rate limiting feature throttles traffic that exceeds defined limits. Its stated purpose is defense against denial-of-service attempts, brute-force attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). If the caller is a monitor or a batch job, compare its rate with the limit you defined. Reviewing a limit is not the same as allowing every later request from that IP. These pages never say a source address can be removed from rate limiting or from attack detection.
Visitor checks are the third map, and only when they are in use. Captcha challenge is documented so human users can continue while crawlers and bots are blocked. When authentication challenge is turned on, visitors must enter the password or they are blocked. When dynamic protection is turned on, HTML and JS from the web server are dynamically encrypted on each visit (https://docs.waf.chaitin.com/en/home). A non-browser client can fail a challenge without being an attacker. Decide whether that application should keep the challenge enabled. Do not assume the source IP can be carved out of it.
Treat the Web Access Control List as a named capability, not as a finished allowlist design. The introduction lists it, but the supplied pages do not define match fields, actions, or IP semantics (https://docs.waf.chaitin.com/en/home). If the console you are using shows an access-control form, follow only the labels on that screen and record the exact change plus a rollback. If it does not offer a source-IP allow action, stop. Do not copy a rule from another product, and do not guess command flags. An unsupported integration is outside this guide.
Keep install facts out of the access decision. SafeLine expects Linux on x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The deploy guide opens the console on the SafeLine host at port 9443, and docker exec safeline-mgt resetadmin prints the initial administrator username and password (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM install requires a Pro license, and the Personal Edition is not supported on ARM. Those constraints tell you whether the instance can run. They do not create an IP allowlist.
Close the review with one written outcome. Leave inspection unchanged, tune only a documented limit or challenge for that application, or escalate because the requested whitelist is not described. After any change, confirm again that the domain resolves to the SafeLine server and that ordinary requests still reach the upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Store the rollback note with the ticket. Leaving the IP inspected is a valid result when the only proposal is an undocumented pass.
Does this documentation set show how to whitelist an IP?
No. It names a Web Access Control List and IP-based rate limiting, and it explains reverse-proxy protection, but it does not give whitelist steps, fields, or commands (https://docs.waf.chaitin.com/en/home). Until a page you are using documents the control, do not publish a procedure for it.
What should I verify before I touch any access setting?
Verify the application domain, port, SSL choice, and upstream, and verify that DNS points at the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Then match the symptom to attack blocking, rate limiting, captcha, authentication challenge, or dynamic protection. Those are the behaviors the introduction describes (https://docs.waf.chaitin.com/en/home).
Can I treat a known IP as safe because rate limiting is IP-based?
No. IP-based rate limiting is described as throttling traffic that exceeds defined limits, not as an identity allowlist (https://docs.waf.chaitin.com/en/home). A known network can still send injection payloads, floods, or automated calls. These pages do not say attack inspection can be skipped for a trusted address.
How do challenges differ from an IP exception?
Captcha, authentication challenge, and dynamic protection are visitor or content controls, and the last two apply when turned on (https://docs.waf.chaitin.com/en/home). They are not documented as per-IP whitelist switches. If a client fails a challenge, review whether that application should use the challenge. Do not invent a source-address carve-out.
When is the right outcome to leave the IP inspected?
Leave it inspected when the request contains an attack payload, when the client can still reach the origin directly, or when the only proposal is a permanent pass for every path and method. Also leave it inspected when you cannot cite a control from the introduction, the deploy guide (https://docs.waf.chaitin.com/en/GetStarted/Deploy), or the application guide. Missing steps are a reason to stop, not a reason to improvise.
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.