Documentation
First-party proxy: Cloudflare Worker route guide
Ad blockers often block a known analytics host. They do not block the customer's own domain. A route on the customer's Cloudflare zone fetches the script and the collect endpoint from AnalyticFast, while the browser only talks to the customer's host.
This is a customer Worker, not a change to AnalyticFast's wrangler.jsonc. Custom hostnames (stats.customer.com CNAMEd onto AnalyticFast) are a different product and are not built. See custom hostnames.
Checked 2026-10-26: Workers routes.
Route
On the customer's zone, attach a Worker to the exact paths you choose, for example:
example.com/af/script.jsexample.com/af/event
Leave every other path on the customer's origin.
Worker
const ANALYTICS = 'https://YOUR_ANALYTICS_HOST';
export default {
async fetch(request) {
const url = new URL(request.url);
const targetPath = url.pathname === '/af/script.js' ? '/js/script.js'
: url.pathname === '/af/event' ? '/api/event' : null;
if (!targetPath || (targetPath === '/api/event' && request.method !== 'POST' && request.method !== 'OPTIONS')) {
return fetch(request);
}
const headers = new Headers(request.headers);
headers.delete('cookie');
headers.delete('authorization');
return fetch(new Request(ANALYTICS + targetPath + url.search, {
method: request.method,
headers,
body: request.method === 'POST' ? request.body : undefined,
redirect: 'manual',
}));
},
};
YOUR_ANALYTICS_HOST is the AnalyticFast origin (TRACKING_ORIGIN), with no trailing slash.
Script tag
<script defer data-website-id="YOUR_SITE_ID"
data-api="https://example.com/af/event"
src="https://example.com/af/script.js"></script>
The tracker already reads data-api (src/tracker/tracker.js). The page URL inside the event (u) must still be an allowed hostname for that site. The proxy's own host is not what the domain check uses.
What this does not do
- It does not store the visitor address. AnalyticFast hashes
CF-Connecting-IPonly when cookieless mode is on, then drops it. A customer Worker in front means AnalyticFast's edge sees the Worker, not the browser, so cookieless ids can collide for people who share that egress. Prefer normal cookies when you proxy, or accept one id per address and user agent per UTC day. - Do not forward
X-Forwarded-For. The collector does not read it (it is client-controlled). - Do not log request bodies or addresses in the customer Worker.
- The collect payload cap is still 8192 bytes. Over that, AnalyticFast returns 413 and stores nothing.
Rate limit behind a proxy
Hosted AnalyticFast limits ingest per sender address, about 300 events per 10 seconds per site in each Cloudflare location. Pings don't count toward it. Behind this proxy, every visitor reaches AnalyticFast from the proxy's address, so the whole site shares that one allowance. That covers a site with roughly a thousand visitors active at the same moment. Above that, events are dropped silently with a 202, and the customer's site never sees an error. If you expect more traffic than that, load the script directly instead of through the proxy, or ask the operator about a higher limit.
Questions, answered.
How do I use first-party proxy: cloudflare worker route with AnalyticFast?
Follow the First-party proxy: Cloudflare Worker route instructions on this page using your own website’s Site ID and configuration. Verify a real event before relying on the reports.
Where can I get setup help?
Contact support@analyticfast.com with the website domain and a redacted description. Do not send API tokens, signing secrets or personal customer data.