By David Kim · Mar 4, 2026

Terraria's Network Architecture, Port 7777, and Why Monitoring Saves Worlds from Corruption

How does a game built around a single-threaded server process, using TCP instead of UDP, handle multiplayer at scale? Terraria's networking model is unusual among online games, and its design choices create specific failure patterns that most generic server monitoring guides never mention. Understanding the architecture explains why Terraria servers crash in ways that Minecraft, Valheim, or Rust servers do not, and what kind of monitoring actually helps.

Most multiplayer games use UDP for gameplay traffic because it is faster and tolerates packet loss gracefully. Terraria uses TCP. Most game servers use multithreaded architectures to handle player connections concurrently. Terraria's dedicated server runs on a single thread for game logic. Most games separate world state from network I/O. Terraria processes both on the same thread, meaning a network stall can delay game ticks and a slow game tick can stall network processing. These are not bugs. They are architectural decisions made for a game originally designed for small co-op groups of 4-8 friends. But they create specific vulnerabilities when you run a public server with 16 players, mods, plugins, and weeks of continuous uptime.

TCP-Based Protocol: What It Means for Server Stability

Most real-time multiplayer games use UDP (User Datagram Protocol) for player movement, combat, and world updates because UDP does not guarantee delivery or ordering. A dropped packet just means a skipped position update; the next packet corrects it. The game feels smooth even with moderate packet loss.

Terraria chose TCP (Transmission Control Protocol) instead. TCP guarantees every packet arrives, in order, with no duplicates. If a packet is lost, TCP retransmits it and holds all subsequent packets until the missing one arrives. This is called head-of-line blocking.

The consequences for server stability:

A single player's bad connection affects everyone. If one player has packet loss, TCP retransmissions create a backlog. Because the server processes connections on one thread, the retransmission delay for one player can slow down packet processing for all players. On UDP-based games, a player with packet loss just has a bad experience locally; on Terraria, they can cause server-wide lag.
Network congestion causes cascading delays. When the server sends a burst of data (world sync during events, boss fights with many projectiles), TCP congestion control throttles the send rate. The server's send buffer fills up. Because sending and game logic share a thread, the send buffer backup stalls game tick processing.
Disconnection detection is slow. TCP detects a dead connection through keepalive timeouts, which default to minutes. A player whose internet drops silently occupies a connection slot and associated resources for minutes before the server detects the disconnection. With 16 player slots and no timeout tuning, ghost connections can fill half your slots.
Large world syncs are expensive. When a new player joins, the server sends the entire visible world state over TCP. On a large world with extensive player modifications, this initial sync can be megabytes of data. TCP's congestion control sends this slowly, and during the sync, the game thread is partially occupied with serialization and sending.

None of this is a problem for a 4-player LAN session. All of it becomes a problem for a public server with 12+ players on varying internet connections.

Single-Threaded Game Loop: The Bottleneck

Terraria's dedicated server (TerrariaServer.exe or its Linux equivalent) runs all game logic on a single thread. This includes:

NPC AI and spawning decisions
Projectile physics and collision detection
Tile updates (liquid flow, wiring, block interactions)
Player input processing
World save operations
Network packet serialization and dispatch
Plugin/mod tick handlers (TShock, tModLoader)

The game targets 60 ticks per second. Each tick has a 16.67ms budget. Everything listed above must complete within that budget. When it does not, the tick rate drops, players experience lag, and the server falls behind on processing.

Unlike Minecraft (which runs at 20 TPS with a 50ms budget), Terraria's tighter tick budget means it is more sensitive to individual expensive operations. A single laggy plugin that takes 10ms per tick consumes 60% of the budget.

Critical single-thread bottlenecks:

Boss fights with many NPCs and projectiles. The Moon Lord fight can spawn hundreds of projectiles per second. Each projectile needs physics calculation and collision checking on the single game thread. On a server with multiple simultaneous boss fights, the tick budget is impossible to meet.
Liquid simulation. Breaking a large body of water or lava triggers cascading liquid physics calculations. The server processes every liquid tile update sequentially. A flooded cave can freeze the server for seconds.
Wiring and logic gates. Terraria's wiring system triggers tile activations synchronously. A large wired contraption (like a pixel art display or a complex trap system) that fires hundreds of wire signals in a single tick can stall the game loop.
World save operations. Terraria periodically saves the world to disk. The save operation serializes the entire world state and writes it to file. On a large world (8400x2400 tiles), this can take hundreds of milliseconds. During the save, no game ticks are processed. Players see a brief freeze every save cycle.
Plugin overhead. TShock and tModLoader plugins run within the game loop. A poorly written plugin that does database queries or HTTP requests synchronously in the tick handler blocks the entire server.

