Someone threatened to DDoS my FiveM server: is my IP exposed?

Updated

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026. Sources

VerdictA threat is not an attack

A threat is not an attack. The real question is whether your origin IP is published, and you can check that in two minutes.

FiveShield helps with part of this

Hiding the origin behind a proxy is what FiveShield does, but steps you can take yourself cover part of it: do those first.

A threat is not traffic. A message in Discord or a ticket shows that someone wants to hurt your server, not that a packet has been sent. It changes the question: not “am I being attacked?” but “can someone find the address to aim at?”

Start with what the Cfx.re listing publishes. By default a server is advertised with its real address: the documentation says sv_forceIndirectListing (default false) “prevents the server from being advertised using its real IP address”. The CFX Finder reads the listing as a stranger would, from your join code. A raw IP and port there means the address is public. A Cfx.re staff member wrote, in the thread on deprecating the Nucleus reverse proxy, that “finding out your server IP has always been possible”.

Only evidence from outside the machine turns a threat into an attack: a host notice, a mitigation-log row, an inbound traffic graph that jumps. Until then, close the ways your address is found and take a baseline of inbound traffic on a quiet day. If evidence appears, read the guide on traffic spikes and host notices.

Messages you may see

  • Error: Force indirect listing is enabled, but no host override is set. This is not supported!

    In the server console, in red, each time a heartbeat is sent, when sv_forceIndirectListing is on without sv_listingHostOverride

What it actually means

This page is about what your server tells the outside world. Every 3 minutes, and sooner after a player connects or drops, FXServer (GameServer.cpp) sends a heartbeat: an outbound HTTPS POST to the Cfx.re listing ingress. It carries your port, a listing token and ipOverride (from sv_listingIpOverride, empty by default). The proxy guide says that value is only needed when the listing backend cannot work out the IP itself, which implies that normally the backend finds your address on its own.

A client then resolves a connect endpoint (the connectEndPoints field of the listing, which sv_listingHostOverride can set), calls GET /info.json and POST /client there, and asks getEndpoints for the server endpoint, which sv_endpoints sets and which then receives its UDP traffic. Hiding the origin means changing what both endpoints publish, then making the machine refuse everyone but your proxy. The convars that set endpoints filter no packet.

Check this first (two minutes)

Five checks separate “someone said something” from “the address is public” and from “traffic is arriving”.

  1. Evidence of traffic, or only a message?

    Evidence is outside the machine: a host notice of an attack on your IP, a mitigation-log row, a jump in inbound traffic. A message is not evidence.

  2. Look up your server in the CFX Finder

    Enter your cfx.re/join/ code to see the connect address cfx.re publishes.

    • It shows a raw IP and a port, under “This server’s IP is exposed” or a title ending “but publishes a raw IP”.: Read cause 1: the listing publishes your real address

    • It shows a hostname, or an address in a proxy network’s range.: Go on to step 3.

    • It says “Listed as private” and you meant it.: Go on to step 4: the listing publishes no address, but the other leaks remain.

    • It says “Listed as private” and you did not mean it.: Read the guide on a server missing from the server list

    • It says “No usable connect address”.: The listing gives nothing to read. Go on to step 3.

  3. Force a heartbeat and read the console

    Run heartbeat, watch the console for a red line, then look the server up in the CFX Finder again.

    heartbeat

  4. Compare three addresses

    The machine’s public address; what each of your hostnames resolves to (your website, and the name in sv_listingHostOverride; ask a DNS tool for A and AAAA records); and sv_endpoints in server.cfg.

  5. Test the origin from outside

    From a machine that is neither your server nor your proxy (a phone on mobile data works), open http://<origin-ip>:30120/info.json, the URL the FiveM documentation uses to test reachability, then http://<origin-ip>:40120 for txAdmin.

Causes, ranked

The order is editorial: the causes a source documents come first, cheapest check first. It is not a measured frequency, and several can apply at once.

