A vs B: Point Your Domain at the WAF IP or Route Through an Edge Layer

When you put SafeLine in front of a web app, the console configuration is only half of the job. The other half is traffic steering: clients must actually reach the WAF before they reach your origin. There are two common ways to do this, and they look identical until something breaks. This post compares both so you can pick the one that fits your setup.

Choice A: Point the domain straight at the WAF IP

SafeLine is a reverse proxy built on nginx. It receives HTTP/HTTPS traffic for the original site, drops malicious requests, and forwards the safe remainder to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In this placement, the public DNS record for the domain resolves directly to the IP of the server where SafeLine runs.

The documented setup flow for this path is: log into the SafeLine console, open Applications, and add an application with the domain, the port SafeLine listens on (80 or 443, with SSL enabled for HTTPS apps), and the upstream address of the real app. After saving, resolve that same domain to the SafeLine server IP. That final DNS step is exactly what the official guide states (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

The advantage is that every request now terminates at the WAF. SafeLine sees the full traffic stream, can enforce rate limiting and access control, and keeps the origin address out of public DNS. The tradeoff is that the WAF server becomes your public edge: its IP is the one exposed in DNS, its certificates handle HTTPS, and its capacity is the first thing a flood hits.

Choice B: Route through an existing edge layer first

Instead of changing DNS to the WAF IP, you leave the domain pointed at an existing front layer such as a CDN, cloud load balancer, or hosting edge, and configure that layer to forward traffic to the SafeLine server IP. SafeLine still sits between that front layer and the origin, but it is one hop behind DNS.

This keeps existing DNS, TLS termination, and CDN caching in place, which reduces the number of things you change during a rollout. The cost is extra indirection: you now have two systems to reason about, and the WAF view of client identity can be masked behind the front layer unless forwarding headers are preserved correctly. SafeLine's role in the chain is still the reverse-proxy behavior described in the official docs; the front layer is simply an additional hop in front of it.

How to choose

Choose A when SafeLine should be the single edge of record, when you can update DNS and move certificates to the WAF, and when you want the simplest possible path. Choose B when you cannot change DNS, when an existing edge already handles certificates or caching, or when you are rolling out protection incrementally behind infrastructure you control. If you choose B, test from outside your network and confirm the WAF actually logs the test requests; a misconfigured front layer can bypass the WAF silently.

Common setup checklist

Confirm the domain added in the console matches the public hostname users type. Use an A record to the SafeLine server IP for the direct path, or the existing front layer forwarding rule for the edge-first path. For HTTPS, enable the SSL option on the SafeLine application and make sure the certificate is served where TLS terminates. After the change, open the console and confirm traffic appears, then try the documented attack samples and expect a block page.

Do I change DNS before or after adding the application?

Add the application first. The console needs the domain, the SafeLine listening port, and the upstream address before it can route correctly. The documentation order is to complete the application settings first, then resolve the domain to the SafeLine server IP (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Which record type do I use to point a domain at the WAF IP?

Use an A record for an IPv4 address, pointing the hostname to the IP of the server where SafeLine is located. The official guide describes resolving the domain to that server IP; it does not depend on a specific DNS provider.

Can I keep a CDN or load balancer in front of SafeLine?

Yes, as long as that layer forwards HTTP/HTTPS traffic to the SafeLine server IP and the SafeLine application upstream points at the real application. This is the edge-first placement described above. The tradeoff is that the WAF sits one hop back, so verify requests are actually logged by SafeLine and preserve client-forwarding headers if you rely on client IP features.

Do I need to expose the origin IP anywhere?

In the direct placement, DNS exposes only the WAF server IP; the origin address stays in the SafeLine application upstream setting, not in public DNS. In the edge-first placement, the front layer also hides the origin from DNS as long as its forwarding target is the WAF IP.

How do I confirm the domain is actually pointing at the WAF?

After the DNS or forwarding change, request the domain and watch the SafeLine console. You can also attempt the documented sample attacks such as SQL injection, XSS, and path traversal, and expect a block page if SafeLine is in the path (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

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.

• SafeLine website: https://ly.cyberserval.tech/bvK1BAV
• Demo: https://demo.waf.chaitin.com:9443/statistics
• Official docs: https://docs.waf.chaitin.com/en/home
• GitHub: https://github.com/chaitin/SafeLine
• Pro offer: https://cyberserval.tech/landing/lto