WebDecoy’s Fastly integration now does detection and protection. It reads the requests your Fastly service answers, reports the automated ones, and blocks addresses in a Fastly Access Control List (ACL). Both halves are configuration in your Fastly service. Nothing is installed in your application.

Until now, Fastly was only a place to push blocks. That was half a product. A block list is only as good as what fills it, and a browser tag cannot see a client that never runs JavaScript: AI crawlers, scrapers, curl, headless scripts. Fastly sees every one of them, so Fastly is now also where WebDecoy looks.

Detection: stream your Fastly logs to WebDecoy

Fastly can post a log line for every request to an HTTPS endpoint. WebDecoy gives you that endpoint, a secret header and a log format. Each line carries the client address, user agent, path, status, cache result and the JA4 TLS fingerprint, which identifies the client software even when the user agent lies.

WebDecoy classifies each request:

  • Automated requests are reported to your dashboard as detections from Fastly, with the crawler named where WebDecoy knows it.
  • Everything else is counted and dropped. Ordinary visitors are never stored.

Because the log is sent after Fastly has answered, detection never sits in your request path and never changes a response.

On our own test service, a stranger’s curl from a hosting network found the brand-new domain within minutes, before we had told anyone it existed. It was reported as a crawler.

Protection: block an address in your Fastly ACL

Blocking uses a Fastly ACL and one line of VCL that you control:

if (client.ip ~ webdecoy_blocklist) {
  error 403 "Forbidden";
}

From the Fastly page in WebDecoy, choose Block an address, give it a duration and a reason, and apply it. WebDecoy adds the ACL entry and then reads it back from Fastly to confirm that Fastly holds it. When the block expires, WebDecoy removes it again: a Fastly ACL entry has no expiry of its own. Every change is listed with its state, its author and its reason, so a block made at 2 a.m. can still be explained a month later.

ACL entries take effect without a new service version, so a block applies within seconds. In our end-to-end test, the blocked address got 403 on the next request and 200 about a minute after we removed the block.

Automatic blocking from detections acts only on detections whose score has been calibrated. Until then, you decide what gets blocked.

One limit to know: a Fastly ACL holds addresses only, and your VCL decides where it is consulted. A block applies everywhere that service consults the ACL, not to one hostname. WebDecoy says so next to every block rather than letting you assume otherwise.

Setup

  1. Create a Fastly API token. An automation token with the Engineer role and global scope, for all services or only the ones WebDecoy should manage.
  2. Create the ACL and the VCL snippet above in your Fastly service, then activate the version.
  3. Add the integration in WebDecoy under Integrations → Fastly: your token, the service ID and the ACL name. Fastly’s dashboard never shows an ACL’s ID, so WebDecoy looks it up from the name. Test confirms the token can read the ACL.
  4. Turn on log streaming from the same integration. Create an HTTPS logging endpoint in Fastly with the values WebDecoy shows, and activate the version. Fastly checks that WebDecoy expects your service before its first delivery.
  5. Prove it:
curl -A "WebDecoy-Test/1.0" https://your-site.example/

A detection labeled Test appears once Fastly delivers the log. The first delivery after activating can take a few minutes, after which Fastly sends batches every few seconds.

The Fastly setup guide has every field, including the log format to paste.

Where Fastly fits

Fastly joins Cloudflare, Netlify and Vercel as a platform where WebDecoy both detects and protects at the edge. If your site runs on Fastly, you can now see the traffic your analytics never shows, and act on it where it arrives.

Connect Fastly in WebDecoy or read the setup guide.

Frequently Asked Questions

Do I need to change my application to use WebDecoy with Fastly? +

No. Detection uses a Fastly HTTPS logging endpoint, which is configuration in your Fastly service. Blocking uses a Fastly ACL and a one-line VCL snippet. Nothing is installed in your application.

Does log streaming slow down or change my responses? +

No. Fastly sends the log after it has answered the request, so WebDecoy is never in the request path. Log streaming changes no response; only the ACL block does, and only for addresses you have blocked.

Does WebDecoy store my human visitors' requests? +

No. Every request in the stream is classified, the automated ones are reported to your dashboard, and the rest are counted and dropped. Ordinary visitors are never stored.

Can a block apply to one hostname only? +

No. A Fastly ACL holds addresses only, and your VCL decides where it is consulted, so a block applies everywhere that service consults the ACL. WebDecoy says so next to every block.

Where do I find my Fastly ACL ID? +

You do not need it. Fastly's dashboard shows ACL names, not IDs, so WebDecoy asks for the name and looks up the ID with your API token when you save.

Want to see WebDecoy in action?

Get a personalized demo from our team.

Request Demo