Ranked by what owners report most and how cheap each check is. That is an editorial order, not a statistic: nobody publishes a dataset of FiveM outage causes. Documented means official docs or the FXServer and txAdmin source. Owners report means forum threads and issue trackers. Our inference is our reasoning from documented facts, shown so you can check it.

  1. The Cfx.re listing publishes your real address

    Documented

    By default the listing advertises the machine’s real address: sv_forceIndirectListing defaults to false, and the proxy guide’s comment on that line reads “prevents the server list from advertising your server using its actual IP”. The connect endpoint comes from the connectEndPoints field of the listing, which sv_listingHostOverride can set. Anyone with your join code can read it.

    How to confirm

    Look up your join code in the CFX Finder. A raw IPv4 address and a port confirm it; a hostname does not. “Listed as private” does not prove a hidden origin: it publishes no address.

    What to do

    Put a connect proxy on a hostname you control, then set sv_forceIndirectListing true and sv_listingHostOverride "server1.example.com" (use your own hostname), with sv_proxyIPRanges listing only your proxy, because the listed ranges also bypass the rate limiter. Wait until the hostname answers: a comment in the FXServer source warns that the option “will break listings if the proxy host can not be reached”. Then run heartbeat and check again; the documentation gives no refresh time for a changed listing (it says only that a new server can take up to 8 minutes to appear).

  2. sv_forceIndirectListing is set without sv_listingHostOverride, or was never applied

    Documented

    In GameServer.cpp the heartbeat adds forceIndirectListing and hostOverride only when sv_listingHostOverride is not empty. With the flag on and no override, the server prints the red error above and sends neither field. The source does not show what the backend then does; the CFX Finder does.

    How to confirm

    Run heartbeat: the red line means the override is missing. With no error and a raw IP still showing, check that the lines are in the file FXServer executes, that you restarted, that a heartbeat has gone out since, and the spelling of sv_listingHostOverride.

    What to do

    Set both together, once the hostname answers. With no proxy yet, remove sv_forceIndirectListing: alone, the server does not even send it.

  3. The game endpoint, sv_endpoints, still names your own address

    Documented

    A hostname in the listing hides only the first half. The proxy guide says the server endpoint “needs a raw TCP/UDP proxy on matching ports”: getEndpoints hands every client “one or more IP/port combos” and the client sends its UDP there. The guide’s own example sets sv_endpoints to “the actual endpoint your server is hosted on”. Everyone who has joined while that value was in place, a player you later banned included, was handed that address. Left empty, sv_endpoints is not what decides: the convar documentation says “the auto-detected public IP is used”, but in InitConnectMethod.cpp an empty value makes the server return an empty list, and the client (NetLibrary.cpp) then sends its UDP to the host it connected to. A raw IP in the listing therefore means the origin; a hostname means wherever that name points.

    How to confirm

    Read sv_endpoints. The machine’s own address means the game endpoint is the origin. Empty, see above: the listing decides, so cause 1 and cause 4 are where to look. The CFX Finder cannot see this: it reports the connect address only.

    What to do

    Point sv_endpoints at the public address of a proxy that forwards UDP and TCP on matching ports, then close the game port to everything but that proxy. Until then the old address keeps working for anyone who has it.

  4. A DNS record, a website, a screenshot or a resource publishes the address

    Our inference

    This is our reasoning, not FXServer behaviour. A hostname whose A or AAAA record holds the machine’s address publishes it to anyone who can type the name: your website, a play. name, the name in sv_listingHostOverride if it points at the origin. Addresses also leave through the owner: a console screenshot in a help channel, a webhook that includes the endpoint, a client script that calls your API by IP (players download client scripts). Treat any address ever published next to your name as known.

    How to confirm

    Compare the A and AAAA records of every related hostname with the machine’s address. Search your resources and configs for the literal address, and read your webhook templates.

    What to do

    Move the website elsewhere or behind an HTTP proxy, point the listing hostname at the proxy only, and remove literal addresses. If the origin address was ever published, ask your host for a new one once the proxy is in place: changing it first only gets the new address listed within a few heartbeats.

  5. txAdmin or another service answers on the same address

    Our inference

    The txAdmin documentation says it listens on TCP port 40120 by default (TXHOST_TXA_PORT) on interface 0.0.0.0 (TXHOST_INTERFACE), every interface. Whether the internet reaches it depends on your firewall, which the documentation does not describe, so the rest is inference: a panel answering on http://<origin-ip>:40120 tells anyone who finds it that this address runs your server.

    How to confirm

    From outside your network, open http://<origin-ip>:40120. A txAdmin login page means the panel answers on the origin. Repeat for any other panel or service on the machine.

    What to do

    Restrict port 40120 to the addresses you administer from, in the machine’s or your host’s firewall. Do not use TXHOST_INTERFACE to hide it: its documentation says it also decides what FXServer binds to.

  6. The threat is followed by a real attack

    Our inferenceThe DDoS case

    A threat can be carried out. No source we know of measures how often, so this page gives no rate. Once someone has the address they can aim traffic at it from anywhere, and the sources are usually spoofed, which is why OVHcloud does not show them. Only evidence from outside your machine shows it.

    How to confirm

    Look for a host notice, a log row or a jump in inbound traffic (commands below). On OVHcloud, Network > Network Security Dashboard lists each detected attack with “Detection time”, “End time”, “Destination IP” and “Attack vectors”; an empty log means “no suspected attacks have targeted your public IP addresses”, but it covers only what the detection flags.

    What to do

    Do not restart repeatedly or announce a new address. Save the host’s log and graph now (OVHcloud documents 1 year for the log, 2 months for the chart). Put a proxy in front first, then change the origin address and publish it nowhere.

What a DDoS looks like here

An attack that follows a threat shows up outside your machine first, not in the message.

What a DDoS looks like here

  • Your host tells you: an e-mail or dashboard entry saying traffic to your IP was rerouted or filtered, starting when the trouble did.
  • An inbound traffic graph that jumps in packets or bits per second against a quiet-day baseline. Outbound traffic after a restart is downloads, not an attack.

