Why players cannot connect to your game server: step by step

When players cannot connect, the cause is almost always one of six things, and they can be checked in order: the server has not finished starting; it is listening on a different port or address from the one you think; the player is using the wrong address or port; the network between them drops the traffic; the game itself refuses the player (version, password, whitelist, mods, bans, slots); or the problem is entirely on the player's side. Each step takes a minute and rules out a whole layer. Skipping ahead - rewriting firewall rules before checking the console - is how a five-minute fix becomes an evening.

This post is the order and the evidence for each step. For the port numbers themselves, game server ports explained has the table; for servers that people can join but cannot find in the list, why a server does not show in the server list is the right page.

First: one player, or everyone?#

The single most useful question, because it splits the problem in half before you touch anything.

If one person in a group of ten cannot join, do not change the server. Nine successful joins prove the server and the network are fine.

Step 1: is the server actually up?#

"Running" in a panel or in Task Manager means the process exists. It does not mean the game has finished loading. Large worlds, modded servers and first boots after an update can take minutes, and the port often is not open until the end.

Read the console and look for the line the game prints when it is ready. A few examples:

[Server thread/INFO]: Done (14.208s)! For help, type "help"      <- MinecraftConnection to Steam servers successful.                           <- Source gamesSession "Longship Crew" with join code 483920 ... is active        <- Valheim

If the last lines are an error, a stack trace or a server that stopped and started again, you do not have a connection problem, you have a server problem. Reading the console explains what to look for, and why your game server keeps restarting covers crash loops. On RE:NODE the console shows live, unfiltered output with memory, CPU and disk graphs beside it, so a server that hit its memory limit and restarted is visible at a glance.

Step 2: is it listening where you think?#

The game binds to an address and a port. Both can differ from what you expect: a config file that was not saved, a game that rewrote its config on shutdown, a port variable set in two places that disagree. The server tells you what it actually bound to in its first lines of output. On a machine you control, you can ask the operating system directly:

# Linux: every listening TCP and UDP socket, with the process$ ss -lntup | grep -E '25565|2456|27015'udp   UNCONN 0  0   0.0.0.0:2456   0.0.0.0:*   users:(("valheim_server",pid=812))udp   UNCONN 0  0   0.0.0.0:2457   0.0.0.0:*   users:(("valheim_server",pid=812))

On Windows, Get-NetUDPEndpoint -LocalPort 2456 or netstat -ano | findstr 2456 does the same. Read the address column carefully:

• 0.0.0.0 or * - listening on every interface. Good.
• 127.0.0.1 - listening on loopback only. Nobody outside can reach it, ever. Fix the bind address in the game's config; for Minecraft that is server-ip= in server.properties, which should almost always be left empty.
• A private LAN address on a machine with several - fine at home, wrong if the machine moved networks.

If nothing is listening on the port at all, the problem is the game's configuration, not the network.

Step 3: right address, right port#

The next most common cause is the player typing the wrong thing. Check what they actually entered, not what they think they entered.

• Game port, not query port. For games with two ports, players join on the game port. Valheim joins on 2456, not 2457. A player who copied the second number from a list gets a timeout.
• The port at all. If the server is not on the game's default port, the player has to type it: 203.0.113.10:25570. Without it, the client tries the default and reaches nothing - or someone else's server.
• The domain points somewhere else. If players use a name, check where it resolves today: nslookup play.example.com. A recent change can still be cached for the length of the record's TTL. On Windows, ipconfig /flushdns clears the player's own cache; resolvers upstream will catch up on their own. Connecting a domain to a game server covers the records, and for Minecraft SRV records explain how a name can carry the port.
• The address changed. A home server's public address can change on any reconnect. A hosted server's address does not change, but a server moved to another host does.

Step 4: does the network let it through?#

Only now is it worth looking at ports and firewalls. Test from outside - a phone on mobile data with wifi off, or a friend - because a test from the server itself or from the same network proves nothing.

For a TCP game (Minecraft Java, Terraria):

