DEV Community

禾
禾

Posted on

A vs B: Direct WAF Placement vs an Extra Proxy When Investigating Blocked Requests

#waf #security #troubleshooting #deployment

A blocking page gives you a starting point for investigation. The next task is to find the corresponding event and understand what happened before changing your configuration.

If you are looking for how to check WAF attack details after a blocking page appears, the supplied SafeLine documentation gives a short workflow: open the SafeLine web console, check the attack list, and click "detail" to view the specific attack details. The guide describes a blocking page appearing after its example attack requests as evidence that SafeLine defended against those requests. Official application configuration guide

That workflow becomes easier to interpret when you understand your traffic path. Compare two architecture choices: placing SafeLine directly in front of the application, or retaining another proxy before SafeLine.

Choice A: Browser to SafeLine to application

The documented setup uses SafeLine as an HTTP/HTTPS reverse proxy. It receives traffic for the website, filters malicious traffic, and forwards safe traffic to the original application. The application configuration includes a domain, a listening port, and an upstream address. The guide then instructs you to resolve the domain to the IP address of the server running SafeLine. Official application configuration guide

For an investigation, this creates a relatively short path to verify. Check that the hostname you visited matches the configured application domain, that the browser used the intended port and protocol, and that the configured upstream identifies the intended application.

Next, open the attack list and select "detail" for the relevant event. Record the time of your browser attempt and the URL you requested so you have context while reviewing the console. These are investigation notes you collect yourself; the supplied documentation does not enumerate the fields displayed in the attack detail view.

The practical advantage of this placement is fewer routing decisions to trace. Its operational tradeoff is that your team must plan the domain routing change described in the setup guide.

Choice B: Browser to another proxy to SafeLine to application

An existing architecture might already include an edge proxy or another intermediary. Keeping that layer introduces another place to investigate when a blocking page appears.

Treat this as a general architecture comparison. The supplied documents establish SafeLine's reverse proxy role, but do not provide a configuration recipe for every possible proxy chain. They do not establish how a particular external proxy integrates with SafeLine or how client identity would be represented in that arrangement. Official SafeLine overview

Start by drawing the actual request path. Identify which component receives the public hostname, where it forwards requests, and whether that destination reaches the intended SafeLine application. Then review the SafeLine attack list and open "detail" as documented.

If you cannot locate a corresponding event, investigate the route and the other intermediary's own records before attributing the response to SafeLine. A browser screenshot alone does not establish which component generated a response in a chain containing multiple enforcement points.

The benefit of retaining an existing proxy is continuity with your current routing design. The cost is a broader troubleshooting scope: your team must distinguish the behavior of each layer. Choose this arrangement only with a clear understanding of the surrounding infrastructure, rather than assuming the basic setup guide documents the entire chain.

Use the same evidence checklist for both choices

Before changing a security setting, collect:

  • The approximate request time, including the time zone.
  • The requested hostname, path, method, and relevant input, with secrets removed from shared notes.
  • The browser's visible response and any displayed message.
  • The corresponding SafeLine attack entry, if located, and the information available through "detail".
  • The intended route from the public endpoint to the application.

Separate two questions: did the request follow the expected path, and was blocking that request appropriate? Answering the first prevents you from adjusting the wrong component. Answering the second requires reviewing the request's purpose and the available event evidence.

Where do I open the attack details?

In the SafeLine web console, check the attack list and click "detail" for the attack you want to inspect. Those are the navigation instructions explicitly provided in the official guide. Official application configuration guide

Does a blocking page mean the request was malicious?

Investigate before drawing that conclusion. The documentation uses blocking pages to demonstrate defense against its example attack requests. That demonstration does not establish the intent or legitimacy of every request you might encounter.

Which placement makes troubleshooting simpler?

A direct path generally involves fewer components to trace. An additional proxy can fit an existing architecture, but you need evidence from each relevant layer to identify where a response originated.

Should I change protection settings immediately?

First locate the event, inspect the available details, and verify the request path. The supplied sources do not document a specific exception workflow, so this guide does not prescribe an allow rule or promise a particular tuning control. Make any subsequent configuration decision against your actual findings and the applicable documentation.

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)