Sons of the Forest server not showing or can't join

When a Sons of the Forest dedicated server will not show up or will not let people in, the cause is nearly always one of five things, and the symptom tells you which. Missing from the list but joinable by address: the query port 27016 or LanOnly. Listed but every join times out: the game port 8766, or IpAddress bound to the wrong interface. Joins, then hangs forever on the loading screen: the BlobSync port 9700. Worked yesterday, rejects everyone today: a game patch and a server that was not updated. Rejects one person only: their password, their client version or their network. All three ports are UDP, and a rule that opens TCP instead is the most common way to do everything right and still fail.

This guide works through each of those in order, with the checks that separate them. The install, every key in dedicatedserver.cfg and the owner list are covered in the Sons of the Forest dedicated server guide; save slots and moving worlds are in Sons of the Forest settings and saves. Here the only subject is getting players from the menu into the world.

Match the symptom to the cause#

Start by being precise about what players see. "It doesn't work" covers half a dozen unrelated faults, and the fix for one of them does nothing for the others.

Two quick tests narrow it down faster than anything else. First, can anyone outside your network join by address? If yes, the server works and the problem is listing, a single client or your own LAN. Second, does the server log show the start-up network test passing? If it reports a closed port, believe it before you believe the router's web page.

The three ports, and what each one breaks#

Sons of the Forest uses three UDP ports, all set in dedicatedserver.cfg:

{  "IpAddress": "0.0.0.0",  "GamePort": 8766,  "QueryPort": 27016,  "BlobSyncPort": 9700}

Each one fails in its own recognisable way, which is useful, because it means you can usually name the closed port from the symptom alone.

• `QueryPort` (`27016`) is what Steam's master server and the in-game browser use to see the server, read its name and player count, and measure ping. Block it and the server still runs and still accepts direct joins, but it never appears in the list. If the list shows the server with no ping or a stale player count, the query traffic is getting through intermittently or not at all.
• `GamePort` (`8766`) carries the actual game session. Block it and the server can appear in the list - the query port still answers - but clicking join ends in a timeout.
• `BlobSyncPort` (`9700`) transfers world state to a joining player. Block it and the connection succeeds, the loading screen appears, and it never finishes. This is the one people miss, because most Steam games have only the first two and a checklist copied from another game will not include it.

All three must be UDP. Port forwarding pages on home routers often default to TCP or to "TCP/UDP"; check which one you picked. A forward of 8766 TCP does exactly nothing for this game. If the difference is new to you, TCP vs UDP for game servers explains why games use UDP and why that makes testing harder.

You can change any of the three numbers. The usual reason is a second server on the same machine, and then all three must differ between the two servers - two servers sharing a BlobSync port produces exactly the stuck-on-loading symptom for whichever started second. When you change a port in the config, change the forward, the firewall rule and anything you have told players to type, all at once. A port changed in one place and not the others is a large share of "it broke after I tidied up" reports. The general picture of game, query and transfer ports is in game server ports explained, and query ports and A2S covers what the query port is actually answering.

On start the server runs its own accessibility test against the three ports and writes the result to the console. A failed test tells you which port it thinks is closed, or that a port is already in use. "Already in use" usually means a previous copy of the server never exited - a crashed process still holding the port - or another program on the machine is on that number. Find and stop the old process before changing anything else.

IpAddress: what the bind setting really does#

IpAddress is the local address the server listens on. It is not the address players type, and it is not your public IP.

0.0.0.0 means every interface on the machine, and on a home PC, a VPS or inside a container it is what you want. The mistake that comes up again and again is putting the public address here because it seems like the server ought to know its own address. On a machine behind a router, the public address does not belong to any interface on that machine - it belongs to the router - so the server tries to listen on an address it does not have. Depending on the build, that either fails at start or produces a server that runs and that nobody can reach.

There are two legitimate reasons to set something other than 0.0.0.0:

• A machine with several network interfaces, such as a server with a public and a private network, where you want the game on one and not the other. Use the address of that interface exactly as the operating system shows it.
• A machine with several public addresses, where each game server should own one. Again, the address must be one the machine actually holds.

On Windows, ipconfig lists the addresses the machine has; on Linux, ip -4 addr. If the value in IpAddress is not in that output, it is wrong. A related trap is a home PC whose LAN address changes after a reboot because the router hands it out by DHCP. If you bound to 192.168.1.40 and the machine is now 192.168.1.52, the server listens on nothing useful and the router forwards to an empty address. Use 0.0.0.0 in the config and give the PC a DHCP reservation in the router, so the forward always lands on the same machine.

The server also needs a public IPv4 address to register with Steam. A connection that has only IPv6, or whose IPv4 is shared behind carrier-grade NAT, can start the server without being able to list it or receive joins. The log will say it could not get a public address from Steam, or the network test will fail on every port at once. IPv6 and game servers covers why Steam games still assume IPv4.