$ nc -vz 203.0.113.10 25565Connection to 203.0.113.10 25565 port [tcp/*] succeeded!

"Succeeded" means the path and the port are fine. "Connection refused" means the machine answered but nothing is listening - go back to step 2. A long wait then a timeout means something dropped the packet: a firewall, a missing forward, or the wrong protocol. In the Minecraft client these show up as Connection refused: no further information and Connection timed out: no further information respectively, and the difference between them is the most useful clue the game gives you.

For a UDP game, nc cannot tell an open port from a filtered one, because UDP sends nothing back unless the application answers. Use the game's own query instead - query ports and A2S has a one-line check for Steam games - or simply try to join.

The usual network causes, in order of frequency:

1. Wrong protocol. A TCP rule for a UDP game matches nothing. Valheim, Source games, Palworld, Project Zomboid and most survival games are UDP; Minecraft Java and Terraria are TCP; some need both.
2. Port not allocated or not forwarded. On a hosted panel, the game's port setting must match a port that is actually allocated to the server. At home, the forward must point at the server's current LAN address.
3. Firewall on the machine. Windows Defender Firewall blocks inbound by default. If players on your LAN cannot join either, this is it.
4. CGNAT or double NAT at home. No forward on your router will ever work if your router does not hold a public address. NAT and CGNAT for game hosts explains how to tell.

On RE:NODE the allocated ports are listed on the server's Network tab, and the game's port settings are on the Startup tab. If the two disagree, the server listens on a port that nothing routes to. Fix it so the game uses an allocated port, restart, and read the first lines of the console to confirm.

Step 5: the game refuses the player#

If the connection reaches the game and the game says no, there is usually a message, and it is usually accurate. The trouble is that players paraphrase it as "it doesn't work". Ask for the exact text or a screenshot.

Two of those deserve a warning. Allow lists keyed on names break when a player changes their name; use IDs where the game supports them. And IP bans hit everyone behind the same carrier NAT or university network, so a ban meant for one person can lock out a stranger - handling cheaters and ban lists covers better ways.

Mod mismatches produce the most confusing errors, because the message comes from the mod loader rather than the game and often names a mod rather than the problem. If only modded players fail, compare mod lists and versions before anything else. What to do when a mod update breaks has the routine.

Platform and crossplay failures

When everyone on one platform fails and everyone on another succeeds, the cause is almost never the network. It is the way that platform joins.

• Valheim players on Xbox or the Microsoft Store can only join a server started with -crossplay, and they join with the six-digit code printed in the log, not by IP. The code changes on every restart, so yesterday's code is a dead end. A server with client-side mods is effectively PC-only, because console players cannot install them. Valheim crossplay and Xbox players goes through it.
• Minecraft Bedrock players cannot join a Java server at all without a translation layer such as Geyser, and console editions of Bedrock cannot add an arbitrary server address without workarounds. Minecraft Geyser and Bedrock crossplay covers the setup and the ports it needs - Bedrock is UDP, unlike Java.
• Steam versus non-Steam copies of the same game sometimes use different networking and cannot see each other's servers. Check the game's own notes before assuming a fault.

The day after an update

A large share of "nobody can connect" tickets arrive within a day of a game patch. The client updated automatically; the server did not, or it did and the mods have not caught up. The symptom is a version error for everyone at once, often reported by players as "the server is down".

Check the version the server reports in its startup output against the version the players have. If they differ, update the server - on a panel, usually a restart with updates enabled - and, for a modded server, check that each mod has a release for the new version before you do. If a player is on a beta branch through Steam's properties, they will be on a different version from everyone else until they opt out. Automating game server updates covers keeping the server in step without breaking mods on patch day.

Step 6: it is the player's network#

When everyone else connects and one player cannot, the server is innocent. The player's side has its own list:

• A VPN they forgot was on, or one their anti-cheat dislikes.
• A restrictive network. Schools, workplaces, hotels and some public wifi block non-web UDP outright. Try mobile data.
• Security software that blocks the game's outbound connections, or a fresh install that never got permission.
• A stale DNS cache after you moved or renamed the server.
• Their ISP's routing. Rare, but real: one ISP with a broken path to your server's network. An mtr from the player to the server, read with reading traceroute and MTR, shows where it stops.

When it works sometimes#

Intermittent failures are a different shape of problem. Players get in, then cannot, then can again.

• The server is restarting. A crash loop or a memory limit looks like "the server keeps going offline". Check the console and the uptime.
• The server is full at peak hours. Obvious once you think of it; not obvious from "I can't connect at 9pm".
• Packet loss. Joins time out more often on a lossy path, because the handshake is several round trips. Latency, jitter and packet loss explains how to see it.
• An attack. A flood against the server or its query port makes joins fail while connected players carry on or rubber-band. What we do about attacks describes what that looks like from the inside.

FAQ#

Why can I join my own server but my friends cannot?

If you are on the same network as the server, you are using the LAN path, which skips the router, the forward and the internet entirely. Your friends use the public path. Test from outside your network, and check the forward, the protocol and whether your connection is behind CGNAT.

What is the difference between "connection refused" and "connection timed out"?

Refused means the packet reached the machine and nothing was listening on that port, so the machine answered with a rejection. Timed out means nothing answered at all, usually because a firewall, a missing forward or the wrong protocol dropped the packet on the way.

Players get "server is full" but nobody is online. Why?

Usually stale sessions: players who crashed or lost connection are still counted until the server notices they are gone. A restart clears them. If it keeps happening, check the max players setting and whether a plugin reserves slots.

Do players need to open ports to join my server?

No. Players connect outbound, which every home router allows. Only the server side needs open or allocated ports. If a player is told to open ports to join a dedicated server, the advice is wrong.

Can my host see why someone cannot connect?

A host can confirm the server is running, which ports are allocated and whether traffic is reaching the node. It cannot see the player's error message or their network. Give your host the exact error and the player's rough location along with the console output.