Skip to main content
Every Hiveku-hosted site sits behind Hiveku’s edge firewall. Bulk scrapers are blocked and unknown automated clients are asked to prove they are a browser; real visitors, search engines, AI assistants, link previews and common uptime monitors pass without noticing it. The Firewall section on the Hosting page shows what the firewall did for your site and lets you allow a specific client — an uptime monitor, an agency’s audit tool — without turning protection off.
The section opens with its status line: “Hiveku’s edge firewall protects this site. Bulk scrapers are blocked and unknown automated clients are asked to prove they are a browser. Real visitors, search engines, AI assistants, link previews and common uptime monitors pass.”

​
What the counters mean

Three counters cover the last 7 days, with the coverage date under them (“through 2026-09-17, updated daily”). The numbers are rolled up once a day from the edge access logs, so today’s traffic shows up tomorrow. When nothing was challenged, blocked or rate limited, the section reads “Nothing has been challenged in the last 7 days.”

​
The clients table

Automated clients that were challenged or blocked lists the top 20 clients by request count over the same 7 days: Below the table, Allowed for this site lists every allowance in place: its kind (user agent or address), the value, your note, who added it and when, with a Remove action on each row.

​
How to allow a client

1

Open the Firewall section

From your project, click Hosting in the sidebar and scroll to Firewall.
2

Find the client

Look for your monitor or audit tool in the clients table. The Client column shows the user agent it sends; hover to read the whole string.
3

Click Allow

A small confirmation opens with the proposed exception: the client’s own user-agent token when it has a distinctive one (for example MyMonitor/2.1), or its address when the user agent is generic.
4

Confirm

Add a note if you want to remember why (for example “Uptime check for the marketing team”) and confirm. The allowance is saved immediately and pushed to the edge; if the edge cannot be updated at that moment, it is picked up within the day.
The Allow button works from a row in the table. A client that has not appeared yet shows up after the next daily rollup, so let it make a few requests first.

​
What an allowance does and does not do

Allowing a client skips the browser check only. Volume limits and the blocks on known scraper networks still apply. An allowed user agent works on this site’s addresses only; an allowed IP address is trusted wherever it goes on Hiveku hosting.
  • A user-agent allowance matches any request to this site whose user agent contains the token, case-insensitively. It works on this site’s addresses only, because a user agent can be copied by anyone. A token that would exempt browsers or verified bots (for example Mozilla, Chrome, Googlebot, bot or http) is refused; use the product’s own token instead. bot is refused even inside a product name, so a client with such a name is allowed by address.
  • An address allowance matches one IPv4 or IPv6 address or a small range. It is trusted across Hiveku hosting, because an address identifies one machine. Private, loopback and multicast ranges are refused.
  • Each site can hold up to 10 active allowances. Remove one you no longer need before adding another.
  • An allowance never lifts the per-address rate limit or the block on known scraper networks, so a monitor that hammers the site is still rate limited.

​
Removing an allowance

Under Allowed for this site, click Remove on the row. The change is pushed to the edge right away and, at the latest, by the next daily sync; from then on that client is challenged like any other.

​
Troubleshooting

If the monitor reports an HTTP 202 with an empty body, or a response carrying the header x-amzn-waf-action: challenge, that is the firewall’s challenge, not your site; visitors are seeing the page. Either have the monitor send a recognisable user agent — its product name and version — or find it in the clients table and click Allow. A HEAD request is never challenged, so a monitor that only needs the status code can use one.
A token that appears in every browser’s user agent, or in a verified search-engine bot’s, would exempt all of them, so it is refused. Use the distinctive part of your tool’s user agent instead, such as MyMonitor/2.1, or allow the client by address.
Either nothing automated was challenged, blocked or rate limited in the last 7 days, or the daily rollup has not run yet for a site that was just deployed. The coverage date under the counters says which day the numbers run through.
An allowance reaches the edge within the day. If the client is still challenged after that, hover the Client column and check that the token you allowed really appears in the user agent it sends, and check its Outcome: an allowance does not change a Blocked or Rate limited row.

​
What’s Next?

Site Enhancements

Cookie consent, security headers, PWA, SEO

View Deployment & Runtime Logs

Debug production issues with log streaming