A CDN and a WAF can sit on the same request path, but only one of those roles is described in the SafeLine guides supplied for this article. SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic between an application and the Internet, and it is meant to stand in front of the application as a reverse proxy (https://docs.waf.chaitin.com/en/home). The application guide narrows that further: SafeLine is an nginx-based reverse proxy that receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Nothing on the home page, the deploy page, or the application page documents Cloudflare, a generic CDN origin mode, a trusted proxy list, or a client-IP header. If the search is how to put a WAF behind Cloudflare or any CDN, the accurate answer from these sources is a placement checklist, not a switch to enable.
The documented visitor path is short. In Applications, you add an application and enter the domain, hostname, or IP; the port SafeLine will listen on, such as 80 or 443; the SSL option when the app is HTTPS; and the upstream, which the guide calls the real address of the original app. After those fields are saved, the guide tells you to resolve that domain to the IP address of the server where SafeLine is located, then access the protected application through the domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That sentence is the whole DNS design the product states. A CDN owns the public name instead. Clients resolve to the CDN, and the CDN fetches an origin you chose in the CDN. Those are different resolution targets. You cannot satisfy both resolve the domain to the SafeLine server and resolve the domain to the CDN for the same name at the same time. One of them is outside the guide.
That conflict is the decision, not a missing checkbox.
Write the three addresses before you change records. Address one is the public name visitors type. Address two is the SafeLine listen address and port from Add Application. Address three is the upstream SafeLine will forward to. Protection only matches the guide when address one resolves to address two, and address two forwards to address three. If a CDN must be address one, then address two is no longer the documented public target. Label that design undocumented. Do not rename it to a SafeLine CDN feature.
Keep the upstream pointed at the application. The upstream is not the previous origin name, and it is not the CDN. If the CDN origin is SafeLine and the SafeLine upstream is the CDN, traffic has nowhere stable to land. The guide's forwarding story is one direction: SafeLine receives, cleans, and forwards to the original app (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Draw that arrow before you draw a CDN arrow.
Do not confuse the console with the site. The deploy guide tells you to open the console on the SafeLine server IP at port 9443, and MGT_PORT is the console port setting (https://docs.waf.chaitin.com/en/GetStarted/Deploy). On the same page, MGT_PROXY is the number of console proxy layers. It should only be used when configuring the proxy for the console. The default is 0, and no proxy is configured. It does not say it trusts a CDN, rewrites client addresses, or publishes an application. Leave it at 0 unless you are deliberately proxying the console and you understand you are changing console access, not site protection. Do not point a CDN origin at port 9443 in order to protect the website. That port is the management UI in the install flow, not the application listener you set to 80 or 443.
Ask what SafeLine can see, then stop where the docs stop. Core capabilities include defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). The same introduction describes blocking common web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal; throttling traffic that exceeds defined limits in order to defend against DoS attacks, bruteforce attempts, traffic surges, and other abuse; CAPTCHA challenges; an authentication challenge that asks visitors for a password; and dynamic protection that encrypts HTML and JS on each visit. IP-based rate limiting is explicit. If the CDN connects to SafeLine from the CDN address rather than from each visitor, SafeLine may see only that shared address. These guides never say SafeLine reads a forwarded client header, so you cannot claim that rate limits, access lists, or bot controls still distinguish visitors after that hop. If per-visitor control is the reason you deployed the WAF, the documented design is the direct path, where the domain resolves to SafeLine.
Prove the block in the console, not on a provider status page. The application guide's own check is to request test cases for SQL injection, XSS, path traversal, code injection, and XXE against your protected domain, expect the blocking page, and then open the attack list and its detail view (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Run that check while the domain resolves to the SafeLine server. If you later place a CDN in front, repeat a normal request and one of those checks, and compare the console. A new attack detail supports the claim that SafeLine received the request. No new detail means the CDN result is not evidence of SafeLine inspection. If the CDN serves a cached response, the request may never reach SafeLine, and these guides do not list cache-bypass controls.
Match the host to the deploy guide before you argue about edges. The minimums are Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, one CPU core, 1 GB of memory, 5 GB of disk, and SSSE3 on the CPU (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM server needs a Pro license; the Personal Edition is not supported on ARM. A CDN in front does not change those constraints, and the install page does not list provider-specific packages.
Use the home-page comparison table only as a warning. It includes a CloudFlare column among detection figures (https://docs.waf.chaitin.com/en/home). A column name is not an origin tutorial, a compatibility statement, or permission to copy provider settings into SafeLine. Placement still comes from the application guide's domain, port, upstream, and DNS instructions.
Order the work so rollback is obvious. Bring the direct path up first: console login, application fields, domain pointed at the SafeLine server, a normal page from the upstream, and a blocked test visible in the attack detail. Freeze that configuration. If a CDN is still required for caching or reach that SafeLine does not claim to provide, change DNS only as a separate, reversible step owned outside SafeLine. Record that the product docs do not cover the hop. Retest direct and proxied access independently. If the console stops explaining the blocks, put the domain back on the SafeLine address. Filling in guessed SSL modes, origin authentication, or real-IP headers will not make those behaviors appear in the current documents.
Does SafeLine document a Cloudflare or generic CDN mode?
No. The cited guides describe a reverse proxy and tell you to resolve the application domain to the SafeLine server. They do not document a CDN front end.
Which name has to point at SafeLine?
The domain, hostname, or IP you enter in Add Application. The application guide says to resolve that domain to the SafeLine server IP and then use it to reach the protected app.
Can MGT_PROXY put a website behind a CDN?
No. MGT_PROXY is the console proxy layer count. It defaults to 0 and is only for proxying the console, not for application traffic or a CDN origin.
What becomes unproven if every client shares one CDN address?
The docs list IP-based rate limiting and a web access control list, but they do not describe restoring a visitor address from a CDN header. Treat per-visitor controls as unproven in that layout.
How do I show that SafeLine blocked the request rather than the CDN?
Resolve your own application domain to SafeLine, use the guide's attack checks, and confirm the blocking page plus an attack detail in the console. A result that never creates that detail is not SafeLine evidence.
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.
