Nexren ShieldWhat does Under Attack mode do?
Under Attack mode asks every new visitor to pass a short verification before seeing any content. Once they pass, they see the normal page. A bot or a simple script that does not run JavaScript cannot pass, so an application-layer (L7) flood is filtered before it reaches your server.
The mode shifts the cost of verification onto the visitor and the attacker: a few seconds for a real browser, far more for a bot sending thousands of requests. The guide on attack types explains how L7 attacks work.
When do you need it?
If several of these signs appear together, an attack is likely:
- RPS spikes. Requests per second jump to several times normal within minutes.
- Origin CPU and memory climb. The server is under load, but your real user count has not changed.
- Many unique IPs hit one URL. Especially search, login or an expensive API endpoint.
- The 5xx rate rises. The server cannot keep up and timeouts begin.
- Unusual User-Agent or country mix. A source you do not normally see concentrates.
High traffic alone is not proof of an attack, so confirm first.
Is it an attack or a campaign?
A viral post or an e-mail campaign raises traffic too. To tell them apart, check these:
| Question | Campaign/viral | Attack |
|---|---|---|
| Where is the traffic going? | Campaign page, varied content | One URL or one expensive endpoint |
| Is there a referrer? | Social media, e-mail, news | Empty or forged |
| Session behavior | Browsing across pages, long stays | Single request, instant exit |
| Geography | Matches your audience | Unrelated countries |
| Marketing news | Your team knows | Nobody knows |
| Browser variety | Real browser mix | Uniform or outdated User-Agent |
Asking your marketing team is the first step. If it is still unclear, switching the mode on briefly and watching the effect is a reasonable approach: verification lets real visitors through with a few seconds of delay and keeps filtering bots.
What do visitors see?
Instead of the page, the visitor sees a short verification screen. A real browser solves it in the background, usually within a few seconds, and gets redirected. No clicking or puzzle is needed. After passing, the visitor receives a clearance cookie and does not see the screen again in the same session. The cookie has a limited lifetime; when it expires, verification renews.
A user who has disabled JavaScript, or a very old browser, cannot pass. Brief your support team: if a complaint arrives, ask the user to enable JavaScript and reload. A small delay on first entry is normal while the mode is on; treat it as an acceptable cost for the duration of the attack, and measure it.
Which side effects should you know?
- API and webhook clients. A server or mobile app cannot display the verification page or run JavaScript. Define excluded paths for these clients and rely on rate limits and token protection.
- SEO crawlers. Search bots that cannot pass the page cannot see your content. Make sure verified search crawlers are handled separately.
- Caching. If you run your own CDN or cache layer, check that the verification screen does not get cached; otherwise everyone sees the same interstitial.
- Mobile apps and embedded web views. In-app browsers may restrict JavaScript. Test them.
- WebSocket connections. A WebSocket upgrade (RFC 6455) cannot show an HTML page and needs its own rule.
- Payment and callback URLs. A payment provider's callback cannot pass verification; exclude those paths.
What should you do during an attack, step by step?
- Confirm. Use the table above to separate attack from campaign, and note the incident time.
- Review the excluded paths. Webhooks, payment callbacks, health checks.
- Turn the mode on. Enable Under Attack if your plan allows it.
- Watch. Track RPS, the 5xx rate and the number of visitors passing verification. Share legitimate user complaints with your team.
- Keep records. Source IPs, paths and rule data in the event log help you tune thresholds for the next attack.
- Turn it off. Switch it off once the signs below appear.
Exclusions and turning it off
Define the paths to exclude before you enable the mode: webhook endpoints, payment callbacks, health checks, public APIs.
For the off decision, look for these signs: RPS back to normal, the 5xx rate down, attack source IPs no longer arriving or already blocked. Watch for half an hour after switching off, and re-enable if the attack continues. If attacks recur for weeks, a permanent mode can make sense, but choose it deliberately.
Decision checklist
| Indicator | Threshold (relative to your baseline) | Action |
|---|---|---|
| RPS | Several times your baseline | Check the distribution |
| Unique IPs per URL | Unusual on a single URL | Consider Under Attack |
| Origin CPU | Sustained high | Enable Under Attack |
| 5xx | Rising | Enable Under Attack, check capacity |
| Marketing campaign running | Yes | Verify the campaign first, do not enable |
| Uplink saturation | Clogged at the provider | The mode will not help; contact your provider |
How Nexren Shield handles this
Automatic verification. When a flood is detected, the site switches to verification mode automatically on every plan.
Manual Under Attack. On Pro and Enterprise plans you switch it on yourself. Every visitor passes a CAPTCHA verification once and receives a clearance cookie. Background API/XHR clients receive a JSON 403 (RFC 9110) asking them to reload. WebSocket upgrades, static assets and excluded paths follow separate rules.
Manual RPS threshold and permanent mode. On Pro and Enterprise plans you can set your own RPS threshold or keep attack mode permanently on.
Per-IP and per-path limits. Rate limits return 429 with Retry-After (RFC 6585). Traffic profiles (api 20, webhook 5, realtime 30 requests per second per IP) are halved during an attack or mitigation.
Verified search crawlers are handled separately.
The honest limit. This mode cannot fix a saturated uplink. A volumetric attack can choke the line at the provider before it reaches the server; Nexren Shield runs in a single region on a single virtual server and has no upstream scrubbing. For how bot verification works, see the bot protection guide; for the overall design, see what Nexren Shield is.
Sources
- RFC 6585: Additional HTTP Status Codes (429)
- RFC 6455: The WebSocket Protocol
- RFC 9110: HTTP Semantics
Related product pages:Help center Technology
Frequently asked questions
Can I leave Under Attack mode on permanently?
Technically yes, but every new visitor sees a verification page, which affects conversion and API clients. Use it temporarily unless your site is under constant threat.
Are search engine crawlers affected by this mode?
Verified search engine crawlers are handled separately. If you leave the mode on for a long time, still watch your crawl rate in Search Console.
How long does the verification page show for a visitor?
Real browsers usually pass within a few seconds. After passing, the visitor gets a clearance cookie and does not see the page again on later requests.
Why does my API return a JSON 403 while the mode is on?
Background API and XHR clients cannot display a verification page, so they receive a JSON 403 asking them to reload. Once the user reloads the page and passes verification, requests flow normally.
Does Under Attack mode help if the uplink is completely saturated?
No. If traffic clogs at the line provider before reaching the server, this mode cannot change that. Volumetric attacks need upstream scrubbing.
Related guides
DDoS Attack Types: L3, L4 and L7 Differences and Defense
DDoS attacks fall into three classes: volumetric attacks that try to fill the line (L3/L4), protocol attacks that exhaust connection tables (L4) and application attacks that wear down the app over HTTP (L7).
Bot Protection and CAPTCHA Alternatives: Methods Compared
Bot protection answers three questions: is the client a real browser, does its behavior look human, and does the request come from a reputable source.
API Security: What Rate Limiting and a WAF Do and Do Not Solve
API security covers two separate jobs: filtering bad traffic from outside and getting the application's authorization logic right.
What Is Nexren Shield? A Reverse-Proxy Web Security Service
Nexren Shield is a reverse-proxy security service that sits in front of your web applications.