Game Server Troubleshooting Guide

Every game server hits problems eventually. Connection failures, lag spikes, mysterious crashes, and performance degradation are all part of running a server. The difference between hours of frustration and a quick fix often comes down to knowing where to look. This guide covers the most common game server issues across all games, how to diagnose them, and when to fix things yourself versus contacting your hosting provider's support team.

Connection Issues

Connection problems are the most frequent support requests for game servers. When players report they cannot connect, work through these checks in order.

Verify the server is actually running. Log into your hosting control panel and check the server status. It sounds obvious, but servers can stop without warning due to crashes, scheduled maintenance, or billing issues. If the server shows as stopped, start it and check the console for errors.

Confirm the correct IP address and port. Players often mistype the server address or forget the port number. The format is typically 123.456.789.0:25565 (IP colon port). Some games use separate ports for queries and connections. Double-check the address displayed in your hosting panel and send it to your players directly -- do not rely on memory.

Check if the port is accessible. Use an online port checker tool (search "port checker" or "can you see me") to verify that the server's port is open and responding. If the port shows as closed, the server process may have crashed silently, a firewall may be blocking the port, or there could be a networking issue on the host's end.

Firewall and whitelist settings. If you have enabled a whitelist or IP-based access control, verify that the connecting player is on the allowed list. For Minecraft, check whitelist.json and make sure the player's current username and UUID are listed. For other games, check the equivalent access control settings.

DNS resolution. If you use a custom domain (like play.yourserver.com) instead of a raw IP, verify that the DNS record points to the correct IP address. DNS changes can take up to 48 hours to propagate, though most resolve within minutes. Use nslookup play.yourserver.com to check what IP the domain resolves to.

Connection timeout errors typically indicate the server is unreachable at the network level. Causes include: the server is down, the port is wrong, a firewall is blocking the connection, or there is a network routing issue between the player and the server. Have the player try connecting from a different network (like mobile data instead of home WiFi) to rule out local network issues.

"Server is full" errors mean the server has hit its player slot limit. Increase the max player count in your server configuration, or upgrade your plan if your hosting limits concurrent players.

Performance Problems

Lag, rubber-banding, and low TPS are the issues that drive players away. Diagnosing performance problems requires understanding where the bottleneck is.

Server-side lag vs client-side lag vs network lag. These feel similar to players but have completely different causes. Server-side lag means the server cannot keep up with game simulation (low TPS in Minecraft, low server FPS in other games). Client-side lag is the player's computer struggling to render the game -- the server cannot fix this. Network lag (high ping) is caused by distance between the player and server, poor routing, or bandwidth saturation.

Diagnosing server-side lag. In Minecraft, use the spark plugin to check TPS and generate profiler reports. In other games, check the server console for tick rate or performance warnings. Most game servers expose performance metrics either through console commands or RCON. Key metrics to monitor:

