LiquidFiles Documentation
LiquidFiles Documentation
On This Page

Content Delivery Networks (CDN)

A CDN such as Cloudflare, Amazon CloudFront or Akamai is a globally distributed reverse proxy. LiquidFiles works behind a CDN, but it treats one exactly like any other reverse proxy — there is no CDN-specific integration and we make no claims of a partnership with any CDN provider. Everything in the Reverse Proxy documentation applies (set the Public URL, use HTTPS everywhere, and add the proxy as a Trusted Proxy), so please read that first.

This page covers the two things that are specific to a CDN and that catch most people out:

  • A CDN limits how large a single upload request can be, which clashes with the LiquidFiles upload chunk size.
  • Getting the real client IP address right — and doing it safely.
A CDN does not make LiquidFiles faster or more secure by default. As with any reverse proxy, the most likely outcome is that things work the same or slightly worse unless you configure the CDN carefully. See the Reverse Proxy security discussion for the background.

Upload Chunk Size

Most CDNs cap the size of a single request body they will forward to your origin. On Cloudflare this limit is 100 MB on the Free, Pro and Business plans (higher on Enterprise); Amazon CloudFront has a similar per-request limit. LiquidFiles uploads large files in resumable chunks, and the default chunk size is also 100 MB — so chunks land right on, or just over, the CDN limit and large uploads fail while small ones succeed.

The fix is to make each chunk smaller than the CDN limit. In LiquidFiles, go to Admin → Configuration → Settings → Advanced and set:

Upload Chunk Size — lower this below your CDN's per-request limit, for example 90 MB when the CDN limit is 100 MB. The valid range is 10 to 100 MB.

The chunk size is not the maximum file size your users can send — that is controlled separately by the group file size limit and quota. Lowering the chunk size only means large files are split into more, smaller pieces; files of any permitted size still transfer normally.

If uploads of large files fail behind a CDN while small files and the rest of the interface work fine, the chunk size hitting the CDN's request limit is by far the most likely cause.

Trusted Proxies & the Client IP

When LiquidFiles sits behind a CDN, every request arrives from the CDN, not from the end user. To recover the real client IP address, add the CDN's edge IP ranges to the Trusted Proxies setting in Admin → System → Network Setting. The field accepts individual addresses and CIDR ranges, separated by commas.

You can obtain the published ranges from the CDN provider:

If you do not configure this, LiquidFiles will record the CDN's address as the client IP for every request. That breaks anything that depends on the client IP, including group IP restrictions, the brute-force lockout (which would then lock out the CDN — that is, everyone), strong authentication IP exclusions, SAML auto-login networks, and your activity logs and geolocation, which will all show the CDN instead of the real user.

CDN edge ranges change over time, so this list has to be kept up to date. Before you add broad CDN ranges as Trusted Proxies, read the next section — trusting a CDN's shared ranges is only safe once your origin is locked to your own CDN account.

Locking the Origin to your CDN

A CDN's edge IP addresses are shared by every customer of that CDN. Listing those ranges as Trusted Proxies therefore means “trust anything that arrives through this CDN”. If your LiquidFiles origin is reachable from those ranges, an attacker can point their own CDN distribution at your origin and forge the X-Forwarded-For header to impersonate any client IP — bypassing IP restrictions and the brute-force lockout. Lock the origin to your own CDN before adding broad CDN ranges.

“Locking the origin” means making sure your LiquidFiles system can only be reached through your CDN distribution, not through the CDN's shared ranges in general. There are two layers, and you want both.

1. Network allow-list

Restrict the LiquidFiles firewall so it only accepts connections from the CDN's published ranges (Cloudflare's IP list, or the CloudFront origin-facing prefix list on AWS). This stops attackers connecting to your origin address directly. On its own it is necessary but not sufficient — it does not stop another customer's distribution on the same CDN, whose traffic also arrives from those shared ranges.

2. Bind the origin to your distribution

This is the part that actually closes the hole — prove that traffic genuinely came through your own CDN account:

  • Cloudflare Tunnel (recommended). Using cloudflared, the origin makes an outbound connection to Cloudflare. There is no public origin address and no inbound port to attack at all, which makes it both the simplest and the strongest option for an appliance.
  • Cloudflare Authenticated Origin Pulls (mTLS). Cloudflare presents a client certificate to your origin and the origin refuses connections without it. With a per-zone certificate, only your Cloudflare zone can connect — someone else's Cloudflare distribution cannot.
  • Amazon CloudFront. Have CloudFront add a secret custom header (for example X-Origin-Verify) that is validated before the request reaches LiquidFiles, combined with AWS WAF on the distribution and a firewall allow-list to the CloudFront origin-facing ranges. Because LiquidFiles decides trust by the connecting IP rather than by a header, the secret-header check needs to be enforced by a proxy in front of the appliance.

Once the origin only accepts traffic from your own distribution, the forwarded client IP can be trusted, and listing the CDN ranges as Trusted Proxies is safe.

When CDN Security Blocks LiquidFiles

CDNs include security features — Web Application Firewalls, managed rule sets, bot and rate protections. These can block legitimate LiquidFiles traffic, and the usual symptom is that LiquidFiles stops working immediately after a CDN security feature is enabled. We have seen CDN WAF rules block large uploads, the API, and specific application paths.

If LiquidFiles stops working after you enable a CDN security feature:

  • Disable the feature to confirm it is the cause.
  • Re-enable it selectively and allow-list the LiquidFiles behaviour it flagged — typically large request bodies (file uploads) and the API endpoints.
  • Test both upload and download with the CDN security enabled before going live.
LiquidFiles is a modern, hardened application that is designed to sit on the public Internet on its own — see the Reverse Proxy security discussion. We do not control or certify any specific CDN security configuration; tune it against your own LiquidFiles deployment.