World File Corruption: The Real Danger

Terraria's world file format stores the complete state of every tile, chest, NPC home, and player-placed object in a single binary file. A Large world (8400x2400) can produce a save file of 20-40MB depending on how much has been built and explored.

The save process works like this:

The server serializes the world state to memory.
It writes the serialized data to a temporary file.
It renames the temporary file to the world file (overwriting the previous save).
It deletes the backup of the previous save.

If the server crashes during step 2 (writing to disk), the temporary file is incomplete. If it crashes during step 3 (rename), both the temporary and original files may be in an inconsistent state. If it crashes during step 1 (serialization), the in-memory state may have been partially serialized, and any earlier temporary file is stale.

Corruption scenarios:

Crash during save. The most dangerous scenario. If the server process is killed (OOM, power loss, hosting provider issue) during the save operation, the world file can be truncated, partially written, or entirely missing. The temporary file, if it exists, is incomplete.
Mod-induced serialization errors. tModLoader mods add custom data to the world save. If a mod's serialization code has a bug, it can write invalid data that corrupts the save file. The corruption may not be detected until the next load attempt.
Disk full during save. If the disk runs out of space during the write operation, the file is truncated. Terraria does not always detect this gracefully.
Filesystem-level corruption. Power loss on a hosting provider's storage system can cause filesystem-level corruption that damages the world file even if Terraria's save logic was correct.
Concurrent access. Backup scripts that copy the world file while the server is writing to it can produce a corrupt backup. The backup looks fine until you try to restore it.

A corrupted world file typically means one of two outcomes: the server refuses to start (and tells you the world is corrupt), or the server starts but the world has missing sections, reset areas, or misplaced tiles. In both cases, the only fix is restoring from a backup. If the most recent backup is also corrupt (because it was taken during a crash), you lose everything since the last good backup.

This is where monitoring matters most. The faster you detect a crash, the less data is at risk. If your server crashes and sits offline for 6 hours before you notice, those 6 hours of potential backup time are wasted. With monitoring alerting you within minutes, you can investigate the crash, verify backup integrity, and restore service before the next scheduled backup cycle would have overwritten a good backup with a potentially corrupt one.

Port 7777: What Monitoring Actually Tests

Terraria's default server port is TCP 7777 (configurable via serverconfig.txt or command-line arguments). When UptyBots performs a TCP port check on 7777, here is exactly what happens at the protocol level:

The monitoring system initiates a TCP three-way handshake (SYN, SYN-ACK, ACK) with the target IP on port 7777.
If the handshake completes, the port is "open" and the server is confirmed to be running and accepting connections.
The monitoring system records the time taken to complete the handshake (connection latency) and closes the connection.

What a successful check confirms:

The server process is running (not crashed, not terminated by OOM Killer).
The server is accepting TCP connections (not frozen in a save operation that blocks the accept loop, though brief freezes between check intervals would be missed).
The network path from the monitoring location to the server is functional (no routing issues, firewall blocks, or DNS problems).
The hosting provider's network infrastructure is working.

What a failed check means:

Connection refused. The port is closed. The server process is not running. It has either crashed, been stopped manually, or failed to start after a restart attempt.
Connection timed out. No response at all. Possible causes: firewall blocking the port, hosting provider network outage, server machine is down, or the server is so frozen that it cannot process the TCP handshake.
Increasing latency trend. The server is responding but taking longer each time. This pattern precedes many crash types: the server is under increasing load, running out of memory, or spending more time in GC/save operations.

For TShock servers, there is an additional monitoring target: TShock's REST API. If enabled, it listens on a separate port (default 7878) and responds to HTTP requests. You can monitor this HTTP endpoint with UptyBots's HTTP monitoring to verify not just that the server process is running but that TShock's plugin layer is healthy and responsive.

Monitoring Configuration for Terraria

Primary monitor: TCP port 7777. Check interval: 1-3 minutes. This is your crash detection. Alert via Discord webhook for fastest community notification.
Secondary monitor: TShock REST API (if applicable). HTTP check on port 7878 (or your configured REST port). This catches scenarios where the game server is running but TShock has crashed or become unresponsive.
Alert channels. Set up at least two: Discord webhook for your admin/community channel, plus Telegram or email as a backup. Discord webhooks occasionally fail during Discord outages; a backup channel ensures you are always notified.
Response time tracking. Enable response time logging to spot degradation trends. A baseline of 10-20ms TCP connection time that starts showing 100ms+ readings indicates the server is struggling.
Multi-region checks if your players are geographically spread. A European player reporting "server is down" while US players are fine usually means a routing issue. Multi-region monitoring catches this.

