A CDN and a self-hosted web application firewall answer different placement questions. Cloudflare, or any other content delivery network, usually becomes the public name that visitors resolve. SafeLine, as documented, is a reverse proxy that is supposed to receive the application traffic before the origin does. The supplied product pages never describe a Cloudflare connector, a generic CDN origin mode, header restoration, cache bypass, or a shared certificate workflow. This article is a decision checklist for that gap. It does not turn silence in the docs into a setup procedure.
Start with the traffic path the product actually documents. The home page defines a WAF as a filter and monitor for HTTP traffic between a web application and the Internet, and it says deploying a WAF in front of an application places a shield between the application and the Internet. SafeLine is described as a reverse proxy: clients pass through it before they reach the server. It filters, monitors, and blocks malicious HTTP/S traffic and is intended to prevent unauthorized data from leaving the app, using policies that separate malicious traffic from safe traffic. The listed core capabilities are defenses for web attacks, proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list names protection against attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, plus rate limiting for DoS attacks, brute-force attempts, traffic surges, and other abuse. CAPTCHA, an authentication challenge that asks visitors for a password, and dynamic protection that encrypts HTML and JS on each visit are also documented. Those controls apply to traffic SafeLine proxies. They are not documented as rules pushed into a CDN. Source: https://docs.waf.chaitin.com/en/home
The application guide then fixes the public address. After SafeLine is installed, you add an application with a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps use the SSL option. SafeLine receives traffic for the original site, cleans malicious traffic, and forwards the rest to the upstream. The following instruction is to resolve that domain to the IP of the server where SafeLine runs. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication
That sentence is the conflict. If visitors must resolve the name to a CDN, you are no longer following the documented public path. A CDN-in-front design would require the CDN to connect onward to SafeLine, and SafeLine to connect onward to the application. The pages do not say how to configure that hop, which certificate belongs where, or whether SafeLine will see the visitor address or the CDN address. Treat those as unknown. Do not fill them with settings copied from another product.
Walk the checklist in order.
Confirm the host before you argue about DNS. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and a minimum of 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3. An ARM installation needs a Pro license to work properly, and the Personal Edition is not supported on ARM. LTS is no longer maintained starting from 9.1.0-LTS on 14 August 2025, and the page recommends upgrading. A placement debate does not relax those requirements. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy
Separate the console from the site. MGT_PROXY is the number of proxy layers in front of the management console. It should be used only when configuring a proxy for the console, and the default is 0. The console example port is 9443. Changing MGT_PROXY does not put protected sites behind Cloudflare or any other CDN.
Write the path you can still defend. Domain, listen port, SSL choice, and upstream must match the application dialog. If the public name points at a CDN, label that design custom. The only checks these sources support are reachability checks you can observe yourself: the intermediary can open the SafeLine listen port, SafeLine can open the upstream, and a test request arrives at the proxy rather than stopping at a cache.
List controls that depend on the address SafeLine sees. IP-based rate limiting is a documented capability, described as throttling traffic that exceeds defined limits. The pages do not name a trusted CDN header and do not say SafeLine restores the original client address. If the only connection SafeLine sees comes from an intermediary, IP limits may apply to that intermediary. Attack inspection still requires the request to reach SafeLine. A response served from a cache never enters the documented proxy path, so it is outside the claim that SafeLine cleaned it.
Close the bypass. The documented model forwards cleaned traffic to the upstream you configure. If clients can still reach that upstream directly, the proxy is optional. A CDN in front does not, by itself, remove a public origin.
Retest with the cases already published, not with a new exploit catalog. The application guide gives SQL injection, XSS, path traversal, code injection, and XXE query examples and says to replace the sample host with your domain. Success, as documented, is the blocking page plus an entry in the console attack list, including the detail view. If the request never appears there, do not credit SafeLine for a block that happened somewhere else.
The home page also prints an effect evaluation on 33669 samples for ModSecurity Level 1, CloudFlare Free, SafeLine Balance, and SafeLine Strict. Detection is listed as 69.74%, 10.70%, 71.65%, and 76.17%. False positives are 17.58%, 0.07%, 0.07%, and 0.22%. Accuracy is 82.20%, 98.40%, 99.45%, and 99.38%. That table compares separate evaluations. It is not a test of SafeLine chained behind CloudFlare or any other CDN, and it does not supply placement steps.
The same page says SafeLine is production-ready. Read that as a statement about the documented proxy deployment, not as approval for an undescribed CDN hop. If the documented path is enough, resolve the name to SafeLine and point upstream at the application. If a CDN must remain the public edge, keep the plan limited to what you can verify and leave certificate mapping, cache exceptions, and original visitor identity unmarked until a source actually specifies them.
Does SafeLine document putting sites behind Cloudflare?
No. The home, deploy, and application pages describe a self-hosted reverse-proxy WAF and tell you to resolve the application domain to the SafeLine server. They do not document a Cloudflare or generic CDN integration.
What should resolve to the SafeLine address?
The application guide says to resolve the domain you configured to the IP of the server where SafeLine runs, after you set domain, port, and upstream.
Can MGT_PROXY place the WAF behind a CDN?
No. MGT_PROXY counts proxy layers for the management console only. The deploy guide says to use it only for that console proxy, and the default is 0.
What breaks if a CDN connects to SafeLine?
The docs do not define client-address restoration. IP-based rate limiting and any control tied to the address SafeLine sees may follow the intermediary address. Requests that a cache answers never reach the proxy.
How do I confirm SafeLine inspected a request?
Use the documented SQL injection, XSS, path traversal, code injection, and XXE examples against your own domain. Look for the blocking page and a console attack detail. Absence from the console means you cannot claim the proxy inspected that request.
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.