For a vanilla PC server reached through Join via IP, check the running game, its TCP listener and the external route separately. A server console saying it has loaded the world does not prove that another network can reach it. Conversely, an open TCP port does not prove that the client can enter the game.
The examples use Ubuntu 24.04, the terraria account, tmux and TCP 7777 from our setup guide. They cover direct PC connections. Steam invitations, mobile/console crossplay, tModLoader and TShock introduce different compatibility or transport questions; do not treat them as interchangeable tests.
Classify the failure before touching the firewall#
Record the exact message and the point at which it appears. Is the address unreachable, is there an immediate refusal, does a password prompt appear, or does the client explicitly report a different version? Compare the client's complete PC version with the live server banner first. Use the version mismatch guide when those differ.
An old official-forum connection thread contains repeated reinstalls and firewall changes around an unresolved Steam-join symptom. It illustrates why the message alone is not a diagnosis. This article instead isolates direct-IP connections and changes one boundary at a time.
Ask whether one client fails or everybody does. If another external PC enters the same address, port and world, preserve that working comparison. Do not disrupt it by recreating the server while investigating one player's route.
Confirm the intended process owns a listener#
On the server, run read-only checks from the administrative SSH account:
sudo ss -ltnp 'sport = :7777'
pgrep -a -u terraria -f 'TerrariaServer'
sudo -u terraria sed -n '/^world=/p; /^port=/p' \
/srv/terraria/serverconfig.txt
If your actual configured port differs, replace 7777 in every check. No listener means there is no incoming TCP endpoint at that port yet. Inspect the tmux console for world selection, a load error or a port-in-use message before changing a router rule.
For a listener restricted to 127.0.0.1, external clients cannot connect directly. Check the actual startup arguments, including any -ip binding. A listener on an appropriate local interface is required, but its presence still says nothing about the provider firewall.
Check that the process belongs to the expected account and release. An unrelated program or a forgotten second server can own the same expected port. Do not kill processes using a broad pattern just to clear the number.
Probe TCP from the player's side#
From a Windows player's PowerShell, replace this documentation-only address with the actual server address:
Test-NetConnection -ComputerName 203.0.113.10 -Port 7777
On a Linux workstation with netcat installed:
nc -vz -w 5 203.0.113.10 7777
A successful TCP handshake establishes transport to something listening there. It does not validate Terraria versions, passwords or world access. A timeout indicates that the TCP handshake did not finish; it does not identify which firewall or route caused that result. An immediate refusal commonly means an endpoint actively rejected the connection, so compare it with the listener state and address.
Use an external network for a public-route test. A successful connection from the same LAN can bypass the boundary that remote players need to cross. Ping is not a substitute: ICMP and the game TCP connection can be filtered differently.
Check host firewall, provider rules and NAT separately#
Read the local firewall before editing it:
sudo ufw status verbose
ip -brief address
ip route
For an already configured UFW installation, allow the actual game port if that rule is missing:
sudo ufw allow 7777/tcp
This is not a request to enable an unused firewall or disable an existing one. Preserve SSH access. The server reference identifies TCP 7777 as the default direct server endpoint; opening only UDP does not provide that TCP route.
Check the VPS provider's separate inbound rules. For a server behind a home router, forward the chosen external TCP port to the correct LAN address and internal TCP port. Recheck the destination after a DHCP change. A private LAN address is not an internet address to send to remote players.
If the router's WAN address is private or shared and differs from the public address, investigate upstream NAT or CGNAT with the ISP. Adding another local forwarding rule cannot control an upstream router. Request an appropriate public-address option or deliberately design a VPN route that every participant can use; verify its endpoint and port rather than assuming the old public address applies.
Finish with a game join and retain scoped evidence#
Enter the verified address and port through Multiplayer → Join via IP, supply the game password and confirm the correct world. If using a hostname, compare its resolved address with the working direct address before changing DNS. Test a compatible character as well as a compatible game build.
Keep a compact diagnostic record: timestamp, client/server versions, selected address and port, listener state, external TCP result and the exact game message. Redact secrets and private network details before sharing. If a player reaches the world but later disconnects, record whether the server process continues and whether other players drop simultaneously. That is a different investigation from an endpoint nobody can reach.