LanOnly, hairpin NAT and testing from the right place#

LanOnly set to true keeps the server off the public internet entirely. It does not register with Steam's public list, and players outside your network cannot join. It is the right setting for a LAN party and the wrong one for everything else, and because the server starts cleanly either way, it is worth checking before you go hunting through router menus.

The second trap at home is testing from inside your own network. Most consumer routers do not support hairpin NAT (also called NAT loopback): a PC on your LAN that connects to your own public address is not routed back inside. The result is a server that friends across town join without trouble and that the person hosting it cannot reach by the public IP. That is not a server fault. The host should join by the LAN address of the server PC, and everyone else by the public one.

The same effect breaks the server's own self-test. It probes its public address from inside the network, and without hairpin support that probe fails on a server that is perfectly reachable from outside. This is the only good reason to set SkipNetworkAccessibilityTest to true: you have confirmed with a player outside your network that joining works, and the test still says otherwise. Setting it to silence a test you have not understood just hides the error message while players keep failing.

So test from outside. A friend's PC, a phone tethered on mobile data with the game installed on a laptop, or a server elsewhere that can query Steam - any of those tells you the truth. The server's own machine and anything on its LAN cannot.

Hosting at home: forwards, firewalls and CGNAT#

If the server runs on a PC at home, three layers stand between players and the game, and all three need the same three UDP ports.

1. The router. Forward UDP 8766, 27016 and 9700 to the LAN address of the server PC. Some routers want a range per rule; three single-port rules is fine.
2. The operating system firewall. On Windows, the first time SonsOfTheForestDS.exe listens, Windows Defender Firewall asks whether to allow it. Dismiss that dialog, or tick only "private networks" while your network is marked public, and the inbound traffic is dropped without another word.
3. The connection itself. If your provider uses carrier-grade NAT, no forward you set will ever work, because your router does not hold the public address.

On Windows, an explicit inbound rule is more dependable than trusting the dialog. From an administrator prompt:

$ netsh advfirewall firewall add rule name="Sons of the Forest server" dir=in action=allow protocol=UDP localport=8766,27016,9700

On a Linux host running the server under Wine or Proton, with ufw as the firewall:

$ sudo ufw allow 8766/udp$ sudo ufw allow 27016/udp$ sudo ufw allow 9700/udp

If the server runs in Docker, each port also has to be published with its protocol, such as -p 9700:9700/udp. Docker publishes TCP by default, and a container started with -p 9700:9700 has the same missing-UDP problem as a router forward set to TCP. Firewall rules that matter and the ufw guide cover the wider picture.

To spot CGNAT, compare the WAN address shown on the router's status page with the address a site such as a "what is my IP" page reports. If they differ, or the router's WAN address sits in 100.64.0.0/10, your connection is shared and inbound forwarding cannot work. The fixes are to ask the provider for a public IPv4 address, which some give on request and some charge for, or to run the server somewhere that has one. NAT and CGNAT for game hosts goes through the options, and port forwarding vs hosted servers is the honest comparison of fighting this at home against renting.

On a hosted server most of this disappears. On RE:NODE, Sons of the Forest plans come with three port allocations, and they are already open to the internet; there is no router or Windows firewall in front of them. What you do need to check is that the three numbers in dedicatedserver.cfg match the allocations shown on the Network tab, because a config copied from a home server will carry the home port numbers with it.

Checking from outside: is Steam listing it at all?#

The in-game browser is slow to refresh and filters aggressively, so "not in the list" in game does not always mean "not registered". Steam's public Web API answers the question directly. Put the server's public IPv4 address into this URL in any browser:

https://api.steampowered.com/ISteamApps/GetServersAtAddress/v1/?addr=203.0.113.25

It returns every Steam game server registered from that address, with the ports Steam knows about. An empty list means the server has not registered with Steam: look at LanOnly, the public IPv4 problem and the server log. A result with your server in it means Steam has it, and a player who still cannot see it in game has a browser filter set, or a cached list, or the query port is blocked between Steam and the server so the browser cannot ping it.

The Steam client's own server browser is a second opinion. In Steam, open View, then Game Servers, go to Favourites and add the server by address and query port. If it answers there with a name and ping, query traffic reaches it. That is useful for isolating the game's browser from the network: if Steam's browser sees the server and the game does not, the problem is on the game side, usually a filter or a version difference.

Version mismatch after a patch#

Client and server must run the same build. Steam updates players' copies of the game automatically, usually the day a patch ships. The dedicated server is a separate app (2465200) that updates only when someone runs SteamCMD against it. So the day after a patch, the server is on yesterday's build and everyone who has updated is turned away - often with a message that does not mention versions, or with a connection that simply ends.

