[Bug] fileserver usage problems for caching/proxying

[FingerlessGlov3s]

Summary

I also noticed only the files.json requests get requested via the fileserver, which the request URI contains no hash, so it makes trying to cache the files a little tricky, since we could cache them but when they need to reach the stale point is a bit unknown, as changes to the resource could happen within 5 minutes of caching it for no changes for weeks. Legacy FXServer, used to have a hash in the request which changed as the resources were updated.

But currently that's a moot point because the actual resource downloads aren't using the fileserver either, it is able to retrieve the json files fine, just now the actual resources. Unless there's a new settings required to make this work.

set adhesive_cdnKey "iqpkZpcMW8LHqC51CAbpGisE3xVwRbB6keLvD"
fileserver_add ".*" "https://cache.domain.com/"

This is done to prevent the game server's network being maxed out while players are joining, which causes lag spikes and packetloss.

Issue type

Both / Unsure

Repro rate

Always

Server build version

FXServer-early-access b94 win32

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

None

OS version / distribution

No response

CPU

No response

RAM

No response

Using txAdmin?

None

Hosting provider

None

Machine type

None

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Configure Server.cfg
2. Configure say Nginx proxy as per https://docs.fivem.net/docs/server-manual/proxy-setup/ with caching
3. Connect to server and observe the nginx access log

Expected Behavior

Requests to contain a version hash of the resource. JSON and actual resource files to use the cache/proxy server

Actual Behavior

Only the files.json files are hitting the nginx service, and the actual resources themselves aren't. Plus no version key.

Evidence

No response

Additional Context

No response

[wolfram-cfx]

Fileserver regex should work. The fileserver is added to the resource list.json and the client downloads these from that path. Storing these as hashes in the cache would make sense yes. But thats considered a feature request for later.

[FingerlessGlov3s]

Yeah it's not a top priority but something that needs looking at further down the road, once Enhanced servers start rocketing in concurrent player counts

The regex works, I can see it make a request for https://cache.domain.com/resources/diving/files.json then the content with that json is as follows

{"version":1,"files":[{"hash":"1490c9c38c1ebb08fd08915782f4018370b53d8a","path":"resource.rpf"}]}

There's nothing in that json that says use the cache.domain.com, if that's what you're referring too there.

Hopefully something like https://cache.domain.com/resources/diving/files.json?b560febc0449c3317e30b1a58040542c7d60011a would be nice wish is a hash of the files.json itself. Then resource.rpf is requested via https://cache.domain.com/resources/diving/resource.rpf?1490c9c38c1ebb08fd08915782f4018370b53d8a

This way caching is easy to implement with uri+query_string caching key

[IchigoWalker]

Can confirm on the latest early-access Linux artifact (bXX, 2026-07-25): fileserver_add routes only the per-resource files.json manifests — resource.rpf and stream blob downloads still bypass the file server entirely.

Setup:

• fileserver_add ".*" "http://<files-host>:30122" in server.cfg, otherwise stock config;
• <files-host>:30122 is an nginx reverse proxy in front of the game server's HTTP endpoint, logging every request.

Observed on a fresh client join (client servercache wiped beforehand):
GET /resources/props_new/files.json 200 (via fileserver)
GET /resources/bcl_carwrec_refresh/files.json 200 (via fileserver)
GET /resources/required_ipls/files.json 200 (via fileserver)
... manifests only, for every resource ...

Not a single resource.rpf or stream blob ever hit the file server — the join succeeds and all payload downloads complete against the game endpoint directly. So the server-side injection works (consistent with "the fileserver is added into the resource list.json"), and it's the client-side URL construction for the payload step that ignores the fileserver base.
Two data points that may help narrow it down:

1. The files.json body is {"version":1,"files":[{"hash":"…","path":"resource.rpf"}]} — no host/base URL inside. Whatever base the client applies for the rpf/blob fetch is taken from the connect endpoint, not from the same fileserver mapping it just used to fetch that very manifest.
2. Manifest fetching over plain http:// works fine, so there's no TLS/scheme obstacle on the fileserver path itself.
   On the caching half of this report: +1 that URL-level cache busting is operationally important. Payload URLs carry no content hash, so a standard pull-through cache (nginx proxy_cache, CDN edge) has no invalidation signal — after any resource update a warmed cache would serve stale rpf bytes, the client's hash check rejects them, and joins hard-fail until a manual purge. Either a legacy-style ?hash= cache buster or ETag/Last-Modified + conditional GET support on these endpoints would make external caches safe.
   Happy to test candidate builds — we keep this rig (caching proxy + logging fileserver endpoint) permanently deployed on our staging server and can verify within minutes of a new artifact.

[Gogsi]

A fix for this bug has been implemented and is available in Hotfix 5. Please try again and let us know if the issue persists. Thanks for your help!

[FingerlessGlov3s]

51.x.x.55 - - [28/Jul/2026:18:02:26 +0100] "GET /files/resources/ox_lib/files.json HTTP/1.1" 200 97 "FXHttpClient" "-" "0.000" "-" "HIT"
51.x.x.55 - - [28/Jul/2026:18:02:27 +0100] "GET /files/resources/ox_lib/resource.rpf HTTP/1.1" 200 11321376 "FXHttpClient" "-" "0.773" "-" "HIT"

I'm now getting the resource.rpf comes through when using the fileserver, but there's no version hash in the resource.rpf, so I can't cache the file download sadly. Can we add ?hash= like it does in legacy, this way I can cache on the request effectively, as then any changes to the resource has a different hash, and I can then cache the updated resource. Ideally files.json should also apply a query hash, to allow effective caching.

[wolfram-cfx]

Thanks @FingerlessGlov3s , i'll create a ticket for this.

[IchigoWalker]

Working just fine, thanks