Skip to content
naulon
Get started
docs

Protect your origin

When your custom domain routes through us, every request to your origin arrives from the naulon fleet rather than from each visitor directly. That is how we classify humans against agents and apply the toll before your origin ever sees the request. The side effect: your origin sees that traffic coming from one fixed address, and an origin behind its own bot-management or rate-limiting edge can read the concentration 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 the fleet sends on every request to your origin, which you match at your edge with a rule that trusts it and skips your bot and rate challenges. You never write verification code: a static header is something any edge firewall can match with a no-code rule.

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 the fleet's own address, with and without the secret, and tell you what we can see. When your edge only challenges under sustained load, a safe single-request check can't force that challenge, so it may come back inconclusive even when your rule is correct. That is expected, not a failure (more on this below).

The secret only grants "reach an origin we already sit in front of", and TLS keeps it private in transit, so there's little to gain by replaying it. Rotate it any time by regenerating, which 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 a WAF Skip rule can't bypass Bot Fight Mode: it isn't part of the rule engine, so no rule can make an exception for it, and a header rule won't help. Allow the fleet'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 fleet 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

Vercel Pro and above, the header rule:

  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 still applies, with a caveat. Unlike Cloudflare, Vercel's Free plan can match on a header, so the Bypass rule above works for anything the WAF handles. But a WAF Bypass only skips WAF evaluation. It does not exempt you from Vercel's system-level rate limiting (the automatic mitigation that returns 429 under load, e.g. on _rsc prefetches). That layer is cleared by a System Bypass for the fleet's egress IP (shown in the panel):

vercel firewall system-bypass add <egress-ip>

System Bypass is a paid-plan feature. So if you're on Free and still seeing 429s under load, the header rule alone can't fully solve it. Upgrading the plan, or moving that origin behind an edge you can IP-allow, is the durable fix.

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) {
  // fleet 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've already done the human-vs-agent classification before the request reaches you, so a second check here only fights ours, so prefer leaving it off the routes we proxy.

Verify it worked

Back in the panel, click Verify. We fetch your origin from the fleet's own egress 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 signed one. The bypass works, proven from the same address real fleet traffic comes from. (If the wrong value was also served, your rule checks only that the header is present, not its value, so tighten it to an exact match.)
  • Inconclusive. Every request came back clean, including the one sent without the secret. So nothing here challenges a single request, and there's nothing for the rule to act on. This is the normal result when your protection only kicks in under load (rate limiting) or isn't header-based (Bot Fight Mode). It is not a failure. Real fleet pulls carry the secret and pass; if your live site isn't throwing 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 any time from the panel. The new secret replaces the old one immediately, so the fleet starts sending the new value at once, so update your edge rule to the new secret in the same sitting, or the bypass breaks until you do. There's no dual-secret grace window by design; a single value is all a no-code edge rule can match.