Astro Scripts and embeds
Network blocker
What the network blocker does
networkBlocker stops fetch and XMLHttpRequest calls that match a rule
until the visitor allows the rule's category. A blocked fetch resolves to a
451 response, and nothing is sent. It covers requests that code already on
the page makes, such as an SDK you load yourself or a tag manager's own calls.
It does not stop navigator.sendBeacon, WebSockets, image pixels, <script>
tags or iframes. Load scripts through c15t and gate iframes as
Scripts and
Embeds describe.
Add rules
Rules are plain data, so they can go in the integration options:
| Rule field | Effect |
|---|---|
category | The category that must be allowed for the request to go through |
domain | The host to match. It also matches every subdomain |
pathIncludes | Matches only URLs whose path contains this text |
methods | Matches only these HTTP methods |
vendor | Also requires this vendor to be allowed, for vendor-level consent |
| Option | Default | Effect |
|---|---|---|
rules | Required | The rules to apply |
enabled | true | Set false to keep the rules but stop blocking |
logBlockedRequests | true | Logs each blocked request to the console. Set false to silence it |
The blocker starts with the consent runtime, from a module script. A request
made before that, such as from an inline script at the top of <head>, is not
blocked.
Log or report blocked requests
onRequestBlocked is a function, so it cannot go in astro.config.mjs. Set
networkBlocker in the default export of your client entrypoint instead. It
replaces the integration's networkBlocker completely, so repeat the rules
there:
Check the network blocker
- Open the site in a private window with DevTools Network open, and trigger
the code that calls a blocked host. The request does not appear, and a
fetchreceives a451response. - Allow the rule's category. The next request to that host goes through.
- Withdraw the category and save. After the reload, requests to the host are blocked again.