Fix for Failed to connect to Server API while connection to Dedicated Server?

[Phinnnna]

Check your port forwarding has the following configured for it.

5222 TCP & UDP
6666 TCP & UDP
7777-7827 UDP

i had to recreate my rules for it to work. Worth noting my internal IP worked fine which is what showed me it was the external connection that was the issue.

[Tass]

remove -multihome= from cli

[Grignard]

Originally posted by Tass:

remove -multihome= from cli

Can you explain your comment?

[AxLp]

same issue, 7777 udp, failed to connect to Server API.
Until yesterday the dedicated server worked

[Phinnnna]

Originally posted by AxLp:

same issue, 7777 udp, failed to connect to Server API.
Until yesterday the dedicated server worked

i removed all my rules and recreated with the above ports seems to have resolved it for me

[Phinnnna]

Originally posted by Grignard:

Originally posted by Tass:

remove -multihome= from cli

Can you explain your comment?

yeah i second this, i wasnt after a specific fix i was offering up the issue i had and what i did to fix it

[Dr. Simon Glass]

I thought I was going crazy with this too, glad to see it wasn't just me having this issue

[dankomancer 𝝙]

how do you bind to a specific IP or adapter, then

[xlbeastz]

Open TCP 7777. They changed from UDP to TCP 7777

[Nines]

Alright, none of this worked for me. According to patch notes the only thing necessary is 7777 TCP & UDP. But I don't even have it blocked (firewall is off on my ubuntu server) and i still can't connect, even from my local IP. "Failed to Connect to the Server API"

I even uninstalled it and reinstalled it to try to get it functioning. It worked enough that I could login but then as soon as I went to make a new game on the server, it disconnected and i'm back to square one. This is really scrambling my brains :(.

[Nines]

Here's my systemd setup in linux. And i have UFW disabled,

[Unit]
Description=Satisfactory Dedicated Server
Wants=network-online.target
After=syslog.target network.target nss-lookup.target network-online.target

[Service]
Environment="LD_LIBRARY_PATH=./linux64"
ExecStartPre=/usr/games/steamcmd +force_install_dir /home/steam/SatisfactoryDedicatedServer +login anonymous +app_update >
ExecStart=/home/steam/SatisfactoryDedicatedServer/FactoryServer.sh -Port=7777 -log -unattended
User=steam
Group=steam
StandardOutput=journal
Restart=on-failure
WorkingDirectory=/home/steam
StandardOutput=append:/var/log/satisfactory.log
StandardError=append:/var/log/satisfactory.err
Timeout=120

[Install]
WantedBy=multi-user.target

[Dr. Simon Glass]

According to another thread, if you're using ich777's docker container he knows it's broken and will fix it when he gets home

[Zak]

This is from the Satisfactory DS Discord channel, both posts by CSS programmer:


Today at 6:38 PM
Overall, for new dedicated servers. You should NOT have anything other than -Port=<PortYouWantToListenOn> on your command line. If you do not specify -Port=, the default port is 7777.



Today at 7:26 PM
Okay, it seems like the issue has been identified. Note that the issues described below only affect Linux users

If you are running with -multihome= on the command line, OR inside of the docker container, you will be unable to connect to the Server API.

There is no workaround currently known other than removing -multihome= and running docker containers using the host network mode.

Additionally, a dedicated server will bind to 7778 on UDP on IPv6 and a random port on TCP on IPv6. These are NOT critical and you can safely ignore them, but we will address that in the future.

We will release a patch addressing connectivity in docker containers and with -multihome= this week, so stay tuned.

[Chaos "Fox" Overlord]

Environment:

Satisfactory 1.0 Dedicated Server via Steam on Ubuntu 24.04 (vRoot)


Problem:

UDP Listner 0.0.0.0:7777, but TCP (API) Listner only on 127.0.0.1:7777, thus not reachable, thus leading to "Failed to connect to API"-Error in Client


Solution:

Setting up a DNAT, Code:

sudo iptables -t nat -A PREROUTING -i <your_external_interface> -p tcp --dport 7777 -j DNAT --to 127.0.0.1:7777
sudo sysctl -w net.ipv4.conf.<your_external_interface>.route_localnet=1

First line sets up the routing from your external interface to 127.0.0.1. The route back is automaticly managed by conntrack.
Second line allows localnet Adresses (e.g. 127.0.0.1) on your external interface after rewrting its destination (see first line) to prevent discarding.
Replace <your_external_interface> with the name of your external interface, e.g. eth0, ens6, etc..


Disclaimer:

Parameter -multihome=0.0.0.0 is (still) used, removing the parameter not tested.
Similar solution for other OS (e.g. Windows) may or may not work.

[KovácsKolléga]

Hi all. I had the same problem with a windows PC. For me it turned out, after the correct router settings, i had to aprove the data trafic for the client PC in the ESET Security on the server. That eliminated the connectoin fail for me.