How to Configure SafeLine WAF as a Reverse Proxy

SafeLine is a self-hosted WAF that works as a reverse proxy by design: it terminates your public traffic, inspects every request, and forwards only clean traffic to your real web server. This guide walks through configuring that proxy flow so your existing apps stay exactly where they are.

How the traffic flows

Client → SafeLine (listens :80 / :443) → upstream origin server (your app)

SafeLine sits in front. Your web server (Nginx, Apache, a Docker app, whatever) becomes the upstream — the server SafeLine forwards to. The app never sees unfiltered traffic, and you don't have to change your app's code.

Step 1 — Install SafeLine

Run the one-line installer on a host that can reach your upstream server:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

It pulls the container, starts the management console, and is happy on a small box (1 CPU, 1 GB RAM, 5 GB disk minimum).

Step 2 — Open the console and add a site

Open https://<safeline-ip>:9443 and go to the protected-sites section. Add a site with three pieces of information:

• Upstream server — where your real app listens, e.g. http://127.0.0.1:8080 (if it runs on the same host) or http://192.168.1.20:80 (if it's on another machine).
• Domain — the hostname clients use, e.g. app.example.com.
• Port — the port SafeLine should listen on publicly (usually 80 for HTTP, 443 if you attach a certificate).

SafeLine now knows: "when traffic arrives for app.example.com on port 80, inspect it and forward to http://127.0.0.1:8080."

Step 3 — Point traffic at SafeLine

Two common ways:

• DNS: point app.example.com to the SafeLine host's IP instead of the origin's IP.
• Port / firewall: if SafeLine is on the same host, stop your web server from binding the public port and let SafeLine take it, with the web server moved to a localhost port (the upstream above).

Either way, new requests now pass through SafeLine first.

Step 4 — Verify and tune

The dashboard shows real-time request logs: allowed, blocked, and challenged. SafeLine's semantic-analysis engine blocks SQL injection, XSS, and automated abuse without signature tuning. If a specific path needs custom handling (a legacy API that trips a false positive), you can add a whitelist rule for that route.

Why this mode is convenient

• Your app stays unchanged — SafeLine is purely in the network path.
• One SafeLine instance can proxy multiple upstreams (the free Community Edition covers 10 apps).
• You get a single inspection point and a single dashboard for everything behind it.

FAQ

Does SafeLine replace my Nginx?

Not necessarily. Nginx can stay as the upstream; SafeLine just inspects traffic before it. Many run Nginx → SafeLine → app, or SafeLine → Nginx → app.

What about HTTPS?

You can terminate TLS at SafeLine and forward plain HTTP to the upstream, or forward HTTPS through to the upstream untouched.

Is there a request limit on the free tier?

The Community Edition handles up to 800 QPS across 10 protected apps at no cost.

Can I run more than one upstream per SafeLine?

Yes — each protected site maps its own domain to its own upstream.

---

That's it — your WAF is now running in front of your apps as a reverse proxy.

• ⭐ SafeLine WAF on GitHub — give it a star if you find it useful
• 🔗 Official Docs — installation guide, configuration, and API reference
• 🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en