Skip to main content

Advanced Subfolder Proxy

For experienced administrators only

Only make these changes if you have experience with web server configuration, reverse proxies and HTTPS. An incorrect configuration can make your website or clones unavailable. If you are unfamiliar with this, ask your hosting provider or server administrator to configure it for you.

The Clonable WordPress plugin normally handles subfolder clones automatically. You do not need to configure a proxy yourself.

For busy websites, this approach can create extra load. Want to reduce that load? You can let your web server handle the subfolder directly. This page explains how it works and what you need to configure.

How does the standard setup work?​

When a visitor opens a subfolder such as website.com/nl/, WordPress loads first. The plugin recognises the subfolder and uses cURL to fetch the translated page from Clonable. Clonable then fetches the original page when it is needed for the translation.

For an uncached request, the flow looks like this:

Visitor → website.com/nl/ → WordPress → Clonable plugin
        → Clonable → original WordPress page → translated page

This requires two PHP workers at the same time: one to forward the request and wait for the response, and one to generate the original page. A PHP worker is a process on your server that handles PHP requests. WordPress therefore also loads twice.

With many simultaneous visitors, all available workers can become occupied. New requests then have to wait, slowing down the website. Caching can reduce this, but does not remove the cause.

What does an external subfolder proxy do?​

A subfolder proxy on your web server forwards the request to Clonable before WordPress loads.

Visitor → website.com/nl/ → web server → Clonable
        → original WordPress page → translated page

The extra PHP worker for forwarding is no longer needed. Only generating the original page still requires WordPress when that page cannot be served from a cache.

You can also reduce the load by caching full pages for longer. However, changes may not become visible until the cache expires or is cleared. For websites where performance and up-to-date content matter, we recommend handling the subfolder outside WordPress. This does not require an additional cache layer. Existing caches still affect how quickly changes become visible.

What do you need?​

For this setup, you need:

  • A working subfolder clone in Clonable, including HTTPS.
  • Access to the NGINX or Apache configuration, or a hosting provider that can change it for you.
  • A staging environment to check the configuration before using it on your live website.

Not every WordPress hosting provider allows custom proxy rules. Check what your hosting plan supports first.

Keep the WordPress plugin

You can continue using the plugin for features such as language tags and the language switcher. When switching over, disable only Enable subfolder service, as described below. The plugin itself stays active.

Recognising requests from Clonable​

Clonable must still be able to fetch the original page. This request must not be forwarded back to Clonable, otherwise a loop will occur.

The examples below use the Clonable-Request-ID header for this. Requests without this header go to Clonable. Requests with this header follow the existing handling for the original website. The header is used for routing, not authentication.

When forwarding requests, preserve the public hostname, full subfolder path, query string, HTTP method and request body. Keep existing subfolder exclusions in place too.

NGINX configuration​

Add the following location blocks to your website's existing HTTPS server block. The proxy connects directly to lb.clonable.net, so you do not need to add a separate upstream block. Keep the existing PHP handler.

What do you need to change?​

  • /nl/ and /nl → replace these with your clone's subfolder.
  • website.com → replace this with your website's hostname, including www. if you use it.
Your configuration may differ

This example assumes a standard WordPress installation where index.php handles page requests. Does NGINX forward requests to Apache, or does your hosting provider use a different setup? Have the try_files line in particular adapted to the existing configuration.

location = /nl {
    return 308 /nl/$is_args$args;
}

location ^~ /nl/ {
    # Forward visitor requests before PHP starts.
    if ($http_clonable_request_id = "") {
        rewrite ^(.*)$ /clonable$1 last;
    }

    # Requests for original content follow the existing WordPress configuration.
    try_files $uri $uri/ /index.php$is_args$args;
}

location ^~ /clonable/ {
    internal; # Prevent direct external access.
    rewrite ^/clonable(.*) $1 break; # Remove the internal prefix.

    # SNI and the public hostname.
    proxy_ssl_server_name on;
    proxy_ssl_name website.com;
    proxy_set_header Host website.com;
    # Use HTTP/1.1 for the proxy connection.
    proxy_http_version 1.1;
    # TLS protocols for the connection to Clonable.
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
    proxy_pass https://lb.clonable.net;
    # Increase the buffers for responses from Clonable.
    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
}

How does this configuration work?​

The first location block redirects /nl to /nl/. The second block internally rewrites visitor requests to /clonable/nl/.... The browser continues to use the original address. No additional HTTP status code is needed for this internal rewrite.

The /clonable/ location removes the internal prefix and forwards the request to lb.clonable.net. The subfolder and query string are preserved. The internal; directive prevents visitors from accessing this location directly. The HTTP Host header and TLS server name identify the website the request is intended for. Keep proxy_pass https://lb.clonable.net; without a trailing slash and do not replace this address with your own domain: that normally points back to your own server.

