Bot Management

Acest conținut nu este încă disponibil în limba selectată.

Bot Management tells people from scripts on your site and decides what each visitor gets: let through, challenged or blocked. It scores every visitor from the browser’s own signals, challenges the pages you pick with a proof-of-work the browser solves on its own, lets verified search bots in and stops impostors, AI crawlers and scanners.

Turn it on

Bot Management runs in the connector, so it works the same way on each one, with two exceptions:

Connector	What works
Qlyne proxy	Everything on this page
Hosted by Qlyne	Everything on this page
Cloudflare Worker	Everything except impostor detection and the challenge for browsers that never ran the script. The TLS fingerprint needs Cloudflare’s own Bot Management (Enterprise).

The captcha for any form works on any site, with or without a connector.

Connect the site (Choose the integration).
Open the site and go to Bot Management › Configuration.
Pick a protection level, then fine-tune under Advanced if you need to.
Leave Connector › Configuration, “Mode”, on “Observe only” for a day or two, then switch to “Enforce”.

Changes reach the connector within a minute.

Protection levels

The level at the top of Bot Management › Configuration fills the settings under Advanced and saves them. Change any of them by hand and the level shows as “Custom”.

Setting	Basic	Balanced	Aggressive
Difficulty	3	4	5
Click to confirm	Never	Never	When in doubt
Score visitors	off	on	on
Medium score, 30 to 59	Nothing	Nothing	Challenge
High score, 60 and up	Nothing	Challenge	Block
AI crawlers	none	training	training and AI search
Trap paths	none	secrets, admin tools	secrets, admin tools
Block for (trap)	1 hour	1 hour	24 hours

Tor and shared reputation are set by the level of WAF & Firewall: Basic leaves Tor alone and only warns your app about listed addresses; Balanced challenges both; Aggressive blocks both.

A level never touches what is specific to your site: challenged routes, routes that need the score, the decoy page, your own trap paths, the clearance time, “Challenge browsers that never ran the script” and under attack mode.

“Use the recommended set”, next to Save rules, turns on the trap for secrets and admin tools and blocks AI training crawlers. On Pro it also challenges /checkout*, /login and /signup (if you have no challenged routes yet), turns on the score and challenges high scores.

On Free, the Pro settings a level fills are saved and apply as soon as the account is on Pro.

Settings

Everything below is under Bot Management › Configuration, Advanced, except Tor and shared reputation, which live under WAF & Firewall › Configuration.

Challenge (Pro)

A proof-of-work the browser solves before the page opens. A person sees a short “Checking your browser” page that moves on by itself; a script has to do the work or stop there.

“Challenged routes”: pages bots go after, like /checkout*, /login, /signup. * at the end covers everything below it.
“Difficulty”, 1 to 6: each step multiplies the work by 16. At 4 it takes about a second on a phone; at 5, up to 15 seconds. This is the starting point: it goes up under attack mode and for an address that asks for many challenges in 10 minutes.
“Clearance, minutes”, 5 to 1440 (30 by default): how long a solved challenge lasts. The clearance is a cookie, qlyne_clr, tied to the IP (the /64 for IPv6) and the browser.
“Click to confirm”: “Never” (the browser does the work alone), “When in doubt” (a click on “I’m a person” only when the score is not low or the address asked for many challenges) or “Always”. It also sets how the form captcha behaves. A click fired by a script, or on a computer without the pointer moving first, is refused.

A browser driven by Selenium, Puppeteer or Playwright, as they come, does not get the clearance. A client that copies a browser’s user agent without the headers that browser always sends over HTTPS is refused too.

The “Under attack” button at the top of the page challenges every page view without a clearance cookie. API calls are not challenged, so apps and integrations keep working.

Bot score

With “Score visitors” on, the connector adds a small script, /__qlyne/s.js, to your HTML pages, served from your own domain.

A few seconds after the page opens, after a click or a key, and when the visitor sends a form or leaves, the script posts a summary to /__qlyne/s. The summary says whether the browser reports being automated, how many languages, plugins, processor cores and touch points it reports, the screen size and whether it has a time zone. It also counts how many times the pointer moved, the visitor clicked, typed, scrolled or touched, and how many of those events a script fired. It sends counts only: never keys, text or where the pointer was.

