Reverse Proxy and Custom Hosting

Before building anything, check whether a reverse proxy is really the right tool. It adds a server to operate, a source of subtle SEO faults and a path that Webflow’s support cannot debug end to end.

Most of the time one of the first rows applies. Reach for a proxy only when the subdirectory is a firm requirement.

The visitor never sees Webflow’s address. They request a URL on the main domain; the main domain’s web server (or load balancer) recognizes the /gardens/ prefix, forwards the request to the Webflow-published custom domain over HTTPS, and streams the answer back. Every other path stays with the original platform.

Three consequences follow from this picture and drive everything else on the page.

Webflow’s Help Center article on setting up a self-managed reverse proxy, together with the Href prefix setting in the site’s hosting settings, defines the supported arrangement. As of 2026-10-28 the official documentation establishes these points.

Two sentences in that table deserve emphasis. First, never proxy webflow.io: the staging domain is for review, it is not indexed, and its behaviour is not covered by the proxy documentation. Second, the supported arrangement is a proxy that the organization runs itself. Teams often assume that an edge worker on a CDN is just "a smaller reverse proxy"; Webflow’s documentation says that third-party proxy services are outside what it supports, so a problem found in such a setup is the customer’s to solve.

Because the proxy fetches the page from the custom domain over HTTPS, the TLS rules in Domains, Hosting and Publishing Options still apply to the Webflow side of the connection: the custom domain must be connected and its certificate issued before the proxy can reach it.

Without any configuration, a Webflow page at /roses contains links such as /visit and assets such as /css/site.css or an image on Webflow’s asset CDN. Served under /gardens/ through a proxy, a visitor who clicks /visit would leave the section and land on the main platform’s /visit page, which is not what the author meant.

The Href prefix setting solves exactly this. The site owner enters the subdirectory, for Fernbrook /gardens, and Webflow prefixes the generated internal links with it when the site is published. The result is a page that is correct when it is read from fernbrook.example/gardens/roses.

What the prefix affects, and what it does not, is the most common point of confusion.

The practical rule: after every change to the prefix, publish and then read the published HTML (View source) of one page of each type, a static page, a CMS template page and a 404, and check the links, the canonical tag and the og:url value.

Because the prefix is part of how Webflow renders links, it is a site-wide setting, so plan one subdirectory per Webflow site.

Fernbrook’s main platform is served by nginx. The Webflow site is published to the custom domain gardens-origin.fernbrook.example.com, which is connected in Webflow on a paid Site plan, and the Href prefix is set to /gardens. The proxy configuration below forwards every request whose path starts with /gardens/ to Webflow and leaves everything else to the in-house application.

Source: nginx: ngx_http_proxy_module

The directives that matter, and why each is there:

This listing is a starting point written for this page. The Webflow article is the reference for the exact header set and for how the path should be forwarded for your configuration; compare the two before going live, and test with curl -I against both the public path and the origin.

A quick check from a shell, with the query string intact:

Source: nginx: proxy_pass

A related and frequent question is whether the DNS provider may proxy the Webflow custom domain, for example with an orange-cloud record at a DNS host. That is a different layer from the proxy this page describes and is discussed in Domains, Hosting and Publishing Options.

A proxy that goes wrong is usually discovered in Search Console weeks later. The checklist below is what to inspect on every release.

Cookies set by the Webflow origin are scoped to the origin host unless the proxy rewrites them. For a read-only content section this rarely matters. It does matter for three features.

CMS item URLs follow the same rule as other links. The collection page for the garden guide, with the slug plants, produces item pages such as /gardens/plants/rosa-gallica once the prefix applies. Collection settings, template pages and the redirect rules for changed slugs are in Collection Template Pages. Assets uploaded to the Assets panel are served from Webflow’s asset CDN with their own URLs, as covered in Images and Assets; they do not go through the proxy, which also keeps the proxy’s bandwidth low.

The proxy is a public-facing server. The usual obligations apply.

Source: Webflow Help Center: Custom security headers

When the reason for the proxy is organizational control, such as serving the site from the company’s own cloud account, behind its own web application firewall or on its own CDN, the supported route is Webflow Custom Hosting, an Enterprise arrangement. The official FAQ describes it as a way for an Enterprise customer to host a Webflow site on infrastructure it controls; the contract and the FAQ define who is responsible for the certificate, caching, availability and security of that layer, and which Webflow features continue to work. Because a hand-built proxy is the customer’s responsibility and custom hosting is a product with a defined scope, teams that need more than a path mapping should talk to Webflow’s sales team before building their own.

Source: Webflow Help Center: Webflow custom hosting FAQs

The comparison below shows how the options differ.

The mirror image of the problem is also common: instead of putting a Webflow section under another platform, the organization wants an application under the Webflow domain. Webflow Cloud covers that case with mount paths. Each environment of a Webflow Cloud app gets a unique path under the site’s domain, so an application is reachable at, for example, www.fernbrook-gardens.example/planner, while the rest of the domain remains the Webflow site. The developer documentation notes that a mount path must be unique across all environments of an app, can be changed later and then needs a redeploy, and that if a Webflow Cloud route and a Webflow page use the same path, the Cloud app takes precedence. No proxy of your own is involved, because Webflow does the routing.

For Fernbrook, the Visit Planner is therefore mounted at /planner on the Webflow-hosted domain, whereas the garden guide under /gardens/ of the old platform needs the proxy. The two techniques solve opposite problems: a proxy places Webflow inside someone else’s domain, a mount path places someone else’s code inside Webflow’s domain. Details, build settings and environments are in Webflow Cloud and Webflow Cloud Deployments and Environments.

Source: Webflow Cloud: Environments and mount paths

A fourth route is to move the other platform’s sections to Webflow gradually, using 301 redirects and a staged migration, so that the proxy is temporary. That pattern is described in Redirects and Site Migration.

A proxy is permanent infrastructure, so give it the same care as any production service.

Older books and tutorials describe proxying Webflow through an edge worker, or pointing a proxy at the webflow.io address, because for years that was the only available workaround. The current documentation separates the supported self-managed proxy with the Href prefix from those workarounds, and states that third-party proxy services are not supported. Tutorials that predate the Href prefix also rewrite links with scripts after the page loads; that is unnecessary with the setting and harms crawlers, which read the HTML before any script runs. Treat such guides as history, as listed in Where Older Books and Tutorials Are Outdated.