Why Your IP Always Ends Up Out There
A FiveM server has to be reachable to be playable. Sooner or later something has to publish an address and a port that a player's client can connect to, or nobody joins. That is the whole problem of IP concealment in one sentence: make sure the published address belongs to a proxy, and never to the machine running FXServer.
The difficulty is that FiveM publishes a lot by default. The server exposes its own HTTP endpoints, announces itself to the Cfx.re listing backend, and most owners also run a website, a txAdmin panel and a FastDL host on the same machine. Each of those surfaces can give away the origin address independently of the others — and one is enough to collapse the whole thing.
This post covers the convars that genuinely hide the origin, the ones that no longer do anything even though they still circulate in every copy-pasted config block, the leaks that undo everything else, and the two-minute check you can run yourself. Nothing here is invented: every convar is quoted from the official FiveM documentation.
What Someone Hunting Your Origin Actually Sees
The threat model is simple and requires no special skill. Someone wants your server down, so they need an IP to saturate. They start with whatever Cfx.re publishes about your server, then widen out — your domain's DNS history, your site's TLS certificate, the panel's IP, the FastDL host's IP, FXServer error messages.
This is not an exploit, it is collection. Every service you expose from the same machine is another chance to correlate an address. That is why partial concealment is worth nothing: an attacker does not need the best source, only one that works.
The good news is that the surface is finite, and it closes methodically. If someone has already threatened to DDoS your server, here is how to check whether your IP is exposed.
The server.cfg Block That Actually Hides the Origin
Start with the convar everyone puts first — and which does not do what most people think.
sv_endpointPrivacy: the most widespread misunderstanding
The FiveM documentation describes it as "a boolean variable that, if true, hides player IP addresses from public reports output by the server." Read that carefully: player IP addresses, not yours. It never hid your server's address — it stopped players.json from publishing the IP of every connected player.
On current FXServer builds it does not even do that any more, because the behaviour became unconditional. Leave it in your config and the server prints this at startup:
sv_endpointPrivacy has been removed. Player endpoint addresses are no longer
exposed on any HTTP endpoint. Please remove this ConVar from your server
configuration.
So: keep it if you are pinned to an old build, remove it otherwise, and above all do not count on it to conceal your origin. The same reasoning applies to sv_useDirectListing, which appears in nearly every "anti-DDoS" block shared on forums: it is in neither the server commands reference nor the official proxy setup guide. The documented lever is sv_forceIndirectListing.
The convars that do the hiding
The official proxy setup guide gives this reference block:
set sv_forceIndirectListing true
set sv_listingHostOverride "server1.example.com"
set sv_proxyIPRanges "100.64.1.1/32"
set sv_endpoints "100.64.1.2:30120"
What each line does:
| Convar | What it does | What it does not do |
|---|---|---|
sv_forceIndirectListing | Boolean (false by default) that prevents the server from being advertised using its real IP address in the listing | Filters nothing, drops no packets |
sv_listingHostOverride | Makes the listing backend request a specific domain instead of the default connection method | Changes nothing for anyone who already has the IP |
sv_endpoints | Declares the actual endpoint the server is hosted on, or one or more endpoint proxies clients use to connect over UDP | Does not close direct access to the origin |
sv_proxyIPRanges | Space-separated list of IPv4 networks in CIDR notation allowed to send an X-Real-IP header — and to bypass the rate limiter | Nothing else: it is not a firewall allowlist |
sv_listingIpOverride | Only needed when the listing backend cannot determine the IP on its own (multi-IP machines, firewalled servers) | Is not required in a standard proxy setup |
The caveat on sv_proxyIPRanges is spelled out in the documentation: the listed ranges bypass the rate limiter. Setting it to 0.0.0.0/0, or to a wide range "so it works", therefore disables a built-in protection for the entire internet on top of letting anyone spoof X-Real-IP. Put only your proxy's exact CIDRs in it — nothing more.
These settings hide the address; they filter no packets. That is the job of a FiveM anti-DDoS, which is a separate service doing a separate job.
The Leaks That Undo Everything Else
You can have a perfect block and still be exposed. Here are the seven leaks that show up most often, in the order they actually happen.
- The website on the same machine. Your domain has an A record pointing at the same IP as FXServer. One
digfinds it. Put the site behind an HTTP proxy, or host it elsewhere. - An old DNS record. You moved the site behind a proxy after the fact, but DNS history and public certificate transparency logs still hold the previous address. If the origin was ever public, changing the IP is usually the only clean restart.
- FastDL and the resource cache. A
fileserver_addpointing at your own machine serves downloads straight from the origin, to every player who connects. Serve them through a CDN instead. - FXServer error messages. Some connection failures hand a raw address back to the client. This is the quietest leak, because it only shows up when something breaks.
- An exposed txAdmin. The panel listens on its own port on the same machine. If it answers from the origin IP, it announces it. Restrict access to it or route it through the proxy.
- Discord webhooks and logs. A logging webhook that includes the server endpoint, a console screenshot pasted into a help channel, a debug command run in front of players — all of it circulates.
- A hardcoded IP inside a resource. A resource that calls your own API by IP rather than by hostname puts the address in a file every player downloads.
The general rule: your origin IP should appear nowhere except in your own firewall and in your proxy configuration.
Check It Yourself, in Two Minutes
Do not trust the config, verify the result. The CFX Finder takes a cfx.re/join/ code and checks whether the connection address Cfx.re publishes for that server is exposed. Look up your own and read the connection address it shows:
- If you see your proxy hostname, or the domain you set in
sv_listingHostOverride, indirect listing is working. - If you see a raw IPv4 followed by
:30120, your origin is being published as-is —sv_forceIndirectListingis not active, or was not read at startup. - If the tool shows the server as private and gives no address at all, the listing is broken, not hidden: Cfx.re publishes a
private-placeholder.cfx.reendpoint and disables the connect button. That usually means a listing problem — a missing or unregisteredsv_licenseKey, a blankedsv_master1, or more than 32 slots without OneSync. Fix that first; a private listing is not origin masking.
Add two network-side checks: dig +short yourdomain.com should not return the game machine's IP, and a direct request to the origin IP on port 30120 should get nothing from outside. If you already run behind a proxy, that second test is the more revealing of the two.
Hiding Is Not Filtering
One point almost every guide skips: hiding the address does not shrink the attack surface, it moves it. The published address becomes the proxy's, and that is now the address taking the attack. If that proxy has neither the upstream bandwidth to absorb a volumetric flood nor filtering that understands FiveM's handshake, you have moved the target by exactly one hop.
It is also why concealment alone does not hold over time. The day someone finds the origin again — through one of the seven leaks above, or because it was public before you got around to this — there is nothing left between the attack and the machine. Locking the origin firewall down to the proxy's ranges is therefore the mandatory other half of the work, and the complete guide to stopping DDoS attacks on a FiveM server sets out the rules to put in place.
Anti-DDoS protection that keeps the origin permanently masked does both: it publishes an address that is not yours, and it filters what arrives at that address. On our side the whole configuration is a block pasted at the top of server.cfg — the install guide takes five minutes, and pricing is based on your daily peak player count, with no subscription.
FAQ
Is changing my server IP enough to fix this?
It fixes the past, not the future. If the old address was public, a new IP gives you a clean slate — but without indirect listing and an origin firewall, the new address gets published exactly like the old one on the first startup.
Does sv_endpointPrivacy protect my server's IP?
No. It covered player IP addresses in the server's public HTTP reports, never the server's own. On current FXServer builds it has been removed, and the server asks you to take it out of your configuration.
Can a VPN or a port change hide my server?
No. The port is not a secret — it is published alongside the endpoint — and a consumer VPN changes nothing about the address FXServer announces to the Cfx.re listing. The listing decides what is public, not the network layer underneath it.
Can I do all of this without paying for a service?
Partly, yes. Indirect listing, locking down the origin firewall and closing the seven leaks are free and worth doing regardless. What free does not give you is upstream absorption bandwidth and filtering that can tell a real player from a fake connection.
How do I know my configuration was actually applied?
Restart the server and read the startup console: convars are read in file order, so a block placed after a line that overrides them never applies. Then re-run the CFX Finder check — it is the only test that reflects what the outside world actually sees.