Webflow may block or limit proxied requests if they appear suspicious or violate usage policies, particularly when using a reverse proxy. Here's how and why this happens.
1. Webflow’s CDN and Security Features
- Webflow uses Cloudflare as its underlying CDN and security layer, which includes bot mitigation, IP reputation analysis, and rate limiting.
- If your reverse proxy modifies headers or masks identifying information (like the original IP), Cloudflare might flag the request as suspicious.
- Abnormal user agents, missing headers, or rate spikes are typical reasons Cloudflare may block or challenge proxied requests.
2. Reverse Proxy Setup Risks
- If your proxy passes traffic without preserving certain headers (such as X-Forwarded-For), Webflow’s backend (via Cloudflare) might block or rate-limit the traffic.
- Caching and cookies may not behave as expected if your proxy strips or modifies origin request data.
- Requests like POST submissions, account logins, or CMS interactions are more likely to be rejected than GET requests to static content.
3. Known Limitations by Webflow
- Webflow does not officially support being behind a reverse proxy or being proxied to non-Webflow URLs.
- Some responses or features—like form submissions, site search, or CMS API access—may fail or be blocked entirely under proxy configurations.
- Webflow's terms prohibit scraping, mass automation, or abuse of their CDN through indirect means like misconfigured proxies.
4. Proxy Best Practices (if necessary)
- Ensure your proxy passes through all standard headers, especially Host and X-Forwarded-For.
- Slow the request rate, and mimic human-like patterns if testing performance or workflows.
- Avoid attempting to manipulate or rewrite internal Webflow routes, CMS URLs, or assets, as doing so can trigger security defenses.
Summary
Webflow may block reverse-proxied requests depending on how they’re structured. This is primarily due to CDN-level protections with Cloudflare. For reliable performance, it's recommended to use Webflow as a front-facing site directly or handle integrations through APIs, not reverse proxies.