From that summary, and from whether the request headers match the browser named in the user agent, the connector gives a score from 0 to 100. Below 30 is low, 30 to 59 medium, 60 and up high. The score stays 30 minutes in the qlyne_bs cookie, encrypted and tied to the IP and the browser, so the visitor cannot read or change it.

Your app gets the score in Qlyne-Bot-Score, with the reasons in Qlyne-Bot-Reasons (like automation,no_interaction). This part works on Free.

On Pro, choose what a medium and a high score get:

“Nothing, only tell my app”;
“Slow down by 3 seconds”;
“Challenge”, or “Challenge with a click”;
“Block”, a 403;
“Show the decoy page”: a page of your site the bot gets in place of the one it asked for, under the same address. It keeps scraping something worth nothing. Fill in “Decoy page” with its path.

“Routes that need the score” (Pro) refuse a form or API call (anything but GET) from a browser that has not run the script, with 403 and {"code": "SENSOR_REQUIRED"}. Use it on what bots call directly, like a checkout or signup API. A visitor with a solved challenge goes through.

“Challenge browsers that never ran the script” (Pro; Qlyne proxy and hosted only): a browser opening a page without ever running the script, or solving a challenge, gets the invisible challenge. A real browser solves it and goes on; curl and headless tools stop there. Static files, API calls and verified bots are left out.

Verified bots and impostors

Googlebot and Bingbot are recognised by the IP ranges Google and Microsoft publish, which Qlyne keeps up to date for every account. A verified bot skips the challenge (on any route, under attack mode included), the scanner trap and blocking by shared reputation. Your app gets Qlyne-Verified-Bot with googlebot or bingbot.

On the Qlyne proxy and hosted, a request whose user agent says Googlebot or Bingbot but comes from outside those ranges is blocked as an impostor. This needs no setting and works on Free.

The ChatGPT agent browses with a Chrome user agent, so it can’t be told apart by name or IP. It signs every request instead (HTTP Message Signatures, the Web Bot Auth protocol), and on the Qlyne proxy and hosted that signature is checked against the key OpenAI publishes, which Qlyne fetches for every account. A valid signature gets the same treatment as a verified bot, with Qlyne-Verified-Bot: chatgpt-agent; if you block AI assistants, the signed agent is blocked with them. A request that claims to be the ChatGPT agent with no signature, or with a signature that doesn’t match OpenAI’s key, is blocked as an impostor. A signature made with a key id Qlyne doesn’t know passes without the label and follows your other settings. If Qlyne doesn’t have a current key, nothing is blocked for a signature and the request goes through your other settings.

AI crawlers

Pick the categories to block:

“Crawlers that train AI models”: GPTBot, ClaudeBot, CCBot, Bytespider and others.
“AI search crawlers”: OAI-SearchBot, Claude-SearchBot, PerplexityBot. Your pages stop showing up as sources in those answers.
“AI assistants opening a page for a user”: ChatGPT-User, Claude-User, Perplexity-User.

A blocked crawler gets a 403. Your /robots.txt is served with a Disallow: / group for those crawlers added at the end. Google and Bing search are not affected.

