Vintage Story Server Troubleshooting

Most Vintage Story server problems fall into five buckets: connection issues, lag, crashes, world corruption, and mod conflicts. Mods are the number one cause of basically everything going wrong, so if you've recently added or updated mods and something broke, start there.

Make sure you've read the Getting Started Guide and Configuration Guide first – a lot of the tickets we get turn out to be config issues.

Can't Connect to the Server

This is the most common support ticket we get, and it's almost never actually the server's fault.

Check the basics first:

1. Is the server actually running? Log into the LOW.MS Control Panel and check Current Activity & Stats. If it shows as stopped, start it from the Web Console.
2. Are you using the right address? The format is IP:42420. No http://, no slashes, just the IP and port separated by a colon.
3. Is the server still starting up? First boot or a world regeneration can take a few minutes. Watch the Web Console output – you're looking for the "Server now running" message.
4. Client version mismatch. Both the client and server need to be on the same Vintage Story version. This trips people up after game updates.

The TCP+UDP thing:

Since v1.20, Vintage Story uses both TCP and UDP on port 42420. This catches people who have custom firewall rules or are connecting through a VPN that only passes TCP traffic. On LOW.MS servers, both protocols are open by default, but if you're having intermittent connection drops or the client hangs on "Connecting...", a local firewall or VPN could be blocking UDP.

If you're on a corporate or university network, that's almost certainly the issue. Try from a different network to confirm.

Still can't connect?

Open a support ticket with your server IP and we'll check the server side. Sometimes a bad shutdown leaves a stale lock file that prevents the server from binding to the port properly – we can sort that out quickly.

Server Lag

Lag on a Vintage Story server usually manifests as block placement delays, rubber-banding, and mobs that stutter around. Here's how to track it down.

Step 1: Figure Out What Kind of Lag

Not all lag is the same.

• TPS lag (server side): the server can't keep up with processing. Block updates are slow, mobs behave weirdly, time feels like it's crawling. Run /debug logticks 100 from the Web Console to log any ticks that take longer than 100ms. This is your single best diagnostic tool.
• Network lag (ping): your connection to the server is slow. Players far from the server region will feel this more. Not much to do about physics here.
• Client lag (FPS): the player's computer is struggling. This isn't a server problem – it's their graphics settings.

Step 2: Check the Usual Suspects

Mods. I'm going to keep saying this because it's true – mods are the number one cause of server lag. We had a customer last month who couldn't figure out why their server was lagging with only 3 players. Turned out a worldgen mod was recalculating terrain data every tick for some reason. Removed the mod, instant fix.

If you've recently added mods and lag appeared around the same time, that's your answer.

Auto-save lag spikes. Vintage Story auto-saves the world periodically, and during that save the server pauses for 1-2 seconds. This is completely normal and happens to every VS server. There's no way to eliminate it entirely, but you can reduce the impact by keeping your world size reasonable and making sure you're not running low on disk space.

When the server is low on disk space, saves take dramatically longer because the OS has to work harder to find free blocks. I've seen save spikes go from 1 second to 15+ seconds on servers that were 95% full. Keep at least 20% of your disk space free.

Too many loaded chunks. If MaxChunkRadius is set high and you've got several players spread across the map, the server is loading and processing a huge number of chunks simultaneously. Drop MaxChunkRadius from the default 12 to 8 – most players won't notice the difference but your server will thank you. See the Configuration Guide for details.

RandomBlockTicksPerChunk. This controls crop growth, grass spread, and similar random updates. The default of 16 is fine for small servers but becomes a real burden with more players. Try 8 or 10 if you're seeing tick time creep up in your /debug logticks output.

Entity overload. Too many mobs, dropped items, or animals in one area will tank performance. This is especially common on servers that have been running for a while without culling. The SpawnCapPlayerScaling setting (default 0.5) helps, but if you've got players running massive animal farms, that's going to hurt regardless.

Step 3: Use /debug logticks

This is worth its own section because it's the most useful diagnostic command in Vintage Story.

/debug logticks 100

This logs every server tick that takes longer than 100 milliseconds. Run it, let the server go for 10-15 minutes during normal play, then check the output in the Web Console or Log Viewer. It'll tell you exactly what's eating your tick time – chunk generation, entity processing, block ticks, or mod hooks.