The fix is to update the server, then restart it:

$ steamcmd +force_install_dir C:\sotf-server +login anonymous \    +app_update 2465200 validate +quit

Do it before anyone tries to join, and take a copy of the save first, since patch day is also the most likely day for a save format change. SteamCMD explained covers validate and installs, and SteamCMD errors and fixes covers what to do when the update itself fails.

The opposite mismatch happens too. A player who has opted into a beta branch of the game in Steam's properties is on a different build from a server running the public branch. If exactly one person cannot join after everyone else can, ask them to check the game's Betas tab in Steam and to verify their files. The reverse - a server pinned to an old build while players move on - is how a server running a script with an old -beta argument quietly stops accepting anyone. SteamCMD app ids and beta branches explains how that happens.

A habit worth building: when a patch is announced, update and restart the server on the same day, and tell the group. Game server update day checklist has the steps in order, and automating game server updates covers making it someone else's job - namely, a scheduled task.

Passwords that do not work#

Password is a plain string in the JSON, up to 40 characters. Empty means no password. Three things go wrong with it:

• Case and spacing. The match is exact. A trailing space pasted from a chat message is part of the password.
• JSON escaping. A password containing a double quote or a backslash must be escaped as \" or \\, or the file stops parsing. Easier to pick a password without either.
• A command-line override. Every config key can be set on the command line with a -dedicatedserver. prefix, and the command line wins. If a panel or a start script passes -dedicatedserver.Password, changing the file does nothing. Check the start command before deciding the server is ignoring you.

The password applies at every restart, so a change is a stop and start away, and it does not touch the world. If one player cannot get in with a password that works for everyone else, have them type it rather than paste it. If nobody can, read the start-up log for the configuration line before suspecting the network.

Reading the server log#

The console output is where every one of these problems announces itself, and it is worth reading top to bottom once on a server that works, so you know what normal looks like. Start the server with -verboseLogging while you are diagnosing; the extra detail is the difference between knowing and guessing. Set LogFilesEnabled to true if you also want the output written to files under the user data folder, with TimestampLogFilenames keeping each start in its own file.

What to look for, in order:

1. The configuration being read. A parse failure means malformed JSON - a trailing comma, a smart quote, an unescaped character in the password - and the server stops there. Fix the file and start again.
2. The ports being opened. An "in use" message means another process holds the number. Stop it, or move this server to free ports.
3. The public address from Steam. A failure here means no public IPv4 is available: IPv6-only connections, CGNAT, or Steam having a bad moment, in which case a restart a few minutes later is worth one try.
4. The network accessibility test. Each port is reported as reachable or not. A single closed port names your problem. All three closed usually means the forward points at the wrong machine, the firewall is dropping everything, or hairpin NAT is breaking the test itself.
5. Players connecting. With a join in progress, the log shows the connection arrive. If the game port connection appears and nothing follows, the BlobSync transfer is not getting through.

On RE:NODE the console shows the server's live output unfiltered, so the network test and every join appear as they happen, and the Startup tab is where any command-line overrides live. That is the first place to look when a value in the file seems to be ignored.

One more thing the log reveals: repeated restarts. A server that crashes on load, perhaps because of a damaged save, restarts and looks briefly "online" before vanishing again. To players that is indistinguishable from a network problem. If uptime in the console keeps resetting, the problem is the server, not the ports - why your game server keeps restarting is the place to start.

FAQ#

Why does my server show up for friends but not for me?

You are on the same network as the server, and your router does not loop traffic to its own public address back inside. Join using the server PC's LAN address instead. Everyone outside your network uses the public address as normal.

Which ports do I need to forward for Sons of the Forest?

UDP 8766 for the game, UDP 27016 for the Steam query, and UDP 9700 for BlobSync, unless you changed them in dedicatedserver.cfg. All three must be UDP. Missing the third one causes the endless loading screen.

Should I put my public IP in IpAddress?

No. IpAddress is the local interface to listen on, and 0.0.0.0 means all of them. Only set a specific address when the machine has several and you want the server on one, and then use an address the machine itself holds.

Players got kicked back to the menu right after a game update. What happened?

Their game updated and the server did not. Stop the server, run app_update 2465200 through SteamCMD, and start it again. Back up the save first, since patch days are when formats change.

Is it safe to turn on SkipNetworkAccessibilityTest?

Only after someone outside your network has joined successfully. The test fails falsely behind NAT without loopback support, and in that case skipping it is fine. If nobody can join, skipping it changes nothing except the message.

Can I run two servers on one machine?

Yes, if each has its own three ports and its own user data folder via -userdatapath. Two servers sharing any one port - BlobSync is the easy one to forget - will break joins on whichever started second.