For a FiveM connection failure, keep the exact error and check whether you can join another server. A refused connection, timeout, whitelist rejection and resource-download failure require different fixes.
Start with the visible symptom
Connection refused: the selected endpoint may have no listener or the server may be stopped. Timeout: investigate reachability or a stalled server. Whitelist/ban/entitlement message: follow the named access or ownership process. Failure while downloading a named resource: preserve that resource and error for staff.
Use the community’s current official join link or endpoint. Old listing links and copied IP addresses can point to a retired server.
Player checks
- Record the server, time and full error. Check the community’s status announcements and Cfx.re service status.
- Try another known server. If it works, report the failure to the original server’s staff before changing your whole PC network configuration.
- Restart the official client once and verify that GTA V and FiveM have completed required updates.
- If you use a VPN or a restricted school/work network, compare with an authorized ordinary connection where available. Ask the network owner about the actual required traffic; do not bypass its policy.
- Use targeted cache recovery only when the error identifies a downloaded/cached resource issue. It does not fix a closed game port.
Administrator checks
Confirm FXServer is running and listening on the configured TCP and UDP game endpoint. Compare server.cfg, host allocations, NAT and firewall rules. The common default is port 30120 for both protocols, but use your actual allocation.
Keep management access separate and restricted. The Cfx.re proxy documentation explains the HTTP connection and raw game paths; a normal web proxy does not automatically carry game UDP traffic.
Use a narrow reachability test
In Windows PowerShell, this checks only TCP to your actual server hostname. Replace the example hostname and port:
Test-NetConnection -ComputerName game.example.com -Port 30120A successful TCP result does not prove UDP connectivity or a working player session. Check a real client connection and server logs as well. Intermediate traceroute loss can reflect rate-limited diagnostic replies; different DNS answers can reflect caching or distribution and do not by themselves prove an attack.
Verify one targeted repair
Change only the endpoint, rule or resource demonstrated to be wrong. Preserve the previous configuration. Retry from the affected client and a second permitted connection, then confirm normal resource loading and player state.
Do not disable request-security controls, alter system-wide IPv6/MTU settings or increase slots and retries as generic repairs. If the failure persists, share a redacted error and timestamps with the responsible host or Cfx.re support.