FiveM Failed to get info from server (tried 3 times): what it means and how to fix it

Updated

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

VerdictCheck other causes first

The server’s UDP reply never came back, which points first at UDP 30120, forwarding, firewalls and your proxy rather than at an attack.

FiveShield helps only if an attack is confirmed

FiveShield helps only if the path to your server is under attack. If you already run a proxy, its UDP hop is the first thing to check.

The player’s client finished the HTTP part of joining, then sent a UDP getinfo request four times, about five seconds apart, and got no answer. Check first: UDP 30120 closed or not forwarded, endpoint_add_udp missing, a proxy that carries TCP but not UDP, or (our reading) a host game firewall that drops UDP on your game port.

First check: from a network that is not yours, press F8 in FiveM and run connect IP:Port with your public IP and game port. The same message means the UDP path is broken; a successful join means the path can work, so examine the failing player.

Suspect a DDoS only on evidence from outside the machine (your host’s notice, an inbound traffic graph, a capture); this error alone proves nothing.

Messages you may see

  • Failed to get info from server (tried 3 times).

    In the player’s connection dialog, after four UDP getinfo requests went unanswered

  • If you are the server owner, are you sure you are allowing UDP packets to and from the server?

    In the same dialog, under the error

  • Failed to connect to server after 3 attempts.

    In the player’s client, one stage later (the ENet connect)

  • Handshaking with server...

    In the player’s client; a player who stays here never got past the HTTP handshake

  • Failed to fetch /info.json to obtain policy metadata.

    In the player’s client, at an earlier stage (the HTTP GET of /info.json)

What it actually means

