Protect your origin

When your custom domain routes through us, every request to your origin comes from naulon, which classifies humans and agents and applies the toll first. Your origin therefore sees all that traffic from one fixed address. If it sits behind its own bot-management or rate-limiting edge, that edge can read it as a single-source flood and start challenging it. Full page loads usually survive; background requests (prefetches, fetch/XHR, feed pulls) don't, so the site feels slow or half-broken.

The fix is a shared secret naulon sends on every request to your origin. You add an edge rule that matches it and skips your bot and rate challenges. Any edge firewall can match a static header without code.

Generate the secret in your domain's settings (Protect your origin → Generate secret). We then send it on every request to your origin as:

x-naulon-origin-auth: <your secret>

Add the matching rule for your platform below, then click Verify. We fetch your origin from our own address, with and without the secret, and report what we see. If your edge only challenges under sustained load, a single request can't trigger the challenge, so the result may be inconclusive even when your rule is correct (see below).

The secret only lets a request reach an origin we already sit in front of, and TLS keeps it private in transit. Regenerating it breaks the bypass until you update your edge rule, so change both together.

Cloudflare

If your own origin sits behind Cloudflare (this is your Cloudflare in front of your origin, not ours), the right lever depends on your plan.

Cloudflare Pro and above, the header Skip rule:

1. Cloudflare dashboard → the zone for your origin → Security → WAF → Custom rules → Create rule.

2. Set the rule to match this expression (edit it in the expression editor, or build the same in the visual editor: Field Header, name x-naulon-origin-auth, Operator equals, Value your secret):

   http.request.headers["x-naulon-origin-auth"][0] eq "<your-secret>"

3. Action: Skip → All remaining custom rules, plus the managed features you want bypassed. A Skip rule can skip your rate-limiting rules, Managed Rules, and Super Bot Fight Mode.

4. Order it above your challenge and rate-limit rules. Cloudflare evaluates top-down, so a skip below a block never runs. Deploy.

Cloudflare Free

On the Cloudflare Free plan no WAF rule can bypass Bot Fight Mode, because it sits outside the rule engine. Allow naulon's egress IP instead:

1. Cloudflare dashboard → the zone for your origin → Security → WAF → Tools → IP Access Rules.
2. Add a rule: the egress IP shown in the Protect your origin panel, Action Allow, scoped to this zone.

Bot Fight Mode skips any request an IP Access Rule already allowed, so naulon traffic passes without a challenge. (If you later move to Cloudflare Pro, switch to the header Skip rule above, which is IP-independent.)

Reference: Cloudflare WAF custom rules · IP Access Rules.

Vercel

The header rule (every Vercel plan):

1. Vercel → your project → Firewall → Configure → Add rule.
2. Condition: Header x-naulon-origin-auth Equals your secret.
3. Action: Bypass (skips the rest of the firewall for that request). Save and deploy.

On Free the header rule works, with a caveat. Vercel's Free plan can match on a header, so the Bypass rule covers anything the WAF handles. It does not exempt you from Vercel's system-level rate limiting (the automatic mitigation that returns 429 under load, for example on _rsc prefetches). That layer needs a System Bypass for naulon's egress IP (shown in the panel):

vercel firewall system-bypass add <egress-ip>

System Bypass is a paid-plan feature. If you're on Free and still see 429s under load, upgrade the plan or move that origin behind an edge you can IP-allow.

Reference: Vercel Firewall.

AWS WAF

If your origin is behind AWS WAF (in front of an ALB or CloudFront):

1. In the web ACL for your origin, Add rule → Rule builder.
2. Statement: inspect a single header x-naulon-origin-auth, match type Exactly matches string, value your secret.
3. Action: Allow.
4. Set its priority below (evaluated before) your rate-based and bot-control rules, so an allowed request never reaches them. Save.

Reference: AWS WAF string-match rules.

Other edges

If you guard your origin in application code or an edge middleware rather than a managed WAF, trust the header there and skip your own bot/rate logic for it:

if (request.headers.get("x-naulon-origin-auth") === YOUR_SECRET) {
  // naulon traffic, already classified human-vs-agent for you; let it through
  return;
}
// ...your normal bot / rate checks for everyone else

Keep YOUR_SECRET in your platform's secret store, not in source. We classify human against agent before the request reaches you, so leave your own bot check off the routes we proxy.

Verify it worked

Back in the panel, click Verify. We fetch your origin from our own egress address three times: once without the secret, once with a deliberately wrong value, and once with the correct one. Then we compare:

• Confirmed. Your origin challenged the unauthenticated requests and served the one with the secret, from the same address real naulon traffic uses. (If the wrong value was also served, your rule only checks that the header is present; change it to an exact match.)
• Inconclusive. Every request came back clean, including the one without the secret, so nothing challenges a single request. This is the normal result when your protection only acts under load (rate limiting) or isn't header-based (Bot Fight Mode). If your live site isn't returning 429s or timeouts, you're set.
• Still challenged. The edge blocked even with the correct header, so the rule isn't matching. Check the header name (x-naulon-origin-auth) and the secret value character-for-character, and that the rule is ordered ahead of your block rules.

Rotating the secret

Regenerate from the panel. naulon sends the new secret immediately, so update your edge rule straight away or the bypass breaks until you do. There is no window where both secrets work, because a no-code edge rule can only match one value.