Backup Strategy Aligned with Monitoring

Monitoring and backups work together. Monitoring tells you when something went wrong; backups let you recover from it. The two should be aligned:

Backup frequency: every 30 minutes. Terraria's world save is relatively small (20-40MB for a large world), so frequent backups are cheap. The goal: when a crash corrupts the world, the most progress you lose is 30 minutes.
Backup retention: at least 48 hours. Keep enough history to recover from a corruption that persists through multiple save cycles. If the world was corrupted at 2 PM but you only notice at 6 PM, you need a backup from before 2 PM.
Do not back up during save. Schedule backups at a known offset from the server's autosave interval. Terraria's default autosave is every 10 minutes. Set your backup to run at the 5-minute mark between autosaves to avoid copying a mid-write file.
Verify backup integrity. Periodically restore a backup on a test server and confirm the world loads. A backup that has never been tested is a liability, not a safety net.
Store backups off the same disk. If the disk fails, it takes both the live world and the backups. Copy backups to a different machine or cloud storage.

TShock and tModLoader: Extra Failure Modes

Most community Terraria servers run TShock (server-side administration) or tModLoader (mod support), or both. These add capabilities and new points of failure.

TShock

SQLite database corruption. TShock stores player data, bans, and permissions in an SQLite database. If the server crashes during a database write, the SQLite file can become corrupted. Recovery requires either restoring the database from backup or rebuilding it from scratch (losing player data).
Plugin crashes. TShock plugins run in the game loop. A plugin that throws an unhandled exception can crash the server. Unlike Terraria's own code, third-party plugins often lack error handling for edge cases.
REST API memory leaks. TShock's REST API, if heavily used by external tools (Discord bots, web dashboards), can accumulate memory from request handling. This contributes to overall memory pressure on the single-process server.
Permission system issues. Misconfigured permissions can lock players out or give unintended access. While not a crash, it causes player frustration that leads to complaints that look like "the server is broken."

tModLoader

Mod version mismatches. tModLoader mods must match between client and server. A mod update on the server that players have not installed locally causes connection failures. The server appears "down" to those players even though it is running fine.
Custom world data. Mods add custom data to the world file. Removing a mod after it has saved data to the world can cause load failures or silent data loss.
Increased memory footprint. Each mod loads its own assemblies and data structures. A heavily modded tModLoader server can consume 4-8GB of RAM, compared to 500MB-1GB for vanilla.
Tick rate impact. Mods that add complex NPCs, projectiles, or tile interactions increase per-tick processing time. The 16.67ms tick budget shrinks quickly with several content mods active.

Diagnosing Common Terraria Crash Patterns

Server crashes during boss fights. Cause: too many entities and projectiles exceed the tick budget. The game loop falls behind, memory spikes from entity data, and the server either freezes or crashes. Monitoring shows a sudden timeout after a period of normal responses. Solution: limit simultaneous boss fights, reduce NPC spawn rates, or upgrade server hardware.
Server crashes every few days at the same time. Cause: scheduled tasks (backups, OS updates, hosting provider maintenance) interfere with the server. Monitoring shows the crash correlates with a specific time. Solution: reschedule the conflicting task or add a pre-task save command.
Server starts, accepts connections, then crashes when a player loads a specific area. Cause: a chunk of the world contains corrupt tile data (often from a mod that was removed or updated). Loading that area triggers a deserialization error. Monitoring shows the server starts successfully but crashes within minutes of a player joining. Solution: restore the world from a backup before the corruption occurred, or use a world editing tool to clear the affected area.
Gradual slowdown over hours, then crash. Cause: memory leak, either from the base server or a plugin/mod. Memory grows until the process is killed by the OS OOM Killer or crashes with an out-of-memory exception. Monitoring shows gradually increasing response latency before the timeout. Solution: schedule regular restarts (every 6-12 hours) and investigate which plugin is leaking.
Server is running but players cannot join. Cause: all player slots are occupied by ghost connections (disconnected players whose TCP sessions have not timed out). The server is "up" and monitoring confirms the port is open, but no new connections are accepted. Solution: configure TCP keepalive settings and TShock's timeout parameters to detect dead connections faster.

Optimizing the Server for Stability

