Receive the request
NGINX passes request context to the local edge. The route identifies whether this is browsing, search, login, checkout or a machine integration.
TRABOTPRO / ARCHITECTURE
Local protection.
Central intelligence.
A local decision layer alongside your store, with centrally managed policies and visibility across the fleet.
01 / THE ARCHITECTURE
Your traffic stays local.
Your policies stay connected.
NGINX remains the entry point. TraBotPro evaluates requests alongside your store, while the central console manages policies and collects insights.
REQUEST PATHInside your existing infrastructure
01
Visitor
Browser, crawler
or integration
HTTPS
Your NGINX
TLS & request handling
Allowed traffic
Your store
Cache & PHP-FPM
Request contextLocal decision
LOCAL DECISION ENGINE
TraBotPro edge
Verify identity. Evaluate signals.
Apply the policy for this route.
Signed policiesEvents & health
CENTRAL MANAGEMENT
TraBotPro console
Fleet policies, site overrides,
traffic intelligence & audit history.
The console is outside the live request path. Decisions use the configuration available on the local edge.
02 / INSIDE THE DECISION
From request context
to a clear response.
Identity, behaviour and route policy work together. A familiar User-Agent is a claim to verify; a single unusual signal is context to investigate.
Route · headers · network context
Check lists and identity
Evaluate allow and deny lists, active bans, crawler identity and scoped exceptions. A false crawler claim or a matching hard rule can determine the outcome independently of the score.
Build the risk picture
Combine connection hints, header consistency, reputation, request tempo and behavioural patterns. Valid clearance and human evidence can lower risk.
Apply the route policy
Evaluate the risk score against the policy for this route and site. Rate controls, WAF inspection and targeted virtual patches add protection where applicable.
Return the decision
The edge returns a response for NGINX to enforce. Allowed traffic continues; suspicious traffic receives a suitable check, a rate limit or a block.
Record what happened
Traffic counters provide the overall picture. Decisions and sampled allowed requests support investigation, while health metrics show how the protection layer is operating.
Scores, weights and thresholds are configurable and remain private. The visitor flows use fictional examples to explain the decisions.
Explore the fifteen visitor flows03 / THE RESPONSE
The right amount
of verification.
Escalate checks when context calls for it, while keeping customers and essential integrations moving.
Allow
Let legitimate traffic continue. Verified crawlers and scoped integrations follow their own policies.
Invisible check
Collect browser evidence in the background and establish clearance with minimal interruption.
Proof of work
Require additional computational work to raise the cost of automated traffic on suitable routes.
Interactive check
Ask for stronger interaction evidence when the combined context warrants it.
Rate limit
Return a 429 response when requests exceed configured limits, including expensive search and API routes.
Block
Stop requests that meet blocking rules or policy conditions before they reach the application.
Machine traffic needs machine policies.
Payment webhooks, API integrations and legitimate crawlers should not receive browser puzzles. Scoped exceptions and identity checks keep protection appropriate. Your application still performs its own authentication.
04 / BUILT TO OPERATE
Protection is only useful
when you can run it reliably.
Central console unavailable
The edge continues using its last good configuration. Bounded local buffering supports later delivery of events when connectivity returns.
Local edge unavailable
The NGINX integration uses a short decision timeout and fails open so requests can continue. Monitor edge health to detect when protection is degraded.
Policy changes
Signed snapshots are validated before replacement. Shared policies and per-site overrides support controlled changes with an audit trail.
Monitor before enforcing
Review proposed decisions without blocking traffic. Use simulation and backtesting to assess changes before moving into enforcement.
Traffic and infrastructure together
Investigate requests alongside latency, cache behaviour and fleet health. Prometheus metrics and Grafana support operational monitoring.
Know the fingerprinting boundaries
Hypernode provides TLS hints and header information for JA4-lite and consistency checks. Full TLS and HTTP/2 fingerprints require suitable termination on your own infrastructure.
05 / DEPLOYMENT
Keep your stack.
Add a decision layer.
TraBotPro runs alongside Magento on Hypernode. No new reverse proxy, root access or Docker is required. Your existing NGINX and caching setup stay in place.
- Connect & validate
Configure the local integration, establish the correct request context and verify important store routes.
- Observe & tune
Start in monitor mode. Review customers, crawlers, search, checkout and payment callbacks against the proposed policies.
- Enforce & review
Enable enforcement after review, then follow decisions, customer impact and edge health as traffic changes.
MAKE ROOM FOR REAL CUSTOMERS
Your traffic deserves
a smarter gatekeeper.
Start with your setup. Build a rollout brief for your TraBotPro contact.