Fixing Empyrion server lag starts with identifying where the delay occurs: the player’s computer, the local network, the internet route, or the dedicated server simulation. Test in that order before changing settings. A loopback connection to 127.0.0.1, followed by a LAN test and then a public-address test, quickly separates server-process failures from router and internet problems. For missing servers, verify the live Srv_Port value in dedicated.yaml or your host panel and match it in the router and firewall. For everyone experiencing stutter or disconnects, record CPU, RAM, active players, active and reserved playfields, and the affected playfield’s memory use. Individual players should verify Steam files, check security software exceptions, and collect logs and DxDiag data.
What causes Empyrion server lag and connection failures?
Empyrion problems that look identical in play can have completely different causes. A player may have high network latency while the server is running normally; the server may be overloaded while every player has a good ping; or a blocked port may prevent anyone from joining even though the game process is healthy.
Empyrion supports self-hosted and rented dedicated servers, so the responsible component may be a game client, a home router, an upstream internet path, a host firewall, or the server machine itself. Classify the symptom before applying a fix.
| What you see | Most likely area to test first | Useful evidence |
|---|---|---|
| Only one player freezes, rubber-bands, or disconnects | That player’s Wi-Fi or wired route, firewall, ISP, and client installation | Ping behaviour, whether other players remain stable, client log and DxDiag |
| All players lag or disconnect together | Dedicated-server process, host CPU/RAM, playfield load, and server logs | Telemetry captured during the incident, player count, active/reserved playfields |
| Server is absent from the browser or direct connection fails | Configured port, router forwarding, operating-system firewall, and server binding | Current dedicated.yaml or panel port, local/LAN/public test results |
| Lag occurs only on one planet or near one large base or ship | Affected playfield’s entities, blueprint size, memory use, and configuration limits | Playfield name, memory size, build/entity load, and whether other playfields are normal |
Is this high ping, client stutter, or server simulation lag?
High ping is network latency: the time required for data to travel between a client and the server. It can produce delayed interactions and disconnects, but it does not prove that the server simulation is overloaded. Simulation lag is usually shared by players in the same session and often appears when CPU, memory, entities, or a busy playfield reaches a limit.
Signs of a network or ping problem
- Only one player is affected while others continue normally.
- The problem follows the player to different servers or disappears when switching from unstable Wi-Fi to a wired connection.
- Actions arrive late, voice or other internet services also show instability, or the player disconnects without a corresponding server spike.
Signs of server-side overload
- Several players report the same slowdown at the same time.
- The issue is concentrated around a large ship, base, or a single playfield.
- CPU or RAM usage rises during the incident, or server logs show repeated warnings and connection losses.
Do not change heartbeat or ping-kick values merely to hide a performance problem. Those controls can change when a player is removed, but they cannot create CPU capacity or repair a broken route.
How do I isolate the failing part of the connection?
Run three connection tests from the closest point outward. Record whether each test succeeds and which address and port you used. A successful test proves only that the layers inside it are working; it does not prove that the next layer is configured correctly.
- Test on the server machine. Start the dedicated server and connect to
127.0.0.1when the game and server are on the same computer. Loopback bypasses the router and external internet. If it fails, investigate the server process, its configuration, or the local firewall before touching port forwarding. - Test from another device on the same LAN. Use the server computer’s private address, such as its current
192.168.x.xor10.x.x.xaddress, together with the port shown in the installed configuration. If loopback works but LAN does not, check the operating-system firewall, the server’s bind address, and whether the router isolates wireless clients. - Test from outside the LAN. Use the public address and the exact port displayed in the current
dedicated.yamlor host panel. If LAN works but this test fails, concentrate on router forwarding, the public address, upstream filtering, and the host firewall.
Perform the outside test from a genuinely external connection, such as a phone hotspot, rather than from another device on the same home network. Some routers do not support hairpin NAT, so an internal attempt to reach your own public address can fail even when outside players can connect.
What ports does Empyrion use?
Use the values in the server build you actually installed. Community dedicated-server documentation commonly shows Srv_Port set to 30000 and recommends forwarding 30000–30004 for both UDP and TCP. A separate Steam setup guide documents port 30000 on both protocols. These are practical starting points, not a guarantee that every host panel or packaging uses the same range.
| Configuration item | Documented value | How to apply it safely |
|---|---|---|
Srv_Port |
30000 in common dedicated-server guidance |
Read the installed dedicated.yaml or panel first; use that live value |
| Forwarding range | 30000–30004 in one community guide |
Forward the documented range to the server computer’s private IP over UDP and TCP when the build requires it |
| Single-port setup | 30000 over UDP and TCP in another setup guide |
Use the narrower rule only when the current guide or host panel specifies it |
| Other container or package conventions | Some third-party packages report 27015/27016 |
Do not copy these values blindly; packaging and version can change the required ports |
Forwarding means sending traffic arriving at the router’s public address and port to the server computer’s private address and matching port. Give the server computer a DHCP reservation or static private address first; otherwise a router reboot can assign a new address and silently break the rule.
How do I configure router and firewall rules?
- Open the server configuration or host panel and note the exact port, protocol, and any additional ports it lists.
- Reserve the server computer’s current private IP in the router’s DHCP settings.
- Create a port-forward rule from the public interface to that private IP. Select UDP and TCP when the server instructions require both; do not assume a UDP-only rule is sufficient.
- Allow the same executable or port through the operating-system firewall on the server computer. A router rule cannot override a blocked local firewall rule.
- Restart the dedicated server, then repeat the loopback, LAN, and external tests. Test from outside the LAN to avoid hairpin-NAT limitations.
Check for double NAT when the server is behind an ISP gateway and a second personal router. The forwarding rule must exist on the device that owns the public address, or traffic must be passed from the gateway to the second router and then to the server. Carrier-grade NAT can prevent inbound connections entirely; in that case, ask the ISP whether a public IPv4 address or an alternative hosting arrangement is available.
How can I tell whether the dedicated server is overloaded?
Measure the server while the lag is happening, not several hours later. Capture CPU and RAM usage, active player count, active playfields, reserved playfields, and the affected playfield’s memory size. These are the details requested by Eleon when investigating connection loss, lag, and overall poor performance.
Capture useful telemetry
- Note the exact incident time and the game and server build.
- Record total CPU utilization and, where available, per-process usage for the Empyrion server.
- Record total RAM consumption and whether the operating system is paging or running out of available memory.
- List active players, active playfields, reserved playfields, and the name and memory size of the affected playfield.
- Mark whether the slowdown affects every playfield or only one location.
A high CPU reading that coincides with every player’s slowdown points toward simulation or host capacity. High memory use, paging, or a steadily growing process suggests a memory pressure problem. Low resource use during the incident makes a network path, firewall, or client-specific cause more likely, although short spikes can be missed if monitoring is infrequent.
Why does one planet or large build cause lag?
A single playfield can be heavier than the rest because of its entities, active structures, scripts, or unusually large blueprints. Compare its memory use and build/entity load with a quiet playfield while keeping the player count in mind. If the same group of players lags only near one structure, move away or temporarily load a different playfield as a controlled test.
Practical tests for a heavy playfield
- Ask affected players whether the slowdown begins at a repeatable location.
- Compare the playfield’s memory and entity counts with another playfield at a similar player count.
- Temporarily remove or disable the suspected large structure in a backup save, then test the copy rather than risking the live world.
- Review configuration limits and server logs for repeated warnings associated with the playfield.
Large blueprints can have a strong performance impact. Avoid increasing administrative kick thresholds to compensate for a build that consistently overwhelms the simulation; first reduce the load or move the build to a better-sized environment.
How do I fix an Empyrion client that disconnects or stutters?
When one player is affected, complete client checks before changing server settings. Steam can repair missing or damaged files, while security software can block the game or its network traffic.
- In Steam, open Library, right-click Empyrion – Galactic Survival, choose Properties, open Installed Files, and select Verify integrity of local game files. Wait for the process to finish, then restart Steam and the game.
- Check antivirus and firewall history for blocked Empyrion executables or connections. As a temporary diagnostic, add the Empyrion installation folder to the product’s exception or allow-list, then retest. Remove the exception if it does not change the result or if your security policy does not permit it.
- Update the network adapter driver and reboot the router and computer. Test with Ethernet if Wi-Fi signal quality or interference is suspected.
- Collect the client log from the game’s
Logsfolder and create a DxDiag report. Include the time of the failure so errors can be matched to the correct session.
Do not delete saves or configuration files as a first response. Preserve them until logs have been copied and a reproducible backup exists.
What causes high ping, and will Ethernet fix it?
Latency depends on connection quality, ISP performance, firewall configuration, protocol behaviour, and geographic distance between the player and server. A Cat6 Ethernet cable is a reasonable diagnostic option when Wi-Fi variability is suspected, because it removes wireless interference and roaming from the test. It will not fix server simulation overload or a distant, congested internet route.
Reduce avoidable latency
- Compare the same server over wired Ethernet and Wi-Fi at the same time of day.
- Stop large downloads, cloud synchronisation, and video uploads on the local network.
- Test another server region to determine whether distance or a particular route is responsible.
- Check that firewall or security software is not inspecting or blocking the game’s traffic.
- Ask the ISP about packet loss, carrier-grade NAT, or routing problems when outside tests fail consistently.
If ping is stable but the game world pauses for everyone, stop tuning the player’s connection and return to server telemetry. If ping spikes only for one player, preserve the timestamps and compare them with router or ISP diagnostics.
When should I move to a different server host?
A host change is justified when evidence shows inadequate CPU or RAM, consistently poor routing from the host’s location, insufficient player capacity, or support that cannot provide logs and recovery help. It is not a first-line cure for a blocked local port, damaged client files, or a single oversized playfield.
| Hosting factor | Questions to ask before moving |
|---|---|
| Location and routing | Is the data center close to most players, and can the provider explain packet loss or recurring route problems? |
| Resources | Are CPU shares, RAM, storage type, and process limits documented rather than described only as an equal number of slots? |
| Capacity | Does the plan support the intended player count, active playfields, and reserved playfields without aggressive throttling? |
| Backups | Can you download savegames, schedule backups, and restore a known-good version? |
| Support | Will support review server logs, telemetry, and port rules, and can you reach them during the affected hours? |
| Network controls | Can you set or verify the required ports, protocols, firewall rules, and public address? |
Before migrating, export the savegame and configuration, record the current build, and test the new server with a copy of the world. Keep the original instance available until players can connect, the expected playfields load, and a backup restore has been verified.
What logs and details should I send for support?
A useful report lets the recipient reproduce the failure and match it to server events. Save and exit the server safely before collecting files when possible.
- Client log from the game’s
Logsfolder. - Dedicated-server logs from
Empyrion - Dedicated ServerLogs<build number>. - Crash folders and a DxDiag report when the game crashes or fails to start.
- The server savegame, preferably from a backup made before making changes.
- CPU and RAM telemetry captured during the incident.
- Active player count, active and reserved playfield counts, affected playfield name, and its memory size.
- Game and server build, exact incident time, reproduction steps, and whether loopback, LAN, and public tests produced different results.
Describe one symptom per report: for example, “all players lost connection at 20:14 UTC on one playfield” is more actionable than “the server is bad.” Include the configured port and whether the router and operating-system firewall rules match it, but redact public credentials and unrelated personal data.
What should I change first?
Start with isolation, not guesswork. Confirm whether the server accepts loopback connections, then test from the LAN and from outside it. Read the live port setting, match the router and firewall rules, measure CPU/RAM and playfield load during the incident, and only then change client settings, administrative thresholds, or hosting.
Frequently Asked Questions
Why can friends not see my Empyrion server even though I can join it?
A local join proves the server process is running but does not prove that internet traffic reaches it. Check the public address, forwarding target, operating-system firewall, double NAT, and whether your ISP uses carrier-grade NAT; then test from a genuinely external connection.
Does restarting the Empyrion server permanently fix lag?
A restart can temporarily clear a stuck process or memory pressure, but it does not identify the trigger. Save the world, capture logs and telemetry around the next occurrence, and compare player and playfield counts before relying on restarts.
Can changing the ping-kick setting stop disconnects?
It can alter the threshold at which an unresponsive client is removed, but it cannot lower latency or repair packet loss. Change it only after confirming that the route is healthy and the server has enough CPU and memory.
How do I know whether my ISP or the game server is at fault?
Compare your connection with another server or an external network test at the same time. If only one destination or route shows loss, provide timestamps and results to the host or ISP; if every server is affected while others remain stable, investigate your local connection first.