• TPS (ticks per second): Minecraft targets 20 TPS. Anything below 18 is noticeable. Below 15 is severe lag.
• Tick time (MSPT): How long each tick takes to process. Must stay under the tick budget (50ms for Minecraft's 20 TPS).
• CPU usage: Sustained 90%+ CPU means the server needs more processing power or optimization.
• RAM usage: If RAM usage hits the allocation ceiling, the server thrashes between garbage collection and game simulation.

Common causes of server-side lag:

• Too many entities (mobs, items, vehicles) in loaded chunks.
• Unoptimized world generation when players explore new territory.
• Poorly written mods or plugins consuming excessive tick time.
• Insufficient RAM causing frequent garbage collection pauses.
• Too many players for the server's hardware tier.
• Redstone machines, mob farms, or other player contraptions creating excessive load.

Network lag diagnosis. Have affected players run a traceroute to the server IP (tracert <server-ip> on Windows, traceroute <server-ip> on Mac/Linux). This shows every network hop between the player and server and where delays occur. If the latency spike happens at the destination (your hosting provider), contact their support. If it happens at intermediate hops, it is a routing issue that usually resolves itself.

Rubber-banding (players snapping back to previous positions) is caused by the server correcting client positions when it cannot process movement fast enough, or by packet loss between the player and server. If only one player experiences it, the problem is their connection. If all players experience it, the server is lagging.

Crash Diagnosis

Server crashes are alarming but usually leave clear evidence of what went wrong. The key is knowing where to find that evidence.

Where to find crash information:

• Crash logs: Most games generate crash reports in a crash-reports/ directory. These contain stack traces that identify exactly which code path caused the crash.
• Server logs: The logs/latest.log or equivalent file shows everything the server printed before crashing. Scroll to the end and work backward to find the first error.
• Console output: If the server is running in a panel, check the console view for error messages that appeared before the crash.
• System logs: Your hosting panel may show OOM (Out of Memory) kills or other system-level events that caused the shutdown.

OutOfMemoryError is one of the most common crash causes. The Java Virtual Machine ran out of allocated heap space. Solutions:

1. Increase RAM allocation in your hosting panel.
2. Install memory optimization mods (FerriteCore for Minecraft).
3. Reduce loaded content (lower view distance, limit chunk loading).
4. Check for memory leaks using spark's heap dump analysis.
5. If you are already at maximum RAM for your plan, upgrade your plan.

Mod and plugin conflicts cause crashes when two modifications try to alter the same game system in incompatible ways. The crash log usually names both mods in the stack trace. Solutions: update both mods to latest versions, check their issue trackers for known conflicts, or remove one of the conflicting mods.

Corrupted save data causes crashes when the server tries to load damaged chunks, entities, or player data. Symptoms include crashes that happen at the same point during startup or when loading a specific area. Solutions: restore from backup, use repair tools specific to your game (like MCA Selector for Minecraft region files), or delete the corrupted data and let the server regenerate it.

Update-related crashes happen when you update the game, a mod, or a plugin without checking compatibility. The server log clearly states version mismatches. Solution: roll back the update, check compatibility, and update dependencies in the correct order.

Resource Monitoring

Proactive monitoring prevents most problems from reaching your players. Check these metrics regularly, not just when something breaks.

CPU usage patterns. Normal server CPU usage varies by game and player count, but watch for trends. If CPU usage has been climbing over weeks even with the same player count, something is accumulating -- entities, loaded chunks, or data that grows over time. Investigate before it causes lag.

RAM usage and garbage collection. For Java-based servers (Minecraft, etc.), RAM usage follows a sawtooth pattern: it climbs as objects are allocated, then drops sharply during garbage collection. This is normal. Problems arise when the drops do not bring usage back down to a reasonable baseline (indicating a memory leak) or when the sawtooth becomes very rapid (indicating insufficient RAM).

Disk usage. Server worlds grow over time as players explore. Logs can also accumulate. Check disk usage monthly and archive old logs. If your hosting plan has a storage limit, running out of disk space causes crashes and potential data loss. Clean up unnecessary files: old backups stored on the server, unused world files, and temporary data.

Network bandwidth. Most hosting plans include generous bandwidth, but large player counts or specific mods (like Dynmap tile serving) can create spikes. Monitor bandwidth to ensure you are not approaching your plan's limits.

Most hosting panels provide basic resource monitoring graphs. For more detailed monitoring, consider server management tools or plugins that track metrics over time. The spark plugin for Minecraft provides excellent profiling and monitoring capabilities.

Backup and Recovery

Backups are the single most important aspect of server administration that most people neglect until it is too late.

Automated backup schedule. Configure your hosting panel to create automated backups. At minimum, run daily backups. For active servers, every 4-6 hours is better. Keep at least 7 days of backup history -- a corruption issue might not be noticed immediately.

What to back up: World files (the entire world/ directory or equivalent), configuration files, plugin/mod data directories, and player data. Some hosting panels back up the entire server directory, which is simplest. If you configure backups manually, ensure you include everything needed to restore the server to its current state.

Test your backups. A backup you have never tested is not a backup. Periodically download a backup, set up a test server, and verify that it loads correctly. Nothing is worse than discovering your backups are corrupted or incomplete when you actually need them.

Recovery process: When disaster strikes, stop the server, upload your most recent clean backup, and restart. If the issue was a corrupted chunk or player data file, you can often do a targeted restore -- replacing only the damaged files from the backup while keeping more recent data for everything else.

Off-site backups. Keep at least one backup copy outside your hosting provider. Download backups to your local computer or a cloud storage service. If your hosting account is compromised or the provider has issues, you still have your data.

When to Contact Support vs Self-Fix

Knowing the boundary between "I can fix this" and "I need help" saves time.

Fix it yourself:

• Server configuration issues (wrong settings, missing plugins, config errors).
• Performance problems caused by in-game activity (mob farms, chunk loading, too many entities).
• Mod/plugin conflicts and crashes (the crash log tells you exactly what is wrong).
• Connection issues caused by whitelist, firewall settings, or DNS you control.
• World corruption where you have a backup to restore from.

Contact support:

• The server process will not start and the logs show no clear error.
• Network issues where the server's port is unreachable but the panel shows it running.
• Hardware-level problems (disk errors, memory errors reported in system logs).
• DDoS attacks causing connection floods.
• Billing-related server suspension.
• Panel or FTP access issues.
• Performance problems where your resource usage is well within limits but the server still lags (possible noisy neighbor on shared hardware).

How to contact support effectively: Include your server ID, the exact error messages or logs, what you have already tried, and when the issue started. Hosts deal with hundreds of tickets daily. A detailed ticket with logs attached gets resolved faster than "my server is broken please help."

Preventing Issues Before They Happen

The best troubleshooting is the kind you never have to do. These practices prevent most common problems.

Proper shutdown procedures. Always stop the server through the control panel or the correct in-game command (/stop for Minecraft). Killing the process or letting the hosting panel force-stop it risks world corruption. Save the world before stopping if your game supports it.

Regular backups. Already covered above, but worth repeating. Set up automated backups and verify them periodically.

Update testing. Never update your game server, mods, or plugins directly on a live server during peak hours. If possible, test updates on a separate staging server first. At minimum, create a backup immediately before updating, and update during off-peak hours when fewer players are affected if something breaks.

Monitor actively. Check your server's resource usage at least weekly. Set up alerts if your hosting provider offers them. Catch trends (rising CPU, growing disk usage, increasing RAM baseline) before they become problems.

Keep plugins and mods current. Outdated plugins are a common source of crashes and security vulnerabilities. Subscribe to update notifications for your critical plugins and update them regularly -- but always read changelogs and test after updating.

Document your setup. Keep a record of what plugins/mods you have installed, what versions they are, and what configuration changes you have made. When something breaks after a change, you can revert precisely instead of guessing.

Set resource limits. Implement player caps, world borders, entity limits, and chunk loading restrictions appropriate for your server's hardware. It is better to set limits proactively than to discover them when the server crashes from overload.

A well-maintained server with good monitoring and regular backups rarely has emergencies. Invest the time in prevention, and your troubleshooting sessions will be brief and infrequent.