Nucleus Reverse Proxy Deprecation

On March 31, 2026, the current *.users.cfx.re reverse proxy will be fully deprecated, meaning you will no longer be able to access your server http endpoints via this reverse proxy service.

As our platforms evolve, some features may no longer meet current performance or maintenance needs. When this occurs, we deprecate them to focus on more reliable and scalable alternatives. There are also plenty of free third-party resources available to build your own reverse proxy if desired.

We encourage you to let us know if this planned change might have an effect on your FiveM or RedM server. Please leave a comment below, or send a message on our Discord server.

Thank you, and please stay tuned for more platform updates and news.

25 Likes

To clear up some confusion that I (and maybe others) had:

The https://cfx.re/join/<servercode> join links will remain active. What will be removed is the https://<username>-<servercode>.users.cfx.re URL that gets printed when the server starts up.

You could use that URL as a reverse proxy for joining the server and also to access /info.json, /players.json, /dynamic.json and custom endpoints registered with SetHttpHandler. But I don’t think many people actually did that.

14 Likes

Thank you Sir Gogsi :saluting_face:

Honestly we’re not sure how many people have been using it/if removing it might mess up anyone’s server, so we want to get feedback before we say a proper goodbye to Nucleus.

5 Likes

Green Light for me :+1:t2:

3 Likes

Good ig :mascot:

2 Likes

Go ahead.

2 Likes

Very random

2 Likes

The proxy is actually used by a major number of servers (possibly +10k) for various purposes.
It makes it easy and predictable for creators to build stuff without requiring the servers to have a proxy setup.

5 Likes

I’m currently using some custom endpoints via the SetHttpHandler native, so this would have an effect on me, however, it’s really not a big deal. I’ll simply find/create an alternative. Better to move forward than to be stuck in legacy land.

1 Like

So the http://ip:port/info.json wil be removed and no longer be available publicly?

1 Like

Accessing endpoints by https://ip:port will continue to work for both built in endpoints like info.json and custom ones using SetHttpHandler.

This is an alternative way, if you don’t want to reconfigure your scripts every time you change your server IP - you can use the Nucleus reverse proxy at https://<username>-<servercode>.users.cfx.re. The suggestion is to remove this reverse proxy but it seems some popular scripts do actually use it.

3 Likes

A suggestion if possible for these deprecations is to put this behind a convar that we can opt into prior to the deadline to test if we are affected by this change.

1 Like

Hey there! I do actually use this extensively as it allows https traffic to the api endpoints and http handlers set up by resources. This allows you to access these endpoints for example in a web browser which doesn’t allow http fetches if you’re on a https site. Will there be a replacement?

4 Likes

Hi, I’m not an API expert or anything like that, but I’d like to know whether this would affect the 5metrics website created by LB. If so, how exactly would it impact the site?

If that’s the case, it might be a good idea for FiveM itself to create its own official website to display how many servers and players are using specific scripts.

I have a Discord bot that looks at the players.json, is it going to still work if I am using 127.0.0.1 in the bot code? For context, the bot is hosted on the same server as our FiveM project.

1 Like

One critical aspect that needs more attention regarding this deprecation is the impact on SetHttpHandler.

Many modern resources rely on SetHttpHandler to expose HTTP endpoints directly from the server runtime. These are frequently accessed via the *.users.cfx.re proxy using GetConvar("web_baseUrl", ""). Removing this doesn’t just affect join links; it breaks essential functionality that many servers might not even realize is dependent on this proxy until it’s gone:

Media Systems: In-game image/video uploads and previews.

NUI Integration: Secure HTTPS fetches and post from NUI to the server.

Integrations: Custom REST APIs for Discord bots and external web dashboards.

For the average server owner, setting up a manual reverse proxy, managing SSL certificates, and configuring public ports is a significant barrier to entry. If the goal is to move away from Nucleus, we definitely need an official, streamlined alternative for securely exposing SetHttpHandler endpoints to prevent widespread breakage across the ecosystem.

10 Likes

Couldn’t agree more. This is actually exactly what I do too with the web_baseUrl convar in all my resources using this. For an example see my filehost resource GitHub - r3ps4J/r3_filehost

3 Likes

I agree we use it for in-game images and some rest-api’s because it just handles the SSL for us. They should look for a streamlined alternative if only it’s for security reasons because even if a average server owner is gonna setup a reverse proxy it might not be as secure and eventually the blame will be put on cfx anyway if or when something happens.

But whatever happens please communicate it weeks before so we can adjust properly. Just like this announcement haha. Thanks.

1 Like

The server profiler directs to this link as well, this will need to be addressed too

2 Likes

is it going to still work if I am using 127.0.0.1

Yes, fetching endpoints by IP/Port isn’t affected, even if it’s 127.0.0.1

Many modern resources rely on SetHttpHandler to expose HTTP endpoints directly from the server runtime. These are frequently accessed via the *.users.cfx.re proxy using GetConvar("web_baseUrl", ""). Removing this doesn’t just affect join links; it breaks essential functionality that many servers might not even realize is dependent on this proxy until it’s gone:

The problem with doing that is that because it’s a proxy, it means all of the traffic you send goes through Cfx’s servers, when it really doesn’t need to. I can see this be particularly annoying for them when you’re uploading images or videos. I see 2 potential easy solutions:

  • Make the web_baseUrl convar return the connectionEndpoint directly
  • Make *.users.cfx.re not be a proxy but instead a 301 Moved Permanently redirect to the connection endpoint.

Both of these would probably break HTTPS though, unless the server owner manually configures it :thinking: