Terraria and Satisfactory: When a Game Server Answers Over TCP

There is a comfortable assumption in game server monitoring: point a UDP check at the port, wait for the Steam-style reply, read off the player count. It holds for Rust, for Counter-Strike, for DayZ, for Project Zomboid, for most of the survival genre.

It does not hold for Terraria or Satisfactory. Both use TCP 7777, and both are silent on UDP. Monitor them the usual way and you get a server that is permanently, confidently, wrongly down.

Two ways a game exposes itself

Games built on Valve's ecosystem inherit a public status query. Send a small UDP packet, get back a structured description: name, map, players, version. It is designed for server browsers, which is why anyone can ask.

Games outside that ecosystem owe you nothing of the sort. They accept connections from clients and that is all. There is no public interface for asking "how are you", because nothing in the game's design needed one.

Terraria is in the second group. It speaks its own protocol over TCP, and there is no side channel that reports status to strangers. Satisfactory is a slightly different case: since version 1.0 the dedicated server exposes an HTTPS API on the same TCP 7777, but reading anything meaningful from it requires an administrator token. A public checker has no business holding your admin credentials, and you should be wary of any that asks.

What a TCP check actually proves

When the payload is off limits, the honest check is the connection itself. Open a TCP connection to the port. If it completes, something is listening and accepting connections. If it is refused or times out, nothing usable is there.

This is genuinely weaker than an A2S reply, and it is worth being precise about the difference:

• It proves the process is alive, bound to the port, reachable through the firewall and the route from the checking location works.
• It does not prove the world loaded correctly, that players can actually join, or that the server is not stuck in a state where it accepts sockets and does nothing useful with them.

In practice that covers the overwhelming majority of real outages. Servers rarely fail by politely accepting connections while being broken inside; they fail by dying, by not restarting after a host reboot, or by losing their port forward.

Our Terraria checker and Satisfactory checker do exactly this and report exactly this. No invented player counts, no fabricated server names. If a tool shows you a player count for a Terraria server, be suspicious of where it came from.

The UDP trap in old guides

Satisfactory deserves a specific warning. During early access the server used UDP query ports, and plenty of guides still describe that setup. Those guides are out of date. We tested five live Satisfactory servers while adding support for the game: not one answered a UDP probe, and every one accepted a TCP connection on 7777.

If you configured a Satisfactory monitor from an older tutorial and it has been red ever since, the server is probably fine and the protocol is wrong.

Where these servers actually break

Both games attract a particular kind of hosting: a spare machine at home, or a small VPS, running for a group of friends rather than a public community. That shapes the failure modes.

• The host machine slept, rebooted or updated. The server process is simply not running any more, and nobody notices until someone tries to play.
• Port forwarding evaporated. A router reboot or a changed local IP breaks the forward. The server looks perfect locally and is invisible from outside - which is exactly the gap an external check exists to catch.
• Version mismatch after an update. Clients update automatically, the server does not, and joins fail while the port keeps answering.
• Memory, in Satisfactory's case. A large factory is expensive to simulate, and a sprawling save on an undersized box gets killed by the operating system.

Three of those four are caught by a plain TCP check. The fourth - version mismatch - is the honest limitation, and no external check will spot it.

How to set it up

• Protocol TCP. Not UDP, for either game.
• Port 7777 by default, or whatever your host assigned.
• Check from outside your network. The whole point is to test the path a real player takes, including the port forward.
• Several locations. A dedicated server running unattended for weeks can lose a route without losing the process.
• Alert to a real channel. These servers run for small groups; without an alert, the discovery method is someone trying to play on Friday evening.

The short version

• Terraria and Satisfactory answer on TCP 7777 and ignore UDP entirely.
• A UDP monitor on either game reports a healthy server as down, permanently.
• Neither exposes a public status query, so a connection test is the honest check - and it catches nearly every real outage.
• Satisfactory guides describing UDP query ports date from early access and no longer apply.