Configuring rate limiting is a policy decision that happens to be enforced by a proxy. If you start from a round number, you will either block a shared office network or leave a login form open to guessing. SafeLine's own pages are unusually clear about the boundary: they name the control, and they do not hand you a sample rule.
The product overview lists IP-based rate limiting among the core capabilities, next to web-attack defenses, bot defense, HTML and JavaScript encryption, and a web access control list (https://docs.waf.chaitin.com/en/home). The feature note says rate limiting defends web apps against DoS attacks, bruteforce attempts, traffic surges, and other abuse by throttling traffic that exceeds defined limits. Read that as a contract. You define the limits. The WAF throttles what exceeds them. The overview, the install guide, and the application guide do not publish default thresholds, rule-field names, or a shell command that creates a limit (https://docs.waf.chaitin.com/en/GetStarted/Deploy, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). This checklist is how to configure the control without pretending those missing details exist.
Confirm the reverse proxy before you throttle anyone
A rate limit can only count requests that reach the WAF. SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet, and it sits as a reverse proxy so clients pass through it before they reach the server (https://docs.waf.chaitin.com/en/home). The application guide describes the same design in implementation terms: SafeLine is developed based on nginx, receives traffic for the original site, removes malicious traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
The documented setup is in the Web Admin Console, not in a rate-limit API. On the Applications page, use Add Application. Enter the original domain, hostname, or IP. Set the port SafeLine will listen on, such as 80 or 443, and check SSL for HTTPS apps. Set the upstream to the real address that should receive cleaned traffic. After that, resolve the domain to the SafeLine server. Until DNS points there, clients can still bypass the proxy, and any later limit is optional for attackers who know the origin.
Prove the path with two checks that the docs actually support. First, load the site through the proxied domain and confirm the upstream responds. Second, try a harmless attack-shaped request of the kind the application guide lists, such as a SQL injection style query, an XSS-style query, a path traversal query, a code injection query, or an XXE-style query, with your own domain in place of the example host. A blocking page means the proxy inspected the request. The console attack list, opened from detail, is where you confirm the event. Neither check proves a rate limit is on. They only prove you are about to configure throttling on the path users actually use.
The install guide is the other half of whether you can even reach the console. It expects Linux, Docker, and Docker Compose, and it opens the console at https://<safeline-ip>:9443/ after startup (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That page is about bringing the instance up. It is not a rate-limit reference, so do not search it for a hidden throttle flag.
Treat the documented identity as the whole identity
The capability is IP-based. Configuration starts by accepting that limit, not by wishing for a user-based quota the supplied pages never describe. An address limit groups every request that arrives from the same IP. It will merge coworkers behind one office firewall. It will split an attacker who rotates addresses. If your abuse problem is one account across many IPs, or one IP across many accounts, IP throttling is only a partial answer. Say that in the change ticket so nobody later treats a quiet chart as proof that credential stuffing stopped.
Write the policy in plain language before you touch a number. Decide which path is expensive enough to protect first. Login, password reset, and any route that sends mail or SMS usually come before the homepage. Decide which shared addresses must survive a normal morning. A support team, a campus NAT, or a partner integration can look like a surge. Then name the failure mode you are buying down. Bruteforce wants a low ceiling on a small form. A traffic surge on a content page wants a higher ceiling. A DoS flood wants the origin kept alive even if some clients wait. The overview names all three. One number rarely serves all three equally well.
SafeLine also documents payload defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, path traversal, and related attacks (https://docs.waf.chaitin.com/en/home). Keep those rules in the design, but do not count them as rate limiting. A patient scanner can stay under a loose IP ceiling and still send exploit strings. A legitimate monitoring job can send clean requests fast enough to hurt a small upstream. Volume and malice are different axes.
Choose the number from your origin, then watch the first peak
Because the docs say the product throttles traffic that exceeds defined limits, the missing input is the definition. Take it from the origin's capacity, measured by you, not from a blog example.
Time the sensitive path under a normal peak. Note the request rate at which latency or errors become unacceptable. Then note the busiest legitimate IP in that same window, especially if it is a shared network. The ceiling should sit above that legitimate burst and below the rate at which one address can consume the origin by itself. If you cannot measure either number, you are not ready to turn the control on. Waiting is better than publishing a guess that blocks customers.
If the console you are running lets you attach a limit to one application or one path, start with the weakest critical route and leave everything else alone. If it exposes only a broader IP limit, document that constraint and pick the number required by the weakest critical route. Do not assume per-user keys, geographic buckets, or header-based quotas. Those shapes are not in the supplied sources.
Change a single limit, record the old value, and compare throttle events with access logs through the next real peak. Success is specific: guessing and floods slow down, and the shared NAT you wrote down still completes login. If good traffic is throttled, raise the limit or narrow the scope you can actually configure. If a single client can still stall the origin, the limit is too high or it is not on the path you tested.
Pair volume controls with the other documented challenges
Rate limiting is the volume tool. The same overview documents neighboring tools that answer other questions, and mixing them up is how configurations get noisy.
Captcha challenge is described as a bot control: human users are allowed, crawlers and bots are blocked. Authentication challenge asks visitors for a password or blocks them. Dynamic protection encrypts HTML and JavaScript on each visit. Those are useful beside an IP limit when the problem is automation or casual replay, not raw request rate. They are not hidden rate-limit modes, and the pages do not say they share counters with IP throttling.
A sensible order is proxy, attack-inspection check, then rate limit, then an optional challenge on the route that attracts bots. Roll back the last change if the next peak looks wrong. Also close the bypass on the origin itself by allowing only the WAF host to connect. That origin restriction is your firewall or security group, not a SafeLine feature listed in these guides. Without it, the documented reverse-proxy model is advice rather than the only door.
Review the policy when the application changes. A new login endpoint, a marketing spike, or a partner that crawls from one address can invalidate yesterday's ceiling. The WAF will keep enforcing the old definition until you change it.
What does SafeLine document about configuring rate limiting?
It documents IP-based rate limiting that throttles traffic above limits you define, aimed at DoS attacks, bruteforce attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). The supplied install and application pages do not list rate-limit fields, defaults, or commands. Configure only the limit control you can see in your console, after the app is proxied.
Does a block page mean my rate limit works?
No. The application guide's block page and attack-list detail show that SafeLine inspected a malicious-looking request and blocked it (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That verifies the reverse proxy. A rate limit still needs its own test: traffic from one IP above the limit you defined should be throttled, and traffic below it should pass.
Can I copy a threshold from somewhere else?
You should not. Nothing in the supplied official pages gives a recommended request rate. A limit that fits a static blog can lock out a shared office on a login form. Measure the origin and the busiest legitimate IP, then set the ceiling between those two facts.
How is rate limiting different from captcha or an auth challenge?
Rate limiting throttles volume that exceeds a defined limit. Captcha challenge is documented as a human-versus-bot check. Authentication challenge requires a password. Dynamic protection encrypts page code per visit (https://docs.waf.chaitin.com/en/home). Use the one that matches the failure you are seeing, and do not expect one of them to enforce another's job.
What if legitimate users share a single public IP?
That is the main design limit of an IP-based control. Count that address as one client, measure its real peak, and set the ceiling above that peak. If the abuse you care about is automated rather than merely fast, consider the documented captcha or authentication challenge as a separate control instead of crushing the shared address.
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.