Joining is a sequence, listed in FiveM’s proxy documentation: /info.json, initConnect and getEndpoints on the connect endpoint; getConfiguration and the /files/* downloads on the server endpoint or a file server; then a UDP info request to the server endpoint and the ENet connect. Every stage before the UDP request is HTTP over TCP.

The message comes from the client’s NetLibrary.cpp. After the downloads it shows Fetching info from server... and sends the packet getinfo xyz over UDP, again whenever more than five seconds have passed, adding (attempt 2), (attempt 3). The client gives up as soon as the fourth request is sent, about 15 seconds after the first.

It accepts the reply, an infoResponse packet, only from the address it sent getinfo to. So the message says one thing: the request or its reply did not get through, for a reason it does not name.

Check this first (two minutes)

Steps 4 and 5 need a terminal on the server machine.

  1. Which message do the players see?

  2. One player or everyone, and what changed first?

  3. Join with Direct Connect from outside your network

    Press F8, then enter your public IP and game port from a phone hotspot or a friend’s connection: from inside your network the traffic often skips your router’s forwarding and your provider’s firewall, so a join there proves little.

    connect IP:Port

  4. Is FXServer bound to UDP 30120?

    Run the first line on Linux or the second in Windows PowerShell. FXServer should own a UDP socket on your game port (on Windows, OwningProcess is the process ID).

    ss -lunp
Get-NetUDPEndpoint -LocalPort 30120

    • No UDP socket on the port, or another program owns it: Read cause 2: the endpoint_add_udp line

    • No FXServer process: Start the server and read its console: it is down, which is not a network problem.

    • FXServer owns the UDP socket: Continue with step 5.

  5. Do the packets arrive, and does a reply leave?

    On the machine that receives the players’ traffic (the origin, or the proxy host), capture while someone tries to join and stop with Ctrl+C. It needs root; on Windows, OVHcloud’s dashboard guide points to Wireshark.

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

Causes, ranked

Each cause names the check that settles it.

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. UDP 30120 is blocked or not forwarded

    Documented

    getinfo travels over UDP; every earlier stage used TCP. A firewall or router that passes TCP 30120 but drops UDP 30120 gives exactly this: the HTTP stages succeed, then four UDP requests go unanswered.

    How to confirm

    Run step 3 from outside, then check each layer: the system firewall, your router or provider, and any firewall your host runs in front of the machine. A website port check does not settle it (the docs do not say it tests UDP, and a forum poster reports the error while one showed the port open), nor does txAdmin showing the server online: its health check is a request to /dynamic.json from the server’s own machine.

    What to do

    Allow UDP and TCP in both directions on the game port at every layer. The default server.cfg binds both: endpoint_add_tcp "0.0.0.0:30120" and endpoint_add_udp "0.0.0.0:30120". At home, forward both protocols.

  2. endpoint_add_udp is missing, or uses another port than TCP

    Documented

    The docs describe endpoint_add_udp as the command that creates the UDP host instance, and its address and port must be valid and not already in use. Without it, TCP still serves the HTTP stages and the UDP request finds no listener (our reading). txAdmin flags a config with no address and port shared by both lines, ending Players would not be able to connect.

    How to confirm

    Step 4 shows whether FXServer owns a UDP socket on the port; then read server.cfg and every file it loads with exec.

    What to do

    Put both lines on the same address and port: endpoint_add_udp "0.0.0.0:30120" and endpoint_add_tcp "0.0.0.0:30120". If a local TLS proxy moves only the TCP port, write the UDP line first, as the docs say. Free the port if another process holds it.

  3. A proxy or forward that does not carry UDP, or publishes the wrong UDP address

    Documented

    FiveM’s proxy documentation separates two proxies: the connect endpoint can be an ordinary HTTPS reverse proxy, while the server endpoint “needs a raw TCP/UDP proxy on matching ports”. A relay that forwards TCP but not UDP lets getConfiguration and the downloads through, then leaves the UDP request nowhere to go. The UDP address comes from sv_endpoints (empty means your auto-detected public IP, not the relay’s); with several addresses listed, the client picks one at random, so one dead relay fails only some joins. The client also ignores an infoResponse that does not come from the address it sent getinfo to (our reading of NetLibrary.cpp).

    How to confirm

    Join through the proxy and, from an allowed address, through the origin: if only the origin works, the relay is at fault. Capture at both ends (step 5) to see where the packets stop.

    What to do

    Give the server endpoint its own raw TCP and UDP relay on matching ports (the docs show an nginx stream block with listen 30120; and listen 30120 udp reuseport;), set sv_endpoints to its address, and let the origin’s firewall accept UDP from it.

  4. A host game firewall that drops UDP on your game port

    Our inference

    OVHcloud’s guide to its Game firewall (Game dedicated servers only) has you add rules per IP naming a game protocol and port range, and strongly recommends “Default Deny”, which “blocks all traffic that does not match the rules you set up for the Game Firewall”. It applies after the Edge Network Firewall, which the guide says cannot be too strict. The guide does not say how a FiveM rule treats TCP and UDP, so this is our reading: a port with no rule at all would drop the HTTP stages too (an earlier error), so this message points at a rule that lets them through but not the UDP side of your port.

    How to confirm

    On OVHcloud, Network > Public IP Addresses, then Configure Game firewall on the IP players use, shows the rules and the Default Deny option; the IP’s Game firewall status must read Configured for rules to apply. Network > Network Security Dashboard (Advanced mode) shows the Firewall and GAME firewall state per IP. Look for a rule that covers your game port, 30120 by default.

    What to do

    Add or correct the rule for your game port on that IP and on every additional IP that serves players. Rules apply a few minutes after saving.

  5. The player’s side: VPN or home network

    Owners report

    The client prints this message for whichever server it was joining, so a player whose UDP cannot leave their network sees it everywhere (our reasoning from the client code). In the one forum thread we read, a poster reports a VPN that needed its UDP option switched on, and another that the error appeared behind a router and not when connected straight to the modem.

    How to confirm

    Try other servers, a phone hotspot, the VPN off (or on: another poster says a VPN fixed it), then the PC plugged straight into the modem.

    What to do

    Change one thing at a time. If a whole region fails, go back to causes 1 to 4.

  6. A DDoS, or a host mitigation dropping UDP

    Our inferenceThe DDoS case

    A flood aimed at the game port can leave the UDP request unanswered, and a host’s mitigation can drop legitimate UDP while it filters (OVHcloud’s guide asks owners who see false positives to contact support). We rank it last because the HTTP stages passed first, and a flood heavy enough to disrupt UDP replies would, in our reasoning, usually disturb them too; a UDP-only flood or filter would not, which is why it stays on the list.

    How to confirm

    Look for the outside evidence in the next section.

    What to do

    Note the times, collect that evidence, then contact your host with the destination IP, protocol and port, and whether legitimate traffic is dropped.

What a DDoS looks like here

This message alone never proves an attack: you need a record made outside the game, by your host or at the network interface.

What a DDoS looks like here

  • Your host reports an attack on the IP players connect to, at the times of the failures, by e-mail or in its dashboard.
  • The HTTP stages fail too (Failed to fetch /info.json to obtain policy metadata., or http://IP:port/info.json stops loading from outside), although a UDP-only attack can leave them working.
  • Inbound packets per second far above a quiet-day baseline, or captured UDP to the game port from many scattered sources, far more than your player count.

Evidence you can collect

  • The host’s record

    Ask for the times, destination IP and attack vectors (on OVHcloud, the scrubbing centre log columns Detection time, End time, Destination IP and Attack vectors) and save them promptly: one year of retention for that log, two months for the traffic chart. Source addresses are not shown, as they are usually spoofed: there is nothing to ban.

  • Packet rate at the interface

    Compare rxpck/s, the inbound packets per second, against a baseline taken on a quiet day (first line Linux, second Windows PowerShell).

    sar -n DEV 1 10
Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

  • Who is sending

    With root, capture 2,000 packets to the game port and read the source column: a handful of addresses matching your players is normal, many scattered sources is not. The capture shows only what survives your host’s filtering, so a quiet one proves nothing while the host is scrubbing.

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

What it does not look like

  • (attempt 2) and (attempt 3) after Fetching info from server...: the normal retry sequence, not a flood.
  • Failures limited to players on one provider, VPN or router: that points to cause 5, not to your server’s path.

When protection is, and is not, the answer

Protection is the answer when

  • Your host’s dashboard or notice shows an attack on the IP players connect to, at the times of the failures.
  • A capture shows UDP to the game port from many scattered sources, far more than your player count.

Protection is not the answer when

  • endpoint_add_udp is missing or on another port than TCP.
  • UDP 30120 is closed on your router, system or host firewall: a proxy only moves the hop, and the new hop needs the same rule.

If the path to your server is under attack

When your host’s record or a capture shows an attack, the error is a symptom and the fix lies upstream: the traffic must be filtered before it reaches the address that answers players. Do not restart repeatedly or publish a new IP.

Put a proxy that carries TCP and UDP in front of the server, restrict the origin so only the proxy can reach it, then rotate the origin IP. Test the UDP hop with steps 3 and 5 first: an unconfigured UDP leg produces this very error.

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.

FiveM anti-DDoS: how FiveShield works

Still stuck? What to post

Replace your public IP with a placeholder if the thread is public, and never post passwords or your license key.

  • The exact message players see, your FXServer build and your txAdmin version.
  • Your endpoint_add_tcp, endpoint_add_udp and sv_endpoints lines, and the output of ss -lunp or Get-NetUDPEndpoint -LocalPort 30120.
  • The Direct Connect result from outside, twenty lines of the step 5 capture with players’ addresses masked, and the times of the failures with your time zone.
  • With a proxy: its type and UDP configuration. With a host firewall: whether Default Deny is on, and the rules for the IP players use. Any host notice.

Frequently asked questions

Does Failed to get info from server mean I am being DDoSed?

Not by itself. Four UDP getinfo requests got no accepted answer after the HTTP stages worked: look first at the UDP port, endpoint_add_udp, a proxy or a host firewall. An attack needs evidence from outside your machine.

After I put a proxy in front of my server, every player gets this error. Why?

Every stage before the UDP request runs over TCP: a relay that forwards TCP but not UDP lets them all through. Check cause 3: a raw UDP relay on matching ports, an sv_endpoints that names the address players should use, and an origin firewall that accepts UDP from the relay.

How is this different from Failed to connect to server after 3 attempts?

A different stage: that message comes from the ENet connect, one stage later, so the getinfo was answered. Start with the same path checks; the documentation does not list its causes separately.

Verified against, and sources

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

Sources from companies that compete with FiveShield are named, with their domain, but not linked.

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