Configure FiveM endpoints and resource start order
FiveM can read several configuration files, especially when txAdmin profiles or exec includes are used. Before changing endpoints or resource order, identify the file the running profile executes. Editing an unused copy explains many cases where a saved setting appears to do nothing. Keep a private backup of the active file and any included files.
Use the allocation you were given
The familiar FiveM port 30120 is an example, not permission to use it on every service. Match the game port assigned to your server. The two lines below are a template: replace ASSIGNED_GAME_PORT with the same numeric allocation in both lines before saving.
endpoint_add_tcp "0.0.0.0:ASSIGNED_GAME_PORT"
endpoint_add_udp "0.0.0.0:ASSIGNED_GAME_PORT"
A wildcard bind address means interfaces available inside the server environment. It is not a join address and does not open a provider firewall. In a container, the public IP may not exist directly inside the container, so forcing FXServer to bind that public address can fail. Keep the host-provided bind arrangement unless support confirms a change. Current Enhanced documentation limits each endpoint type to one; do not copy old multi-endpoint configurations without checking your branch.
Build an explicit startup chain
Settings required during resource initialisation belong before the relevant ensure lines. For a database-backed custom resource, a simplified chain is:
# Connection setting is private; supply real values separately.
set mysql_connection_string "REPLACE_WITH_PRIVATE_CONNECTION_STRING"
ensure oxmysql
ensure example_framework
ensure example_job
This illustrates dependency order, not a complete ESX or QBCore installation. Use the recipe matching your framework release. Start the database adapter before the framework, then framework-dependent jobs and interfaces. Avoid relying on the order of unrelated resources inside a bracketed category. If a specific resource needs another, make the dependency explicit in its manifest when you control the code.
Find duplicate or conflicting settings
Inspect the main file and every exec include for repeated endpoint, key and connection assignments. Check whether the hosting startup process writes values automatically. Preserve a single authoritative location for each setting. Do not paste an entire internet sample over your current configuration: examples can change ports, database names, game builds, permissions and resource sets all at once.
Use ensure carefully. Issuing it for an already running resource restarts that resource, which can interrupt players or discard unsaved script state. Use a planned full restart for changes to a framework's boot sequence rather than restarting core components underneath dependent scripts.
Verify from startup through joining
After a maintenance restart, watch for binding errors and the first failed dependency. Confirm database readiness, then framework readiness, then the dependent feature. Test a real external connection to the assigned public address. If the server starts correctly but cannot be reached, collect the address, port and timestamp for network diagnosis; changing resource order will not repair a blocked UDP allocation.
Keep RCON disabled unless you have a specific secured management requirement. Do not publish your full configuration in a support thread: remove licence keys, database passwords, bot tokens and webhooks from any excerpt.
Related guides
Further reading
Looking for another game? Browse game server setup and troubleshooting guides.