As you mentioned, the HTTPS aspect is the real issue here.
If web_baseUrl starts returning a raw endpoint or a simple 301 redirect without a valid SSL certificate, we’ll run into serious problems:
NUI / Mixed Content
Most modern resources rely on NUI and SetHttpHandler for communication. The in-game browser environment requires a secure context. If a resource attempts to make a non-HTTPS request, it will be blocked due to the browser’s mixed content policy.
The SSL Barrier
One of the biggest advantages of the current system is that SSL is handled automatically — it just works.
If we move to fully direct connections without built-in HTTPS, we’re effectively pushing server owners back into manually managing Let’s Encrypt certificates, DNS configuration, port 443 forwarding, renewals, and so on. For many server owners, especially those with limited technical knowledge, this becomes a significant barrier.
If the goal is to reduce infrastructure costs by removing media proxying, perhaps there’s a middle ground. For example, FXServer could include built-in ACME/SSL automation. That would allow traffic to go directly to the server (without proxying) while still preserving automated HTTPS.
I would like to express my concern regarding the deprecation of the *.users.cfx.re reverse proxy.
For self-hosted operators like myself, this service was extremely practical. It provided secure HTTPS access to txAdmin and HTTP endpoints without additional infrastructure, reduced exposed ports, and simplified SSL management.
While I can technically deploy my own reverse proxy, the convenience and security standardization offered by Cfx were part of the value of paying for a CFX key.
Without this service, the overall value proposition becomes less attractive for me.
I hope you will reconsider or provide a managed alternative.
But txAdmin has not supported using this reverse proxy for any version released in the last two years.
I did some stats check and IIRC less than 200 servers (~0.5%) were using the proxy to access txAdmin, and as far as server listing goes, that number was also really small and probably only related to users setting sv_forceIndirectListing without providing the endpoint they wanted.
I think there has been some confusion regarding what is being deprecated If the URL does not start like https://{whatever}-{cfxid}.users.cfx.re/, it is not being deprecated by March 31st.
All FXServer HTTP routes will still be available through the interfaces/endpoints specified under endpoint_add_tcp (in your server.cfg), which includes:
/info.json
/players.json
/dynamic.json
/client (used for joining the server as well)
Any route provided by resources using the SetHttpHandler
I would like to clarify why this change is concerning in my specific situation.
I am hosting my FiveM server from a residential connection with a static IP. The Nucleus reverse proxy allowed me to avoid exposing my home IP directly through the server listing and HTTP endpoints.
With the removal of the *.users.cfx.re proxy, my public IP will now be directly visible. This does not only affect the FiveM server — it potentially exposes my entire home network and other projects hosted on the same connection.
From my perspective, this increases the risk surface significantly (targeted attacks, scans, DDoS, harassment), which may impact not only the server but unrelated services as well.
While I understand that technically I can deploy my own reverse proxy or migrate to different infrastructure, the managed proxy provided a simple and secure abstraction layer that was especially valuable for small or independent operators.
Without this layer, continuing to develop my server project becomes more risky and less attractive for me.
I hope you will consider the impact on residential and small-scale hosts when finalizing this decision.
I understand your apprehension, but I assure you that your IP was never really “protected” by anything but security through obscurity (which reliance on is itself classified as a weakness), and that is because finding out your server IP has always been possible, and probably as easy to do now as it was before, without even needing any tools that are not available by default in all computers.
For abundance of clarity, let me say that this change does not make anyone more vulnerable to any attack, and neither makes them “more susceptible” as explained above.
This also does not “potentially expose” your home network. What was exposed before/after the update is completely outside the control of FXServer, and likely controlled by your local router device (e.g. port forwarding, upnp, nat poking, etc).
If you had any service exposed with a known vulnerability, it was likely already enumerated by search engines (like Shodan), or even already exploited by automated attacks to create "botnets". This is the unfortunate reality of the internet.
Regarding home hosting, it is not a viable option to any server with more than just a few players for a plethora of reasons, and if you are just running a “friends and family” server, then I highly recommend using the sv_master1 ConVar to set your server as “private”, in which case the server list won’t even show any connection endpoint.
In conclusion, this change should impact a minority of servers, most of whom didn’t even know they were using this proxy (due to the sv_forceIndirectListing mentioned in previous message), and certainly does not make anyone vulnerable. Furthermore, as you have stated yourself, there are plenty of proxy options out there.
Thanks for the clarification regarding IP exposure — I agree that the proxy was never a true security boundary.
However, I think the main concern for many developers isn’t IP masking, but secure HTTPS access for SetHttpHandler endpoints.
While HTTP routes will still technically work via endpoint_add_tcp, many modern resources rely on browser/NUI secure contexts. Without HTTPS:
NUI fetch requests can be blocked due to mixed-content policies
Media upload/preview systems may fail
Web dashboards and REST integrations become harder to deploy
Previously, the reverse proxy provided automatic HTTPS without requiring SSL management or reverse proxy setup.
So the question isn’t about IP visibility — it’s about whether there will be a simple, built-in way to expose SetHttpHandler routes over HTTPS without forcing every server owner to manage certificates and reverse proxies themselves.
Thank you for the clarification regarding IP exposure — I understand the point about security through obscurity, and I agree that the proxy was not a true security boundary.
However, my concern is less about IP masking and more about operational simplicity and HTTPS availability.
I am running my server on a residential static IP, but this is not a casual setup. I have a 2.5 Gbit connection connected to an 8 Gbit router (up/down), a properly configured firewall (my own project), closed SSH access from WAN, and a hardened network configuration. This setup is actually more flexible and cost-efficient for me than renting a virtualized VPS at $20–$40/month with shared resources.
I am not hosting this irresponsibly — I deliberately chose to self-host in order to retain full control and sovereignty over my infrastructure and data.
The Nucleus reverse proxy was valuable not as a security illusion, but as a frictionless HTTPS layer for SetHttpHandler endpoints and web integrations. It reduced operational overhead and provided a standardized and officially maintained access layer without requiring additional infrastructure.
My concern is that removing this managed abstraction increases complexity and operational overhead for independent operators who deliberately choose to self-host seriously and responsibly.
If no managed alternative is planned, an officially documented minimal HTTPS solution tailored specifically for FXServer would greatly help smaller but committed operators like myself transition smoothly.
In any case, I truly appreciate this constructive exchange. It is genuinely a pleasure to discuss these topics openly and technically with the team.
The problem is that you need to pay for proxyfication on Cloudflare with a FiveM server.
For a little creator like me, who want use just his server for interactiv, and try to help FiveM ecosystem at the same time, this news is not cool.
The Nucleus Proxy was easy to use with the approved license system of TxAdmin. It was a good combo to hide your IP address for free, and the latency is not so bad.
As a SaaS developer running Pixel Admin Hub, I’d like to echo the concerns regarding the HTTPS/SSL barrier.
My platform manages multiple FiveM servers via a web dashboard. Currently, we rely on the .users.cfx.re proxy to ensure secure communication between our HTTPS dashboard and the servers’ HTTP endpoints.
If this is deprecated without a streamlined alternative, we face two bad options:
Forcing Clients to self-host proxies: This is a major friction point. Most server owners aren’t technical enough to manage Cloudflare Tunnels, Nginx, or SSL certificates. It would effectively “break” the ease of use for our SaaS.
Centralized Proxying: We would have to route all dashboard-to-server traffic through our own backend. This introduces significant latency and massive bandwidth costs for us as developers, which isn’t sustainable at scale.
We really need a built-in way for FXServer to handle SSL (perhaps via ACME/Let’s Encrypt integration) or a dedicated, lightweight proxy for authorized developer platforms. Deprecating this without a “One-Click” secure alternative will negatively impact the entire ecosystem of web-based tools for FiveM.
before judge someone else ask you some questions before but its not the subject.
