Minecraft “lag” has three different causes: low server TPS, low client FPS, or a slow and unstable network path. The fix depends on which measurement is failing. A server targeting 20 ticks per second (one tick every 50 milliseconds) can still feel fine on a modest computer, while a high-end computer can render smoothly on a server that is timing out. Start by recording TPS, FPS, ping, the exact disconnect message, your Java or Bedrock edition, versions, and active mods or plugins. Then change one variable at a time so you can connect an improvement to its cause.
This guide separates those symptoms and gives a practical order for diagnosing low TPS, low FPS, high ping, rubber-banding, and failed joins.
Why is my Minecraft server lagging?
First identify whether the delay is on the server, on your computer, or between the two. The symptoms overlap, but the measurements and remedies do not.
| Symptom | What is actually slow | What to measure | Typical clues |
|---|---|---|---|
| Server lag | The server cannot finish its game tick work in time. | TPS while the problem is happening. | Actions feel delayed for everyone, mobs and redstone pause, and the whole server may stutter. |
| Client lag | Your computer is rendering frames slowly. | FPS on the affected computer. | The view looks choppy for one player while other players and the server continue normally. |
| Network lag | The route between player, internet service provider, and server is slow or unstable. | Ping, connection bars, packet-loss symptoms, and disconnect text. | Rubber-banding, delayed block updates, sudden teleports, or timeouts. |
Exaroton’s support documentation describes Minecraft’s operational target as 20 TPS: one tick every 50 milliseconds. TPS below 20 means the server is falling behind; it does not prove that your computer or internet connection is at fault. The same documentation treats FPS below 30 as noticeably laggy on the client side, a rendering heuristic rather than a server requirement.
Check TPS during the exact event that feels slow. A server can be healthy at idle and fall behind only when players explore new terrain, activate a large farm, or load a redstone-heavy area. Likewise, a ping spike can occur while TPS remains at 20.
How do I diagnose low TPS, low FPS, and high ping?
Use this sequence before changing several settings. Keeping a short record prevents a server-setting change from hiding the original cause.
- Record the baseline. Note TPS, FPS, ping or connection bars, the exact disconnect text, Java or Bedrock edition, server and client versions, and every active mod or plugin. Save a copy of
logs/latest.logbefore reproducing the issue. - Reproduce one symptom. Write down what the player was doing: entering a new area, loading a farm, fighting mobs, or simply joining. Have another player report whether the same delay occurs at the same time.
- Branch on the measurement. TPS below 20 points to server work; low FPS with normal TPS points to the client; high or unstable ping points to the route. A timeout or failed join requires the connection checks later in this guide.
- Change one variable. Apply one setting or hardware change, repeat the same activity, and compare the measurement. Reverting a change that does not help keeps the diagnosis reproducible.
A useful control is to have one player remain in an already generated area while another explores. If only exploration triggers the TPS drop, chunk generation is a stronger suspect than graphics settings. If only one player sees the problem, compare that player’s FPS and network path with someone who is unaffected.
How do I fix low server TPS?
When TPS falls below 20, reduce the amount of work each tick must complete and identify the activity that creates the spike. These changes trade simulation or exploration range for more consistent tick time, so test them against the way your server is played.
Lower view and simulation distance carefully
Set view-distance to 8–10 chunks and simulation-distance to 5–6 as starting points. View distance controls how far terrain is sent to players; simulation distance controls how far entities and game logic continue to run. Lowering simulation distance can reduce entity and redstone work, but players will notice that activity farther away stops updating until they approach it.
Change one setting first, reproduce the same load, and watch TPS. If the improvement is small, restore the first value before testing another so you know which trade-off helped.
Pre-generate the world
Exploring unexplored terrain generates chunks and can create a short, severe tick spike, especially when several players travel in different directions. Pre-generate the areas your community expects to use, then test exploration outside that prepared region. This shifts the expensive work away from live play; it does not remove the storage and CPU cost of a larger world.
Reduce entity and redstone load
Inspect farms, item sorters, villager halls, mob concentrations, and always-on redstone machines in the area where TPS drops. Temporarily disable one machine or move one farm away from the busiest base, then repeat the test. If TPS recovers, redesign the system rather than raising every server limit at once.
Isolate mods and plugins
Use the log and your activity record to identify errors or repeated warnings. Disable one mod or plugin at a time on a test copy, restart, and reproduce the same scenario. Removing several at once may fix the symptom but leaves you without evidence about which component caused it. Confirm that every mod, plugin, and loader supports the exact server version you are running.
Inspect memory without assuming RAM is the bottleneck
Watch memory usage while the lag occurs and check for allocation failures or repeated garbage-collection pauses in the log. More RAM cannot make a single tick complete faster when the workload is dominated by entities, redstone, or chunk generation. Increase allocation only when monitoring shows the server is actually exhausting its available memory, and retest after the change.
How do I fix low FPS when the server TPS is normal?
If TPS stays near its target but your frame rate is low, the server is not the first place to make changes. FPS is the number of frames your computer renders each second; Exaroton’s guidance treats values below 30 as noticeably laggy.
- Update the operating system and graphics driver. Install the current driver supplied for your GPU and restart before testing again.
- Use current Minecraft software. Confirm that the launcher, game version, mod loader, and performance mods are compatible rather than mixing files from different versions.
- Adjust video settings. Reduce render distance, particles, entity shadows, and other settings that increase rendering work. Test at the same location and camera angle so the comparison is meaningful.
- Disable mods temporarily. Start an unmodded profile or a clean test instance. If FPS returns, re-enable visual or gameplay mods one by one until the expensive component is identified.
- Compare with another world or location. A dense base, many entities, or weather effects can lower FPS in one area while the same computer performs normally elsewhere.
Do not lower server simulation distance to cure a client-only frame-rate problem unless the measurements also show a TPS issue. The two settings affect different bottlenecks.
How do I fix high ping, rubber-banding, and unstable connections?
High ping is a route problem, not a bandwidth score alone. The path from your computer through your internet service provider to the machine hosting the server can be geographically long, congested, or unstable. A fast internet plan cannot guarantee a short or reliable route.
Stop competing traffic
Pause downloads, cloud synchronization, video uploads, game updates, and other bandwidth-heavy applications on the local network. Test again while the server and Minecraft client remain unchanged. If the spikes disappear, schedule those transfers away from play or configure traffic prioritization on the router.
Check geography and routing
Record where the server is hosted and where each affected player connects from. A player far from the data center may have consistently higher latency than a nearby player even when both have fast internet. If only one region or ISP reports spikes, the route rather than the server process is the leading suspect.
Inspect the router and local link
Restart and update the router, check for overheating or overloaded wireless channels, and test from a location with a strong signal. Then connect the client directly with Ethernet, using a suitable Cat6 cable if necessary, while keeping the same server and computer. This wired test isolates Wi-Fi variability; it cannot repair low server TPS or congestion on a distant route.
Compare several players
Ask players in different locations to join during the same event. If everyone rubber-bands together while TPS drops, investigate the server workload. If one household alone sees spikes, focus on that household’s Wi-Fi, router, or ISP path. If players in one geography are affected, compare the route and data-center distance before changing world settings.
Why do I keep timing out or failing to join my server?
A join failure can occur before the game reaches the world, so check the process, address, port, firewall, and version in that order.
- Confirm that the server process is running. Check the console or hosting panel for a completed startup and look at
logs/latest.logfor a crash, bind failure, or mod/plugin error. - Verify the address and edition. Java and Bedrock use different server software and default ports. Make sure the player is using the address intended for that edition, not a saved address from another world or host.
- Forward the correct protocol and port. Java’s default is TCP port 25565. Bedrock’s default is UDP port 19132. Confirm the edition and any custom
server-portvalue before creating a router rule; forwarding the wrong protocol will not expose the server. - Allow the process through the firewall. Permit the server application and the selected port on the host operating system and router. Recheck the rule after changing the server port or moving the installation.
- Check version compatibility. The client, server, loader, mods, and plugins must support the same game version. Read the log for explicit mismatch or handshake errors instead of repeatedly retrying.
- Test from outside the home network. A local address may work from inside the house while the public address fails, or a router may not support connecting back through its public address. Use a separate network for the test and record the exact result.
Magma Foundation documentation specifically notes that network instability and high server lag can both cause disconnects. Therefore, a timeout does not automatically prove that port forwarding is wrong; check TPS and the server log at the same moment.
What should I do when a Bedrock hostname works inconsistently?
Bedrock dedicated servers can fail only when players use a hostname or when DNS returns multiple addresses. In that case, investigate the firewall’s handling of connection probes and the server build, not just the player’s Wi-Fi.
Check whether the hostname resolves to more than one address and whether the firewall treats an initial probe as invalid or unsolicited. Reproduce with the direct address and with the hostname, saving the timestamps and log entries for each attempt. Where the documented issue applies, update to a Bedrock server build containing the 26.40 timeout fix. Confirm the fix against the exact build and operating system you use; the version number is not a universal remedy for unrelated DNS or firewall errors.
Is my home hardware the problem, or should I use managed hosting?
Home hosting can work well when the CPU, memory, network route, and administration are under control. Managed hosting is worth comparing when your home connection is unstable, the data center is far from players, or you cannot maintain backups and version compatibility yourself.
| Decision factor | Home hosting | Managed hosting |
|---|---|---|
| CPU | Depends on your machine’s single-thread performance and what else is running on it. | Compare the provider’s single-thread performance claims and whether resources are shared. |
| Memory | You choose the allocation and must leave enough for the operating system. | Compare included RAM, upgrade options, and any allocation limits. |
| Player and world load | You control farms, exploration, simulation distance, and mod count. | Check the advertised player capacity against your world activity, not just a slot number. |
| Geography and routing | Players connect to your home ISP and its route. | Choose a data-center region close to most players and verify network stability. |
| Administration | You handle firewall rules, updates, backups, logs, and restarts. | The host may provide a panel, automated tasks, and support; read exactly what is included. |
| Mods and plugins | Full control, but you must resolve loader and version conflicts. | Confirm supported Java or Bedrock editions, loaders, versions, and installation limits. |
| Backups and recovery | You must create and test your own backup copies. | Check backup frequency, retention, restore process, and whether backups are stored separately. |
| Cost | Uses existing hardware and internet capacity, with possible electricity and upgrade costs. | Recurring fees vary by CPU, RAM, location, storage, and support; compare like-for-like resources. |
For Bedrock, Minecraft Wiki guidance lists at least 1 GB of RAM as a baseline and 4–8 GB for very large servers. Treat those figures as starting references, not guarantees: player count, world activity, entities, and mods determine the actual requirement. No universal bandwidth figure or hardware specification guarantees lag-free play for every world.
Which fixes should I avoid applying blindly?
- Adding RAM without measuring memory pressure. It does not solve a CPU-bound tick, an overloaded farm, or a bad network route.
- Buying a faster internet plan as the first response. Higher advertised bandwidth does not shorten a congested or geographically long path.
- Forwarding every port. Use the correct edition, protocol, and configured port, then limit firewall exposure to what the server needs.
- Changing many settings simultaneously. You lose the ability to tell whether view distance, a plugin, a router change, or something else made the difference.
- Assuming a client utility can repair server lag. Driver and operating-system maintenance belongs in the FPS branch; it cannot raise server TPS or fix remote routing.
- Judging by feel alone. Capture TPS, FPS, ping, logs, and the exact disconnect text before deciding what to replace.
What is the fastest decision path for a lagging server?
Use the following branch whenever players report “lag” without a precise description.
| Observed result | Next action | Primary fixes |
|---|---|---|
| TPS below 20 during the event | Profile world activity and logs. | Lower view distance to 8–10 and simulation distance to 5–6, pre-generate chunks, reduce entity/redstone load, inspect memory, and isolate mods/plugins. |
| TPS normal, FPS below 30 for one player | Test a clean client profile. | Update operating system and graphics driver, use compatible current software, adjust video settings, and disable mods one by one. |
| TPS and FPS normal, ping unstable | Compare players and test Ethernet. | Stop background traffic, inspect router and Wi-Fi, compare geography and ISP routes, and test a nearer hosting region if necessary. |
| Players cannot join | Check process, edition, address, port, firewall, versions, and logs. | Use TCP 25565 for Java or UDP 19132 for Bedrock unless server-port is customized; correct mismatches before changing performance settings. |
| Bedrock hostname-only timeout | Compare direct address and hostname behavior. | Inspect DNS and firewall probes, then apply the documented 26.40 timeout-fix build where applicable. |
Keep the successful change and document the old and new value, the test scenario, and the measured result. That record makes the next incident faster to solve and prevents a temporary improvement from becoming an unexplained permanent configuration.
Frequently Asked Questions
Why does lag appear only when several players explore new areas?
Exploring different directions at the same time can trigger concurrent chunk generation, creating a short tick workload that an idle test never shows. Compare TPS while players remain in prepared terrain, then pre-generate the areas your group plans to visit and retest exploration.
Can a server have enough free memory and still run below 20 TPS?
Yes. Tick time can be dominated by single-thread work such as entities, redstone updates, or chunk generation while memory remains available. Measure the workload that coincides with the TPS drop instead of treating unused RAM as proof that the server is healthy.
Why do players in one city lag while players elsewhere do not?
Their internet providers may take different routes to the same machine, and those routes can differ in distance or congestion. Compare ping and rubber-banding from multiple locations during the same event before changing server settings.
What does a timeout tell me about the cause?
A timeout only says that the connection did not complete in the expected time. It can result from an unreachable port or firewall, an unstable route, or severe server lag, so match the timestamp with the server log and TPS measurement.
What information should I give a host or administrator when asking for help?
Provide the edition, exact client and server versions, address type (direct address or hostname), configured port and protocol, time of the incident, TPS/FPS/ping readings, affected locations, active mods or plugins, and the relevant section of logs/latest.log. This lets support distinguish a version or firewall error from a performance spike.