Evidence you can collect

  • Your host’s notice and log

    On OVHcloud: Network > Network Security Dashboard, scrubbing centre log. Sources are hidden because they are usually spoofed: there is nothing to ban. Other hosts differ.

  • Inbound packet rate on Linux

    Run it during the event and on a quiet day; compare rxpck/s (packets received per second) and rxkB/s.

    sar -n DEV 1 10

  • Inbound packet rate on Windows

    The same comparison, with the packets-received counter.

    Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

  • A short capture of the game port

    Needs root. Use your interface and port. A handful of player addresses is normal; many scattered sources sending far more packets than you have players is not. Sources can be spoofed, so a capture supports the host notice and the graph without replacing them. Do not ban sources.

    tcpdump -n -i <iface> -c 2000 'udp dst port 30120'

What it does not look like

  • The threat itself, even one quoting your real address: the address is known, so close the origin, but no traffic is shown.
  • Lag, hitch warnings or timeouts on their own.
  • A raw IP in the CFX Finder alone, or outbound traffic after a restart.

When protection is, and is not, the answer

Protection is the answer when

  • Your address has been public (a raw IP in the CFX Finder, a quoted address, a screenshot) and you want that to stop mattering: the listing and the game endpoint must publish a proxy’s address, and the machine must refuse everything else.
  • You have confirmed attack traffic that your host’s own mitigation does not stop. Convars publish less and a firewall refuses strangers, but neither absorbs traffic that has already reached your link.
  • You cannot run a TCP and UDP proxy on matching ports yourself, which the proxy guide requires for the server endpoint.

Protection is not the answer when

  • The CFX Finder shows a hostname that is not your machine, sv_endpoints names a proxy and the origin refuses outside traffic: the address is no longer published; filtering is a separate decision.
  • The leak is your own: a DNS record, a website on the machine, an open txAdmin port, an address in a resource. A proxy in front of the game port closes none of them.
  • The symptom is lag, a hitch warning or a timeout with no outside evidence. A proxy does not change how fast a thread runs.
  • The origin still accepts direct traffic: a proxy is bypassed until the origin address changes and its firewall accepts only the proxy.

If you are actually attacked, or want the origin hidden

If an attack is happening now: do not restart repeatedly, because traffic arriving from outside does not stop when the process restarts and every restart disconnects your players; do not announce a new address, because the person who threatened you may be in the channel; save your host’s evidence before it expires.

Put a proxy in front before you change the origin address: unless the listing and sv_endpoints point at the proxy, the new address is listed again within a few heartbeats. Once the proxy answers, ask your host for a new origin address and publish it nowhere.

FiveShield does this part. Players connect through its proxy instances, so the listing and the game endpoint publish a FiveShield hostname instead of your address, and its filtering applies to what reaches the proxy. Leaks you created yourself, as in causes 4 and 5, stay yours to close.

Start Free Trial

Your first server gets $10 CAD of free trial credit (eligible accounts, no card required): about four days of protection for up to 50 players.

What FiveM anti-DDoS protection has to do, including hiding the origin

Still stuck? What to post

Replace your real address with x.x.x.x in anything you paste: a help thread is public.

  • Your FXServer build number, and your txAdmin version if you use it.
  • What the CFX Finder reports (raw IP, hostname or private), address hidden.
  • The server.cfg lines starting sv_forceIndirectListing, sv_listingHostOverride, sv_endpoints and sv_proxyIPRanges, addresses masked.
  • The console output after heartbeat, including any Error: Force indirect listing or Server list query returned an error: line.
  • Whether your website and panel run on the same machine as FXServer.
  • If you suspect an attack: the host’s log row (masked) and your sar or Get-Counter output.

Frequently asked questions

Someone threatened to DDoS me. What should I do?

A threat is not traffic. Look up your join code in the CFX Finder and work through the five checks above. If your host or a graph shows traffic, read the guide on traffic spikes and host notices. Do not restart repeatedly or announce a new address.

How do I check whether my FiveM server IP is exposed?

Enter your cfx.re/join/ code in the CFX Finder: a raw IP and port mean the listing publishes your address. Then compare your hostnames and sv_endpoints with the machine’s address, and from outside open http://<origin-ip>:30120/info.json and http://<origin-ip>:40120.

Is changing my server IP enough?

It clears the past, not the future. The proxy guide implies that the listing backend finds your address itself, so within a few heartbeats (sent every 3 minutes) expect the listing to show the new address as it showed the old one, unless the listing and sv_endpoints point at a proxy. Put the proxy in place first.

Does sv_endpointPrivacy hide my server’s IP?

No. It concerned player addresses and has been removed. If you still set it, FXServer prints “sv_endpointPrivacy has been removed. Player endpoint addresses are no longer exposed on any HTTP endpoint.” Your own address depends on sv_forceIndirectListing, sv_listingHostOverride and sv_endpoints.

Verified against, and sources

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026.

Server behaviour changes between builds. If your build prints something different, the build numbers above tell you what this page was checked against.