Share
Explore

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. We do reverse-proxy work for our clients and while this is part of our documentation on the technical side, we also have extensive consultation sessions with them about the pros and cons of reverse-proxy for their website, along with how using Webflow to reverse proxy may create complications in the future in terms of site management, SEO implications, etc. If you’re looking to get reverse proxy going for your company or talk more about it, feel free to email us at and we’ll get back to you. ⚡️
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 proxy-ssl.webflow.com as your CNAME values, use proxy.webflow.com 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 webflow.io 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 proxy.domain.com or project.domain.com. Again, for this project you’ll want to make sure and turn SSL off and use proxy.webflow.com 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 domain.com and you’re adding a blog at domain.com/blog you’ll want your canonical tag to be https://domain.com/blog.
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 https://domain.com/blog. 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="https://domain.com/blog" />
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.
image.png
Add a worker in your Cloudflare dashboard
In your Cloudflare dashboard, click on Workers in the sidebar:
image.png
Once you’re on the Workers page, click on the Create a Worker button.
image.png
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 => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
// new URL object to play with,
// based on the one being requested.
// e.g. https://domain.com/blog/page
var url = new URL(request.url)
// set hostname to the place we're proxying requests from
url.hostname = "blog.domain.com"

// 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 blog.domain.com 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 domain.com/blog*. 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 domain.com and see your main dot com site load secure as usual. And, if you head over to domain.com/blog 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 (
CtrlP
) instead.