For WordPress, we use ^~ on both prefix locations. This gives them priority over regular-expression locations, such as existing PHP and static-file rules. Check how these files are handled within your subfolder too. Repeat the subfolder blocks for each clone; the /clonable/ location can be shared within the same server block.

Additional hosting settings​

Ask your hosting provider to check which settings are inherited from the existing configuration:

  • Caching: if you do not want a proxy cache here, add proxy_cache off; if caching is configured at a higher level.
  • Certificate verification: SNI sets the server name, but does not enable certificate verification. We recommend proxy_ssl_verify on;, together with proxy_ssl_trusted_certificate and the correct CA bundle path provided by your hosting provider.

For more information, see the NGINX proxy module documentation.

Apache configuration​

Using Apache? You can also handle the subfolder outside WordPress. For the best performance, we recommend placing the proxy in your website's virtual host configuration. Your hosting provider can configure connection reuse there too.

Can this be done through .htaccess?​

Yes, a RewriteRule with the [P] flag lets Apache forward a request without loading WordPress. However, adding a rule to .htaccess alone is not enough: your hosting provider must first enable the required proxy features.

By default, [P] also uses a proxy worker without connection pooling. Connections are therefore not reused through a pool. Additional server configuration is needed for optimal performance. See the Apache proxy flag documentation.

What must your hosting provider configure?​

Ask your hosting provider to check the following:

  • Enable mod_rewrite, mod_proxy, mod_proxy_http and mod_ssl.
  • Allow rewrite rules in .htaccess through AllowOverride FileInfo or an equivalent list of permitted directives.
  • Enable SSLProxyEngine On and upstream certificate verification in the server configuration.
  • Set ProxyPreserveHost On for the website and keep ProxyRequests Off.
  • Confirm the upstream HTTPS hostname with Clonable. The upstream is the server Apache forwards the request to.

Apache determines the TLS server name from the proxy target. Preserving the HTTP Host header alone therefore does not produce the same TLS configuration as the NGINX example.

Adding the proxy rule​

Once the server configuration is ready, you can add the following pattern to the .htaccess file in your WordPress root directory. Place it above and outside the generated BEGIN WordPress block, so WordPress does not overwrite it.

Replace nl with your clone's subfolder and CLONABLE_UPSTREAM_HOST with the HTTPS endpoint your hosting provider has agreed with Clonable. This endpoint must point to Clonable and support the correct TLS configuration and routing for your public hostname. The example cannot be used as-is without these changes.

# Place this above and outside the generated BEGIN WordPress block.
RewriteEngine On
RewriteCond %{HTTP:Clonable-Request-ID} ^$
RewriteRule ^(nl(?:/.*)?)$ https://CLONABLE_UPSTREAM_HOST/$1 [P,L]

This rule matches /nl and /nl/..., but not /nl-other. In .htaccess, the path being matched has no leading slash. The query string is preserved. Requests with the Clonable header continue through the existing WordPress rules.

Ask your hosting provider to check redirects too and configure ProxyPassReverse where needed. This prevents visitors from being redirected to an upstream address. Place the server settings in the virtual host configuration, not in .htaccess.

For more information, see the Apache proxy settings and HTTPS proxy settings.

Disabling the subfolder service in WordPress​

When your web server handles the subfolder proxy, you must disable the subfolder service in the Clonable plugin. This lets the web server take over forwarding requests to Clonable from the plugin.

  1. Open Clonable in the WordPress admin area.
  2. Go to the Settings tab.
  3. Under Miscellaneous settings, uncheck Enable subfolder service.
  4. Save the settings.
Part of the switchover

Only disable this service when the web server proxy configuration is ready and being activated. Without either the plugin service or a working web server proxy, your subfolder clones will not be accessible as intended. This step applies to both NGINX and Apache.

Checking that everything works​

Have your hosting provider validate and reload the configuration. Check that Enable subfolder service is disabled and the change has been saved. Then check the following:

  1. Open /nl, /nl/, a translated subpage and a URL with query parameters. Check that the correct translation appears and no redirect loop occurs. You can inspect Clonable response headers in the Network tab of your browser's developer tools.
  2. Test the original website, WordPress admin area, static files and excluded paths. Using WooCommerce? Test the cart, checkout and forms too.
  3. Check that redirects and cookies use the correct public domain and paths. Also test URLs containing spaces or accented characters.
  4. Have your hosting provider check the server and PHP logs to confirm that visitor requests for the subfolder are forwarded before PHP starts. Only fetching the original page should load WordPress when needed.
  5. Change content on the original website and check that the change becomes visible as expected with your cache settings. Also compare response times and PHP worker usage under a similar load.

Using a CDN or another cache in front of WordPress? Ask your hosting provider to keep translated responses and requests for original content separate in the cache rules.

Keep the previous server configuration so you can revert the proxy rules if something goes wrong. Switching back to handling requests through the plugin? Re-enable Enable subfolder service and save the settings too. If you and your hosting provider need help, contact us with the domain, subfolder and any error messages from the server logs.

Last updated on