Use a Medium world instead of Large. A Large world (8400x2400) has nearly twice the tile count of a Medium world (6400x1800). Every world save, every liquid simulation, and every NPC pathfinding calculation is proportionally more expensive. Unless your group specifically needs the extra space, a Medium world is significantly more stable.
Configure autosave carefully. The default 10-minute autosave interval is reasonable. Shortening it to 2 minutes means more frequent save freezes. Lengthening it to 30 minutes means more data at risk during a crash. Match your autosave to your backup schedule so that backups capture a recent autosave.
Set player limits conservatively. Terraria officially supports 16 players per server. In practice, 8-10 is the sweet spot for stability on most hardware. Each additional player adds network I/O, entity processing, and NPC spawn calculations to the single-threaded game loop.
Allocate enough RAM but not too much. Vanilla Terraria server: 1-2GB is plenty. TShock: 2-4GB. tModLoader with multiple mods: 4-8GB. Over-allocating RAM does not help and can hurt (larger working set means longer GC pauses on .NET runtime).
Run on an SSD. World saves write the entire file sequentially. On an HDD, the save operation is I/O-bound and takes longer, extending the freeze window. An SSD reduces save time from hundreds of milliseconds to tens of milliseconds.
Disable features you do not use. If no one uses wiring, disable complex wire evaluations. If you do not need the REST API, turn it off. Every active subsystem is a potential failure point.

Ghost Connections and TCP Keepalive

Ghost connections are a Terraria-specific problem amplified by the TCP protocol choice. When a player's internet drops suddenly (router reboot, ISP outage, laptop lid closed), the TCP connection stays "open" on the server side because no FIN or RST packet was sent. The server does not know the player is gone until a TCP keepalive probe fails or a send operation times out.

The default TCP keepalive on most operating systems is 2 hours. That means a player who disconnects at 8 PM might not free their slot until 10 PM. On a 16-slot server, 4-5 ghost connections mean a third of your capacity is wasted.

Solutions:

OS-level TCP keepalive tuning. On Linux, reduce keepalive time:
```
sysctl -w net.ipv4.tcp_keepalive_time=120
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=3
    
```
This sends a keepalive probe after 120 seconds of idle, retries every 30 seconds, and declares the connection dead after 3 failed probes. Total detection time: about 3 minutes instead of 2 hours.
TShock timeout settings. TShock has built-in timeout handling for unresponsive connections. Configure ServerSideCharacterConfig.json and the TShock config for appropriate timeout values.
Application-level ping. Terraria has its own keep-alive mechanism, but it depends on the server's game loop processing the timeout check. If the game loop is stalled (during a save or heavy processing), the timeout check is also delayed.

Frequently Asked Questions

What is the default Terraria server port?

TCP port 7777. Both vanilla and TShock default to this. You can change it in serverconfig.txt with the port= directive. TShock's REST API uses a separate port, typically 7878.

Why does Terraria use TCP instead of UDP like other games?

Terraria was originally designed as a small-scale co-op game where reliable delivery of every tile update mattered more than raw latency. TCP guarantees every packet arrives in order, which simplifies the game's networking code at the cost of the performance tradeoffs described above. For 4-8 players on a LAN, it works perfectly. The limitations show up at higher player counts and over the internet with variable connection quality.

How often should I back up the world file?

Every 30 minutes for an active server. Terraria's world files are small enough that frequent backups have negligible disk impact. Keep at least 48 hours of history so you can recover from a corruption that goes unnoticed for several hours.

Can UptyBots monitor a Terraria server behind a custom port?

Yes. UptyBots's port monitoring works with any TCP port. Set it to whatever port your server uses (check your serverconfig.txt). If you run TShock with the REST API enabled, you can also add an HTTP monitor for the REST endpoint.

How many players can a Terraria server realistically handle?

The game allows up to 16 (255 with mods). For stable gameplay, 8-10 is the practical limit on typical hardware. Each player adds network I/O and entity processing load to the single-threaded game loop. Boss fights with 12+ players frequently cause lag or crashes.

What is TShock and should I use it?

TShock is a server-side modification that adds admin tools (ban/kick, permissions, regions, anti-cheat, REST API, plugin support). Most public community servers run TShock because vanilla Terraria's admin tools are minimal. The tradeoff is additional complexity, additional failure modes (plugin crashes, SQLite corruption), and a dependency on TShock updates when Terraria updates.

Conclusion

Terraria's network architecture (TCP-based, single-threaded, with the world save and game logic sharing one thread) creates failure patterns distinct from other game servers. World file corruption during crashes is not a theoretical risk; it is the most common way Terraria communities permanently lose progress. Port 7777 monitoring with UptyBots catches server crashes in minutes, giving you time to investigate, restore from backup if needed, and get players back online before frustration sets in.

Pair monitoring with frequent world backups, sensible player limits, TCP keepalive tuning, and scheduled restarts. These are not optional optimizations; they are the minimum infrastructure for running a server that people invest hundreds of hours into.

Start protecting your Terraria world today: See our tutorials.