Understand how Hexa Shield protects your traffic.

After you create an account and verify your email, add a website from the dashboard by giving Hexa Shield your domain's hostname and your origin server's address (the server currently serving that site). Hexa Shield never modifies your origin — it only needs to know where to forward traffic once it has passed through the security pipeline.

Once a domain is added, it starts in the pending state. You'll need to point its DNS at Hexa Shield and prove you control the domain before traffic starts flowing through it — that's covered next.

The dashboard's DNS instructions panel gives you two independent ways to prove ownership of a domain: a DNS TXT record, or a token file served over HTTP at a well-known path. You only need one to pass, though DNS TXT is usually more convenient since it doesn't require your origin to be reachable yet.

Separately, your domain's A/CNAME record needs to point at Hexa Shield's public address for traffic to actually reach it — the dashboard shows this target and reports whether your DNS is currently pointed correctly. A domain can pass ownership verification and still show dns_pending if its DNS hasn't been repointed yet.

Each domain has its own connect/response/idle timeouts and a maximum request body size — there is no hardcoded upload cap; set it to whatever your application actually needs, including several gigabytes for large file uploads. The WAF and bot-tagging can each be turned off independently for a domain that needs to bypass them temporarily.

A managed rule catalog screens the request line, headers, and query string — never the request body, so large uploads and streaming API calls are never buffered for inspection — for patterns like directory traversal, common SQL-injection and XSS indicators, malformed requests, and suspicious automation signatures. You can disable any individual managed rule per domain if it produces false positives for your application.

Custom rules let you match on URI, method, client IP, header values, or user agent using simple contains/equals conditions, and choose to allow, log, block, or rate-limit matching requests. Custom rules are deliberately restricted to this closed set of conditions — there's no arbitrary code execution in a rule, by design.

Rate limit rules use a sliding-window algorithm, scoped to the whole domain, a route prefix, a client IP, or a specific method+route combination. Limits are enforced by every request-handling node against the same shared counters, so they hold consistently even if traffic is later distributed across more than one node.

Allow, block, or temporarily block traffic by individual IP or CIDR range, either for one domain or account-wide. An explicit allow rule always takes precedence over a block — this is also how an emergency unblock works: create an allow rule for the address in question and it immediately overrides any broader block.

Scoped API keys (from the dashboard's API Keys page) let you read domain configuration, analytics, and security events programmatically, using the same endpoints the dashboard itself calls. A key's secret is shown exactly once at creation time — only its hash is stored, so if you lose it you'll need to revoke it and create a new one.