JXWAF: a WAF that ships a model, a semantic engine and an SSL fingerprint check in one compose file

What the three detection engines actually claim

The product description is a web application firewall built on AI large models that analyses traffic in real time, cleans malicious requests and forwards what is left to the origin server. Three engines do the work, and each covers a different class of traffic.

The AI security model is described as proprietary multi-dimensional sparse attention combined with online distillation, which is meant to transfer a large model's detection ability into a local inference engine so that detection is high-concurrency, low-cost and low-hallucination. Two consequences are claimed: newly disclosed attacks are picked up by the large model and distilled into the local model without anyone writing a rule, and false positives that appear during a model update get auto-whitelisted once distillation finishes. It runs on CPU only, and the README states one 4C8G server can sustain a daily average of 800 million inspected requests when all protection modules are on.

The semantic analysis engine does contextual analysis instead of regular expression matching, covering SQL injection, XSS, command or code execution, deserialization and high-severity N-day exploitation. The third engine analyses SSL behaviour with a fingerprint algorithm plus protocol interaction anomalies, which is aimed at identifying non-browser clients for CC attack and crawler detection.

There is a fourth component, WebTDS real-time analysis, but it only appears in the professional and cloud editions, not the standard one.

One compose file starts five subsystems

The standard edition bundles the WAF node, the console, MySQL, log collection and network banning into a single `docker-compose.yml`. The deployment sequence the README gives is short enough to quote directly:

git clone --depth=1 https://github.com/jx-sec/jxwaf.git
cd jxwaf/Standard/
docker compose up -d

Docker installation precedes it if needed, and the repository also offers a zip archive as an alternative to cloning. Environment requirements are Debian 12.x or Ubuntu 20.04 and later, 4 cores and 8 GB of memory, with Docker present.

The five containers are named and each has a distinct job: `jxwaf_node_standard` is the node that handles traffic and performs real-time attack detection, `jxwaf_admin_server` is the console with the visualisation UI and API, `mysql_db` is MySQL 8.0 holding site configuration and attack logs, `log_send_to_mysql` writes node attack logs into it, and `jxwaf_nft_node` bans attacking IPs at the network layer rather than at the application layer.

After startup you reach the console on port 8000 of the server address and register an account on first use. Four protection modes switch the trade-off between learning and enforcing: model training, which learns without taking action; daily protection, business first; hardened protection, security first; and offline protection, which works with no network access at all.

The performance table tells you what protection costs

Rather than a marketing claim, the README gives a wrk measurement against a real business endpoint at four threads, 1,000 concurrent connections, for 60 seconds. Three configurations are compared.

Pure forwarding reaches 67,849 HTTP QPS and 55,227 HTTPS QPS. With the AI model and semantic engine active, that falls to 36,388 and 31,081. With all protection modules enabled, it falls to 10,574 and 7,739. A single node then handles more than 800 million requests per day.

The gap between the second and third rows is the interesting one, and the README does not attribute it to a specific module. The remaining modules, which include the SSL behaviour analysis, appear to account for roughly a factor of three on top of the model and semantic cost. Anyone sizing a deployment should read the second row as the realistic floor for a protected site rather than the third, and should treat the third as the ceiling of what the box will pass.

The standard edition imposes no limit on processing threads, concurrent connections, number of sites or request volume, so the only way to scale is to raise the server specification.

Detection figures, and who produced the comparison

Two test suites are reported. The first is a side-by-side BlazeHTTP run across WAF products, with three columns for detection rate, false positive rate and accuracy.

CloudFlare's free tier shows a 10.70 percent detection rate. ModSecurity at PARANOIA 1 level shows 69.74 percent detection against a 17.58 percent false positive rate, which is the expected shape for a maximally aggressive ruleset. SafeLine's free balanced profile shows 71.65 percent detection at 0.07 percent false positives. JXWAF in daily protection mode with the official free model reports 71.28 percent detection at 0.64 percent false positives, and with a privately deployed model 69.91 percent at 0.20 percent.

The provenance matters and the README is explicit about it: the CloudFlare, ModSecurity and SafeLine figures were published by BlazeHTTP, while the JXWAF figure is the most recent measurement from that vendor. So the comparison mixes a baseline measured by one party with the JXWAF side also measured by that party, which is the best available arrangement short of running it yourself.

The second suite is more impressive and easier to verify. Against 477 cases from PayloadsAllTheThings covering 36 attack categories, the README reports a 96.6 percent overall pass rate, with SQL injection, XSS, file inclusion, deserialization and server-side injection all at 100 percent. Per-category figures are deferred to the documentation site.

Three editions differ in deployment shape, not in features

The edition table compares standard, professional and cloud across deployment architecture, scaling, multi-tenancy and intended audience.

The standard edition is a single machine with the five subsystems combined, suited to personal sites and small businesses. The professional edition splits console, node and log system onto separate servers, which is what makes horizontal scaling and elastic node addition practical. The cloud edition adds a management console plus a user console, adds multi-tenant management, and adds automatic CNAME onboarding, which is the feature that makes sense when several departments share one security team.

WebTDS real-time analysis, offering millisecond-level threat analysis without writing code, is present in professional and cloud but not standard. It is described as detecting advanced persistent threats, protecting against sophisticated crawlers, and analysing business security risk.

The repository tree mirrors the editions with `Standard/`, `Professional/`, `Cloud/` and `WebTDS/` directories at the top level, plus `jxwaf_model_update/` for the model update path and `English.md` alongside the Chinese README. The project's primary language in the repository metadata is Vue, consistent with a Vue console front end over a Lua-based node, since the listed topics include `nginx-lua` and `openresty`.

Licensing, releases and what the repo does not include

JXWAF is GPL-2.0 licensed with a `LICENSE` file in the tree, has 1,225 stars and 268 forks, and has 6 open issues. It is not archived and the last push was recorded on 2026-09-19.

The release history is thin: v4.1 on 2024-05-25, v4.3 on 2024-07-07 and v4.5 on 2025-03-28, the last with an empty description. There is no release between March 2025 and the September 2026 push, which means the code in the repository is ahead of anything with a tag. That is worth noting for anyone pinning a version rather than tracking a branch.

There are also live demo environments, including a professional edition demo, a cloud admin console demo and a cloud user console demo, all sharing the published demo credentials. Product documentation lives at docs.jxwaf.com, and the README repeatedly defers to it for deployment tutorials, the full performance report and the per-category protection report.

The honest summary is that this is a commercial product with an open repository, where the repository carries the standard edition and a great deal of benchmark data, and the professional and cloud editions are partly behind a sales conversation. The performance and detection tables are genuinely more informative than most vendor documentation, and the gap between 67,849 QPS forwarding and 10,574 QPS fully protected is the number to plan around.

Editorial conclusion

JXWAF's most useful contribution is the honesty in its performance table. A single 4C8G node forwarding 67,849 HTTP requests per second falls to 36,388 with the model and semantic engine, and to 10,574 with every protection module enabled, which is the number that matters when you are sizing a deployment. The standard edition is genuinely one `docker compose up` away from running on Debian 12 or Ubuntu 20.04, with a 4C8G machine as the stated floor. Two caveats belong in any evaluation: the comparison figures come from BlazeHTTP with competitor numbers published by that vendor rather than re-measured here, and the newest tagged release is v4.5 from 2025-03-28 while the repository was pushed on 2026-09-19.

Frequently asked questions

Official sources

1. jx-sec/jxwaf on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases