In short. Kinsta documents Bot Protection as incompatible with a reverse proxy setup because the original traffic source cannot be reliably identified.
Definition: Kinsta documents that its Bot Protection cannot be used with a third-party platform, another CDN, or a reverse proxy setup because the original source of the traffic cannot be reliably identified. Kinsta documents a narrower Cloudflare arrangement in which Cloudflare may run first when its WAF and bot protection features are disabled.
Key facts
- Kinsta lists AWS, Microsoft Azure, Sucuri, Fortinet, another CDN, and a reverse proxy setup among the third-party arrangements that its Bot Protection cannot use, according to its Bot Protection documentation.
- Kinsta gives source identification as the reason: the system cannot reliably identify the original traffic source and determine whether a request is automated or human.
- Cloudflare may run alongside Kinsta Bot Protection when Cloudflare's WAF and bot protection features are disabled.
- When both layers are enabled in that arrangement, Cloudflare evaluates traffic first, and Kinsta evaluates only traffic that passes through Cloudflare.
- Kinsta warns that additional custom bot protection layers can produce conflicting classifications and disrupt access.
Why does the source matter?
Kinsta's Bot Protection documentation lists a reverse proxy as an incompatible setup alongside third-party platforms and another CDN. Its stated reason is source identification: after traffic passes through an external layer, Kinsta says the original source cannot be reliably identified well enough to determine whether the request is automated or human. The documented restriction applies to the Bot Protection feature, so it answers a narrower question than whether a Kinsta-hosted site can have a reverse proxy for another purpose.
The same documentation describes Bot Protection as traffic classification based on behavior. It distinguishes confirmed automated requests from traffic that is only likely to be automated. This classification model explains why the page focuses on the original traffic source when it lists proxy and security-layer restrictions.
What is the Cloudflare arrangement?
Kinsta documents Cloudflare as an allowed arrangement under a condition: Cloudflare's WAF and bot protection features must remain disabled. In that configuration, Cloudflare evaluates traffic first. Requests blocked at that layer never reach Kinsta, and Kinsta Bot Protection applies only to requests that pass through Cloudflare.
Kinsta also advises against adding custom bot protection rules alongside its own feature. The documentation says that multiple bot protection layers can classify legitimate traffic differently, causing it to be flagged and blocked. It says this can disrupt normal traffic or prevent access to the site.
How does Kinsta describe a reverse proxy?
Kinsta's separate Reverse Proxy documentation defines a reverse proxy as a layer between web browsers and backend servers that forwards client requests to servers and returns the servers' responses. It describes a use case in which a main site displays a Kinsta-hosted subsite under the same domain, including when the main site is hosted elsewhere.
That page also says that the Kinsta support team requires the real IP of the server to configure a proxied Kinsta site so visits count correctly. This is routing and hosting guidance. The Bot Protection page separately lists a reverse proxy setup as incompatible with Bot Protection, so the supported reverse proxy use case does not supply a documented Bot Protection exception.
What can you check in MyKinsta?
For a site using Bot Protection, the relevant controls are under the site's Bot protection screen:
Sites > sitename > Bot protection
Kinsta documents exceptions for specific IP addresses, paths, user agents, or countries. An exception can allow, challenge, or block matching access regardless of the selected Bot Protection level. If a plugin, integration, or API is affected, Kinsta directs site owners to enable Allow typical WordPress automations or add a custom exception in Exceptions. These are controls inside Kinsta's layer; the documentation gives no source-identification method that permits Bot Protection behind an external reverse proxy.
Related terms
- How does Kinsta classify AI crawlers separately from other verified bots?
- How can Kinsta bot protection allow a needed WordPress automation?
- Does Kinsta's Likely bots label automatically exclude visits from plan usage?
FAQ
Can you use Kinsta Bot Protection behind Cloudflare?
Kinsta documents a Cloudflare arrangement in which Cloudflare runs first and Kinsta Bot Protection handles traffic that passes through. Cloudflare's WAF and bot protection features must be disabled for this arrangement.
Can you use Kinsta Bot Protection behind AWS or another CDN?
Kinsta lists AWS, Microsoft Azure, Sucuri, Fortinet, another CDN, and a reverse proxy setup among the arrangements that cannot be used with its Bot Protection. The stated issue is reliable identification of the original traffic source.
What can you do if a WordPress integration is challenged?
Kinsta documents Allow typical WordPress automations and custom exceptions as the controls for plugins, integrations, or API functionality affected by Bot Protection. Exceptions can target an IP address, path, user agent, or country.
Sources
Check how a page reads to answer engines. Open the GEO score analyzer