Server Crashes

Out of Memory

If you see OutOfMemoryException in the logs, your server ran out of RAM. Vintage Story uses about 1 GB base plus 300 MB per player, but mods can push that much higher.

Check your actual usage in Current Activity & Stats on the control panel. If you're consistently hitting your RAM limit, it's time for a bigger plan. Check our Vintage Story plans.

Disk Space

Running out of disk space during a world save is one of the worst things that can happen. The save gets interrupted partway through, and now you've got a partially written world file. That's corruption territory.

Vintage Story has a built-in safety setting for this:

"DieBelowDiskSpaceMb": 400

This tells the server to shut down cleanly if free disk space drops below 400 MB. I'd honestly set this to at least 500. It's much better for the server to stop gracefully than to crash mid-save and corrupt your world.

Similarly, there's a memory safety valve:

"DieAboveMemoryUsageMb": 3800

Set this to about 200 MB below your plan's RAM allocation. The server shuts down cleanly before it hits the hard limit and crashes.

Mod-Related Crashes

If your server crashes on startup after adding a mod, the fix is usually straightforward: remove the mod. Check the Log Viewer for the error – it almost always names the problematic mod in the stack trace.

If the server crashes randomly during gameplay, that's harder to pin down. Check the logs around the crash time and look for repeating error messages in the minutes leading up to it. Mods that modify world generation or entity behaviour are the most common culprits.

World Corruption

This is the scary one. Signs of world corruption include: chunks that won't load, the server crashing when a player enters a specific area, or blocks reverting to a previous state after restart.

Prevention

The best fix is not needing one. A few things that help:

• Always shut down the server with /stop or the Stop button. Never force-kill it.
• Keep disk space healthy – at least 20% free
• Set DieBelowDiskSpaceMb to 400-500 so the server stops before running out of space
• Use Cloud Backup in the control panel regularly, especially before updates or mod changes

CorruptionProtection

Vintage Story has built-in corruption protection:

"CorruptionProtection": true

Leave this on. It adds some overhead to saves but catches a lot of issues that would otherwise silently corrupt chunk data.

RegenerateCorruptChunks

"RegenerateCorruptChunks": true

When enabled, the server automatically regenerates chunks it detects as corrupted instead of crashing. You lose whatever was built in those chunks, but the server stays up and the world stays playable. It's a trade-off, but for most servers I'd recommend keeping it on.

Restoring from Backup

If corruption is widespread, your best bet is Cloud Restore from the sidebar in your control panel. LOW.MS runs automatic backups, so you should have recent restore points available. Pick the most recent backup from before the corruption started and restore from there.

Mod Conflicts

When mods fight each other, you get anything from minor visual glitches to hard crashes. Here's how to sort it out.

The Disable-and-Test Method

This is tedious but it works every single time:

1. Stop the server
2. Move all mods out of data/Mods/ (use the File Manager to create a temporary folder like data/Mods_backup/)
3. Start the server. Does the problem persist? If yes, it's not a mod issue – look at your config or open a support ticket.
4. If the problem went away, add mods back in batches of 3-4
5. Restart and test after each batch
6. When the problem returns, you've narrowed it to the last batch you added. Now test those individually.

Common Mod Issues

• Version mismatches. A mod built for VS 1.19 might not work on 1.20. Always check the mod page for compatibility.
• Missing dependencies. Some mods require other mods to function. The error log usually tells you exactly what's missing.
• Duplicate functionality. Two mods that modify the same game system (like terrain generation or crafting) will often conflict. Pick one.

Checking Mod Load Errors

After any restart with new mods, check the Log Viewer immediately. Look for lines containing "error" or "exception" near the startup. VS is usually quite clear about what went wrong – "ModX requires ModY version 2.0 or higher" type messages.

You can also use the /moddb command in-game to see the status of loaded mods and check for issues.

Getting More Help

If you've worked through this guide and things still aren't right, open a support ticket with us. We're around 24/7. Include what you've already tried and paste the relevant section from your Log Viewer – it saves a lot of back and forth.