On the Cloudflare Worker, the connector has to run on your whole site (a route like example.com/*), robots.txt included.

Scanner trap

Scanners ask for paths no visitor does: /.env, /.git/config, /phpmyadmin, /wp-login.php on a site without WordPress. Under “Trap paths”, pick the groups:

“Secrets and source files”: /.env, /.git, /.aws, backups and database dumps.
“Admin tools you do not run”: phpMyAdmin, Adminer, cgi-bin, PHPUnit and router exploits.
“WordPress paths”: /wp-login.php, /wp-admin, /xmlrpc.php. Leave it off if your site runs WordPress.

Add your own under “Your own trap paths”, like an old admin address or a link only bots follow. Whoever requests one gets a plain 404, with no hint it was a trap. Then they are blocked on every route for the time in “Block for”: 15 minutes, 1 hour or 24 hours. An IPv6 visitor is blocked by its /64.

The connector that caught it blocks at once; other Workers or proxies of the site learn within a minute. Googlebot, Bingbot and trusted addresses are never caught. Bot Management › Overview lists the addresses held by the trap and when each one is released.

Tor exit nodes (Pro)

Under WAF & Firewall › Configuration, “IP addresses”, “Tor exit nodes” takes the Tor Project’s public list, refreshed every hour. “Challenge every page view” or “Block”; API calls are not challenged.

Shared reputation

Under WAF & Firewall › Configuration, “Shared reputation” lists the addresses that sites of other Qlyne accounts saw attacking in the last 24 hours. That means caught by the scanner trap or the managed rules, with a high bot score, driving an automated browser or refused by the form captcha. An address goes on the list only when at least two accounts report it, so no single account can put someone there. For IPv6 the list holds the /64.

“What a listed address gets”:

“Nothing”;
“Warn app” (the default, on Free too): your app gets Qlyne-Reputation: 1;
“Challenge” (Pro): its page views get the challenge; API calls go through;
“Block” (Pro): 403. Googlebot and Bingbot are never blocked by it.

Trusted addresses skip it. “Report attacks on this site” (on by default) puts the address of those attacks on the shared list. For 24 hours the list keeps the address and your account’s id, which is how it counts how many accounts reported it. It never keeps the path, the user agent or which site it was. Turning it off does not stop you from using the list. How this data is handled is in the terms and the privacy policy.

TLS fingerprint (JA4)

When a connection opens, the browser lists the TLS versions, ciphers and extensions it supports. That list, summarized as a JA4 fingerprint like t13d1516h2_8daaf6152771_d8a2da3f94cd, depends on the program and not on the user agent it claims. A script that copies Chrome’s user agent still connects like a script.

There is no setting. When the connector has the fingerprint, your app gets Qlyne-JA4, Events shows it next to the user agent, and your own rules can use it. The bot score adds tls when the user agent claims a recent Chrome, Firefox or Safari but the connection does not use TLS 1.3 or offer HTTP/2. A company proxy that inspects HTTPS also changes the fingerprint, so this only raises the score to medium and never blocks on its own.

Hosted has the fingerprint for every visitor. The Qlyne proxy has it when HTTPS ends at the proxy: see TLS fingerprint on the proxy page. On Cloudflare it needs Cloudflare’s own Bot Management, an Enterprise plan.

Captcha for any form

For forms on a site without a connector, or on a page you do not want to challenge as a whole. The browser solves a short proof-of-work, no puzzle, and the form carries a token your server checks once. Setup and code: Captcha for any form.

What visitors see

The pages come in English or Portuguese, by the visitor’s browser language. A request that does not ask for HTML (an API call) gets JSON with the same status.

Challenge: a 403 page titled “Checking your browser”, with “This takes a few seconds. The page opens on its own.” The page opens by itself once the browser has done the work. API calls get {"code": "CHALLENGE_REQUIRED"}.
Challenge with a click: “Confirm you’re a person”, with the “I’m a person” button.
Without JavaScript: both challenge pages say “Turn on JavaScript to continue to this page.”
Block (high score with “Block”, impostor, trap, shared reputation, Tor): a 403 page titled “Access blocked”, with “This site refused access from your connection. If you think this is a mistake, contact the site.” No rule, no IP, no mention of bots. API calls get {"code": "ACCESS_BLOCKED"}.
Scanner trap: a plain 404, “Not found”.
AI crawler: a plain 403.
“Slow down by 3 seconds”: the normal page, 3 seconds later.
Decoy: the decoy page, under the address that was asked for.

The challenge and block pages say “Protected by Qlyne” at the bottom.

Measured on the demo

On 2026-10-18, a run of six clients against demo.qlyne.com (hosted, with “Challenge browsers that never ran the script” on) gave:

Client	Result
Googlebot user agent from outside Google’s ranges	Blocked
Bingbot user agent from outside Microsoft’s ranges	Blocked
GPTBot	Blocked
Chrome user agent without the headers Chrome sends	Challenged
Recent Chrome user agent and headers, no JavaScript	Challenged
curl asking for anything but a page	Passed

Limits

The verified bot list is the same for every account: Googlebot and Bingbot, checked by IP range. You cannot add others. Other search engines (DuckDuckBot, Applebot, Yandex) are treated like any visitor, so a challenge on a page applies to them too.
The score needs the script. A first page view has no score yet, so the actions start with the next request. API clients and crawlers never run the script, so they never have a score.
The challenge makes bots pay; it does not stop a determined one. A real browser that hides the automation marks gets through after solving the proof-of-work.
AI crawlers are recognised by the user agent they declare. One that pretends to be a browser is treated as a browser and meets the other rules.
Verified bots skip the challenge, the trap and the reputation block, not everything. Your blocked IP list, rate limits and your own rules apply to them like anyone else.
Impostor detection and “Challenge browsers that never ran the script” are on the Qlyne proxy and hosted, not on the Cloudflare Worker.
Start in observe mode. The counts show what would have been challenged or blocked before anyone is turned away.

FAQ

Will it block Googlebot?

No, when it comes from Google. Googlebot and Bingbot from their published ranges skip the challenge, the trap and the reputation block, and your AI crawler choices do not touch Google or Bing search. What can still stop them is what you set yourself: a blocked IP, a rate limit or one of your rules. A request that only says it is Googlebot, from another network, is blocked on the Qlyne proxy and hosted.

What if the visitor has JavaScript turned off?

Pages without a challenge open as usual, and the visitor has no bot score. A challenged page asks to turn on JavaScript and does not open until they do. With “Challenge browsers that never ran the script” on, that applies to every page view, so leave it off if your audience needs pages without JavaScript.

How much latency does it add?

The connector decides from rules it keeps in memory and does not call Qlyne on each request. Measured on 2026-10-11, from the same server, the demo store answered through the Qlyne proxy in 3 ms at the median, and the challenge page in 2 ms. That leaves out the network between your visitor and your server. A person only waits on a challenged page, about a second on a phone at difficulty 4, and only once per clearance.

How do I see what was blocked?

Bot Management › Overview shows the counts for the period you pick (24 hours by default), the split of low, medium and high scores, and the addresses held by the trap. Events lists each decision with its reason, the score reasons in words, the user agent and the TLS fingerprint, and exports to CSV. In observe mode the same places show what would have happened. More in Events and reports.

Does it work on Free?

Part of it. On Free: the bot score sent to your app, verified bots, impostor detection, AI crawlers, the scanner trap, shared reputation as a warning to your app, the TLS fingerprint and the form captcha. Pro adds what challenges or blocks a visitor by judgement: the challenge and under attack mode, actions by score band, routes that need the score, the challenge for browsers without the script, Tor, and challenging or blocking listed addresses. Every new account starts with 7 days of Pro, no card. See Plans.

Troubleshooting

Everything is on and nothing gets blocked

Check “Mode” under Connector › Configuration. On “Observe only” the connector counts what it would do (“Would challenge”, “Would block”) and lets everyone through. Switch to “Enforce” when the counts make sense. If the site is on Free, the challenge, the score actions, Tor and the reputation actions are saved but do not apply; the page shows a “Free plan” notice. On the Basic level the score is off.

The challenge comes back on every page

The clearance cookie is tied to the IP and the browser, and it is Secure. Look for:

a site served over plain HTTP: the browser does not keep a Secure cookie, so the challenge never clears;
a visitor whose IP changes on every request, like some mobile networks, VPNs or company proxies with several exits;
a browser that blocks cookies for your site;
a test with Selenium, Puppeteer or Playwright, which never gets the clearance. Put the test machine’s address in the trusted list under WAF & Firewall › IP rules.

A search bot is being blocked

Open Events and find the request: the reason says which rule stopped it.

“Blocked a fake Googlebot, Bingbot or ChatGPT agent”: the request did not come from Google’s or Microsoft’s ranges, or claimed to be the ChatGPT agent without a valid signature. SEO tools often send Googlebot’s user agent, and that block is the intended result.
A blocked IP, a rate limit or one of your rules: verified bots are not exempt from those. Take the address off the blocked list under WAF & Firewall › IP rules. For a rate limit or a rule, on Pro, put a rule with “Verified search bot” “is yes” and “Let through, skip the other rules” at the top of your rules.
Another search engine (DuckDuckBot, Applebot): it is not on the verified list, so the challenge applies to it. Turn off “Challenge browsers that never ran the script”, or let it through by a rule on its user agent. Anyone can send that user agent, so the rule lets impostors of that crawler through too.