Subfolder proxy with Cloudflare Workers

A Cloudflare Worker can send visitor requests for a subfolder directly to Clonable. This works for any type of website and does not depend on WordPress or access to your NGINX or Apache configuration.

This setup is an alternative to a subfolder proxy on your web server or through the Clonable WordPress plugin. Cloudflare handles forwarding, so your own server no longer needs to process an extra request to do this.

How does it work?

Visitor → Cloudflare Worker → Clonable → original website

Clonable fetches the original content when needed. Your server no longer has to forward the visitor's request to Clonable and wait for the response. For WordPress, this removes the extra PHP-worker used for forwarding. Caching and page contents determine how many requests Clonable ultimately makes to your original website; this does not guarantee exactly one connection for an entire page load.

What do you need?

• A subfolder clone in Clonable, configured with the correct public hostname and subfolder.
• An active domain in Cloudflare and access to DNS, Workers and Worker routes.
• A DNS record for the public hostname proxied through Cloudflare (orange cloud).
• An origin Clonable can reach without routing the request back to the clone.

In this example, example.org is the root domain, www.example.org is the public hostname and /fr/ is the clone's subfolder. Replace these values with your own details.

1. Add a CNAME record

Select your domain in Cloudflare and go to DNS → Records. Add this record:

Setting	Value in this example
Type	CNAME
Name	clonable-origin
Target	lb.clonable.net
TTL	Auto

This points clonable-origin.example.org to Clonable. For your own domain, use clonable-origin. followed by your root domain, without www..

This is a separate record for the Worker. Keep the existing DNS records for your original website pointing to your own server.

2. Create a Worker

In Cloudflare, go to Workers & Pages, create a Worker and give it a recognisable name, such as clonable-subfolder-proxy. Open the code editor, replace the example code with the code below, then save and deploy the Worker.

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.hostname !== "www.example.org" || !url.pathname.startsWith("/fr/")) {
      return fetch(request);
    }

    return fetch(request, {
      redirect: "manual",
      cache: "no-store",
      cf: {
        resolveOverride: "clonable-origin.example.org",
      },
    });
  },
};

Update these values:

• www.example.org: your clone's exact public hostname, including www. if used.
• /fr/: your clone's subfolder, including the trailing slash.
• clonable-origin.example.org: the hostname of the CNAME record from step 1.

The Worker preserves the public URL, Host header, full subfolder path, query string, HTTP method and request body. resolveOverride only changes the connection destination. The public hostname and override hostname must be within the same Cloudflare zone. A CNAME in your own zone lets you point to lb.clonable.net while keeping the public hostname. See Cloudflare's resolveOverride documentation.

With redirect: "manual", redirects are returned to the browser. With cache: "no-store", this fetch does not use Cloudflare's cache for the response. This does not disable caching in Clonable or on your original website.

3. Add a Worker route

Open your Worker and find its routing settings under Domains or Settings → Domains & Routes. Add a Route, select the example.org zone and assign this pattern to your Worker:

www.example.org/fr/*

Replace the hostname and subfolder with the same values used in your code. Use a route for the subfolder; a Worker Custom Domain is intended for an entire hostname.

The route handles /fr/ and all paths below it, including query parameters. /fr without the trailing slash falls outside this pattern. Set up a redirect from /fr to /fr/, for example with a Cloudflare Redirect Rule, preserving the query string.

For each additional subfolder, add a matching route and update the check in the Worker. Avoid a route for the entire website when only the subfolder should go to Clonable. See Cloudflare's Worker routes documentation.

4. Check Clonable and your existing proxy

In Clonable, select Cloudflare under the clone's Clone Settings → Proxy settings and click Save Proxy. Follow the Cloudflare setup for SSL/TLS configuration. For Full (strict), install the origin certificate first as explained there.

Clonable must still be able to fetch the original content. Original URLs should fall outside the clone's route. If your existing setup fetches original content inside the same subfolder, adapt the routing before using this simple Worker. You must also carry over existing subfolder exclusions in the routing or Worker; the example forwards every request within /fr/ to Clonable.

Using WordPress? Disable Enable subfolder service in the Clonable plugin when the Worker route becomes active and takes over forwarding. You can keep the plugin for language tags and the language switcher. See the steps to disable the subfolder service.

Already using an NGINX or Apache proxy? Coordinate the switch so there is one working handler for the subfolder. This Worker does not require new proxy rules on your web server.

Costs and limits

The Cloudflare Workers Free plan has a limit of 100,000 requests per day, shared across the Workers in your account. It resets daily at 00:00 UTC. These are Worker requests, not visitors: a page can generate multiple requests. Above the limit, the route may bypass the Worker or return an error, depending on its fail mode. Make sure the limit and chosen behaviour suit your traffic. See the current Cloudflare Workers limits.

Check that everything works

1. Open the clone at its public URL, such as https://www.example.org/fr/. A workers.dev URL does not pass the hostname check in the example code.
2. Test /fr, /fr/, a translated subpage and a URL with query parameters.
3. Check that the original website outside /fr/ still works normally.
4. Test redirects, static files, cookies, forms and any cart and checkout pages. Also check excluded paths.
5. Check the Worker logs to confirm the route runs and look for errors. On your own server, verify that it supplies original content to Clonable and no longer needs to forward visitor requests for the clone.

If the clone does not work, check that the public hostname is proxied through Cloudflare, that the route and code use the same hostname and subfolder, that the CNAME record exists in the same zone, and that Clonable can reach the original website. For TLS errors, also check the settings in the Cloudflare setup.

To return to your previous configuration, restore the existing subfolder proxy or plugin service first, then remove the Worker route. Contact Clonable if you need help, including the domain, subfolder and any Worker error messages.