icon picker
Guide: How to Reverse Proxy a Webflow project with Cloudflare Workers

A guide to using Cloudflare as a reverse proxy with multiple Webflow sites

👋 Hey! I’m Matt Varughese, CEO of
— A leading Webflow Enterprise agency serving amazing clients like , , , , , , and many more.

I worked on this guide to help a client of ours reverse proxy a couple of Webflow websites together. It wasn’t initially meant for the general public, but I’ve received countless messages saying that folks have stumbled upon this and successfully reverse-proxied their Webflow projects using this guide — and I’m glad to hear it! That being said, I advise you to use this guide at your own risk. Reverse-proxying a project can be complex as it creates infrastructure (hosting) management that you previously wouldn’t have if you just had a Webflow website stand on its own - which is the most reliable and bulletproof setup.

Configuring Webflow hosting and your DNS Records

In order to use Cloudflare as a reverse proxy you’ll need to make some changes to your DNS records and get your Webflow projects configured properly.
Since we’ll be using Cloudflare’s reverse proxy (keeping those clouds orange in Cloudflare which Webflow doesn’t officially support), you’ll want to make sure to head over to your project settings for your main dot com project in Webflow and turn SSL off.
Set up your domains to take advantage of CNAME flattening and set your naked domain as the default. Then, in Cloudflare instead of using as your CNAME values, use for both and make sure the clouds for these records are on and you’re using Cloudflare’s proxy.
⚠️ IMPORTANT This switch will cause Cloudflare to make a request to Let’s Encrypt (LE) to get a new SSL certificate setup. Webflow also uses LE for SSL certificates so you’ll want to use or the to make sure you aren’t going to hit the LE rate limit. If you do hit this rate limit you’re prevented from pulling a cert for a week.

Configuring the Webflow project settings of your secondary project

For the secondary project that you’ll be proxying to a directory of the main dot com project, you’ll need to set up some things there as well.
Webflow doesn’t allow you to proxy a site on the domain, so you’ll need to jump into your Dashboard and add a hosting plan for this project and add a custom domain you can proxy. Something like or Again, for this project you’ll want to make sure and turn SSL off and use for your CNAME. Make sure the orange cloud is on in Cloudflare and that you’re using their proxy for this domain.
Next head on over to the SEO tab in your secondary project settings and scroll to the bottom of the page and set your . For example, if your domain is and you’re adding a blog at you’ll want your canonical tag to be
Then, head over to the Custom Code tab of your secondary project settings. Scroll to the bottom and you’ll need to set your base tag. As in the example above, it’ll need to be You’ll also need to set your Href Prefix to /blog. Save the changes and publish the site.

Configuring the Webflow page settings of your secondary project

Once your project settings are configured, you’ll need to setup a snippet of code on each page that’s being reverse-proxied, so that Google knows which page is the original.
Let’s say we were working on a Blog Index page (a static page with CMS collections on it) that needs to live on
Head over to the Blog index page (the page in question) on your secondary project, click the Page Settings, and add the following line of code to your website:
<link rel="canonical" href="" />
This snippet of code will need to be added for every page that you have that’s being reverse-proxied. For CMS pages (like an individual blog page), you can dynamically choose the slug in the Custom Code settings, as seen below.

Add a worker in your Cloudflare dashboard

In your Cloudflare dashboard, click on Workers in the sidebar:
Once you’re on the Workers page, click on the Create a Worker button.
Name your new proxy by clicking on the name in the top left hand corner. Use site-proxy or whatever works for you. Next erase all the code in the box on the left, and replace it with the following code.
addEventListener('fetch', event => {
async function handleRequest(request) {
// new URL object to play with,
// based on the one being requested.
// e.g.
var url = new URL(request.url)
// set hostname to the place we're proxying requests from
url.hostname = ""

// remove the first occurence of /blog
// so it requests / of the proxy domain
url.pathname = url.pathname.replace('/blog', '')
// pass the modified url back to the request,
let response = await fetch(url, request)
return response;
You’ll want to replace with whatever subdomain you’re using for your secondary project. If all of the above DNS changes have fully propagated, then you should be able to see your blog from your secondary project loading in the preview on the right. You should be able to navigate without issue and see content loading. Or, if you’re in the HTTP tab you should be seeing 🟢 200 OK as your status.
If this is the case, you can hit the Save and Deploy button to deploy your code.
Now you need to bind this worker to your domain and setup your route. Go back to your Cloudflare dashboard and click on your domain, then click on the Workers icon in the top menu.
Click on the Add Route button and you’ll be presented with a modal. For the route you’ll need to add*. It’s important that the asterisk is there since it works as a wild card to match the incoming requests.
For the worker, select the name of the worker you just created. Click Save.
Now you should be able to head to and see your main dot com site load secure as usual. And, if you head over to you should see your blog being proxied and working as well. If you plan on having a shared navigation you’ll need to do some work to ensure all of the links work as expected.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.