DEV Community

禾
禾

Posted on

Direct Console vs Counted Proxy: How to Place the WAF Management Console

#waf #proxy #console #deploy

Operators often ask how to put a WAF management console behind a proxy, then apply the wrong control. SafeLine already is a reverse proxy for the sites it protects. The management console is a different listener. The install documentation gives you two configuration choices for that listener, and they should not be blended: leave the console with no proxy configured, or set the console proxy layer count to match a proxy you are actually placing in front of it.

Compare the two placements before you edit anything

Choice A is direct console access. The manual deploy guide ships MGT_PROXY at 0 and explains that the value is the number of console proxy layers. It should only be used when configuring the proxy for the console. By default it is 0, and no proxy is configured. The same guide tells you to open the web console at https://:9443/. MGT_PORT is the web console port, and 9443 is the value in the sample environment file. In Choice A, an administrator browser connects to that console port on the SafeLine host. You do not claim that another proxy sits in front of it. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Choice B is the counted-layer placement. You still use the same variable, but you set it to the number of proxy layers on the console path. That is the entire contract these pages state. They do not include a proxy server config, a path prefix, a header allowlist, or a certificate layout. Setting a number does not, by itself, create the proxy. If you cannot point to the layers, Choice B is not a documented integration. Use it only while configuring that console proxy, which is the condition the variable description already sets.

Both choices leave application protection on a separate path. SafeLine is a self-hosted WAF. Deployed in front of a web application, it filters and monitors HTTP traffic and blocks malicious requests before they reach the origin. The product overview describes that role as a reverse-proxy shield, with defenses for web attacks, bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Source: https://docs.waf.chaitin.com/en/home

Adding a site is a console workflow, not a console-placement setting. Log in, open Applications, choose Add Application, and enter the original app domain, the port SafeLine will listen on, and the upstream address. For an HTTPS app, check the SSL option. Then resolve that domain to the SafeLine server so clients reach SafeLine before the origin. SafeLine receives the site traffic, removes malicious requests, and forwards the remaining traffic. Domain, port, and upstream are not MGT_PROXY. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Choice A: no console proxy configured

Direct access is the cleaner choice when administrators can open the console host and port. It matches the install guide browser step, and it matches the explicit statement that 0 means no proxy is configured. You avoid a class of false debugging in which the console is healthy and the failure is an undescribed proxy in the middle.

This placement does not remove the console account step. After docker compose up -d, the documented way to obtain the first administrator account is docker exec safeline-mgt resetadmin. The command prints an initial username and password. Keep that output private. Choice A does not add another login gate, and these pages do not describe one. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Direct access also has a scope limit. It assumes the operator network can reach the SafeLine host on MGT_PORT. The install requirements are Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least one CPU core, 1 GB of memory, and 5 GB of disk. Those requirements say where the product can run. They do not say that every network should publish port 9443. If your security design forbids direct reachability, do not keep MGT_PROXY at 0 while quietly fronting the console. That would make the documented setting false.

Choice B: record real console proxy layers

Use a non-zero setting only for a real console proxy design. Count layers that forward traffic to the management console. Do not count proxies that exist only for a protected website. A site proxy is the WAF reverse-proxy job, configured on the application, not a console layer.

Read the field literally. The number of console proxy layers means a count. One layer and three layers are different values. The guide does not recommend a magic number, and it does not say that any positive value enables a hidden compatibility mode. Because the pages stop there, a responsible Choice B is a checklist, not a guessed integration:

  • You already have a proxy whose relevant job here is reaching the console.
  • You know how many such layers a request crosses before it hits SafeLine.
  • You store that count in MGT_PROXY in the .env file the deploy guide shows.
  • You leave unrelated keys alone, including database passwords, image tags, subnet prefix, and detector tokens.
  • You do not add the console as if it were an origin website on the Applications page.
  • You do not assume a header, rewrite, or certificate behavior that these sources never state.

If any bullet fails, stay on Choice A. An unsupported proxy recipe is worse than a direct console URL you can actually open. The variable supports a layer count. It does not publish the proxy itself.

Decide with the object, not the keyword

Write down which object you are moving. If the object is a public website, you want SafeLine in front of that origin. Follow the application guide, then use the console attack list to review what was blocked. The application guide even supplies sample requests for SQL injection, XSS, path traversal, code injection, and XXE so you can see a block page and then open the attack detail. That verifies protection. It does not move the admin UI. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

If the object is the admin UI, choose A when the published entry remains the SafeLine host and MGT_PORT. Choose B when you are configuring one or more proxies specifically for that console, and set the layer count to that number. Do not use Choice B to mean that you want the console to be harder to find. The variable does not hide the console by itself.

Keep two maps in the runbook. Map one is client, SafeLine, upstream application. Map two is administrator, optional console proxies, management console. MGT_PROXY belongs only on map two. Domain, port, and upstream belong only on map one. Mixing the maps is how a console-placement change gets mistaken for a broken origin or a gap in site protection.

The product overview lists the attack classes the WAF is meant to filter on that application path, including SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, plus rate limiting for traffic that exceeds defined limits. Those controls stay attached to protected applications in either console placement. Source: https://docs.waf.chaitin.com/en/home

Does MGT_PROXY install or start the proxy?

No. The deploy guide calls it the number of console proxy layers and says to use it only when configuring the proxy for the console. Zero means no proxy is configured. These pages do not ship a proxy configuration file. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Is the WAF reverse proxy the same choice as a console proxy?

No. SafeLine reverse-proxy behavior is how a protected application is shielded. You configure that on Applications with a domain, a listen port, and an upstream. MGT_PROXY counts layers in front of the management console. Leaving it at 0 does not disable site protection.

Which URL matches direct console access?

The install guide uses https://:9443/ and sets MGT_PORT to 9443 in the sample environment file. If you change the console port, use that port instead. Direct access also keeps MGT_PROXY at 0, which the guide defines as no proxy configured.

What value should I put in MGT_PROXY?

Use 0 when no console proxy is configured. Otherwise use the number of console proxy layers you are configuring. The sources do not give a sample topology, a maximum, or a per-vendor value. Do not invent one.

How do I log in after either placement?

Run docker exec safeline-mgt resetadmin and store the printed initial username and password. That command is the documented account step for the management service. Neither placement is documented as a replacement for that account.

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.

Top comments (0)