Nexren ShieldFive layers, one request path
We write down how Nexren Shield works, what we measure and where our limits are. Every number here rests on a published measurement or a constant in our source code.
Simplified view. Red labels show the decisions each layer can make.
Each layer filters what the previous one let through
Kernel layer
Packets from banned addresses are dropped right behind the network card, before they even enter the server's connection tracking table. Breakwave limits connection and SYN floods per address.
- XDP mode
- generic (skb), two-step activation approved by the operator
- SYN rate limit
- 100/s per IP, burst up to 200
- Concurrent connections
- 300 per IP
- Fallback path
- raw/PREROUTING ipset DROP
- SYNPROXY
- implemented and tested, off by default in production
Connection layer
The encrypted connection terminates at Nexren. Certificates are obtained and renewed automatically. The connection's fingerprint is used to judge whether the client is a real browser.
- TLS
- HTTP/2-capable termination
- Certificate
- Let’s Encrypt (ACME v2)
- Renewal
- 15 days before expiry, automatic
- Reload
- every 15 seconds, without restarting the service
- Fingerprint
- JA3/JA4 and HTTP/2 (Akamai style)
Application layer
The content of the request is read. Known attack patterns are blocked, and clients suspected of being bots are shown a verification. When a flood is detected the site switches to verification mode, regardless of plan.
- WAF signatures
- 600+ rules, with input normalization
- Attack families
- SQLi, XSS, RCE, LFI, SSRF
- Bot verification
- time-locked proof of work (RSW, WebAssembly)
- Risk model
- logistic regression, adds at most 30 points to the score
- Reputation lists
- Spamhaus DROP, FireHOL level1, daily
- Edge cache
- optional per site, off by default
Access and auditing
Origin Lock™ ensures your server can only be reached through Nexren. Panel access, team permissions and the change log are managed from the same place.
- Origin Lock™
- shared secret header + origin firewall script
- Zero Trust
- access verified with OTP / TOTP
- Team permissions
- view or edit access per module for each member
- Audit log
- HMAC-SHA256 chained, tamper-resistant
- Alerts
- Slack, Discord, Telegram, email
We measured the cost of a blocked packet
Six drop scenarios on the same server. The main measure is the CPU time spent per packet on the receiving side; it is independent of load.
- XDP generic (539 ns) is ~47% cheaper per blocked packet than an iptables INPUT drop (1020 ns) and ~11% cheaper than raw/PREROUTING (607 ns). The order held in all 7 rounds.
- The gap between raw and XDP is real but small: generic XDP also runs after the skb is allocated; the gain comes from skipping netfilter and connection-tracking entry.
- In a SYN flood against an open port, the connection-tracking table filled on every run with SYNPROXY off (262,143). With SYNPROXY on, it stayed at 0 and the per-packet cost fell by ~31% (1885 vs. 2752 ns): the main gain is protecting the state table.
Receiver softirq, ns/packet · median (lowest–highest) · 7 Oct 2026 · 6 scenarios × 7 runs × 5 s
Two network namespaces and a veth pair were set up on the same virtual server; nothing was connected to the live interface. The generator sent a spoofed-source IPv4 SYN flood, choosing the source address from within a /16 and the source port at random for every packet (in practice every SYN is a new flow). In the blocked scenarios all 65,534 addresses of the /16 were on the list. Connection tracking was on in every scenario. Each run was done in a fresh namespace pair; scenarios were run in rounds in alternating order and the generator was pinned to a single vCPU. An independent 7-run repeat differed by less than 3% in scenarios 1–3. The measurement scripts and raw data are kept in our source repository; the table can be regenerated from the raw data. XDP attach/detach and SYNPROXY behavior are additionally tested end to end in isolated network namespaces.
These numbers are a relative comparison between layers. veth + generic XDP + a virtual machine is not the line rate of a real network card; absolute pps/ns values are specific to this server's veth path. The sender and receiver share the same vCPU; multi-queue (RSS) distribution was not measured. The packet rates presented are not a server capacity. Only IPv4 and 40-byte SYN packets were measured; IPv6 and bandwidth (Gbps) were not. Live services were running during the measurement; alternating order and N=7 spread the noise but do not eliminate it. The SYNPROXY scenario was measured with the per-IP Breakwave limits off; in production the limits are applied before SYNPROXY.
Where and on what we run
Nexren Shield runs in a data center in Türkiye. Protection capacity is determined by the server and the hosting provider's network uplink.
- Region
- A single data centre in Türkiye, one region
- Server
- One virtual server · 8 vCPU · 16 GB RAM · Debian 12
- Network
- No anycast or BGP; no upstream traffic scrubbing
- Kernel / XDP
- Linux 6.1 · generic (skb) XDP; native (driver) XDP needs Linux 6.6+ on this NIC
- Application
- Bun + TypeScript; gateway, edge and control plane as separate services
Everything you do in the panel is available in the API too
The REST API and MCP server follow the module permissions in the panel exactly.
- REST API v1
- OpenAPI 3.1 document, scope-limited API tokens, rate limiting and Idempotency-Key responses stored for 24 hours.
- MCP server
- Six tools over JSON-RPC 2.0 — list sites, site details, add a site (with DNS verification), purge cache, read the WAF configuration and query events.
Questions about the infrastructure?
Write to our technical team about measurements, limits or setup.