1.0 API Connection Issue (FIX INSIDE)

[wolveix]

STATUS

IT WORKS 🎉

You shouldn't have any issues with the latest docker image. Available via the tags below:

• latest
• dev
• v1.8.0
• v1.8
• v1.7.3
• v1.7

You also need to ensure that BOTH ports 7777/udp AND 7777/tcp are port forwarded etc. You do not need ANY other ports.

If you see issues about the port binding in the log file, Coffee Stain confirmed to me that these messages are meaningless, please disregard them. The same goes for the certificate being self-signed. If you're getting a certificate key missing error when trying to join, make sure you've added the server through the in-game - server manager FIRST.

If you're unsure, please re-read the README before opening new issues. Every single person that has reported an issue since the fix went out either hadn't updated their Docker image, or were using the old Satisfactory ports.

Summary

I spoke with a Coffee Stain developer for a while and we troubleshooted together to figure out the issue. Essentially, there's an issue with how the TCP bind for the API disregards multihoming. You can reproduce the issue we see with the container by running it on baremetal with -multihome set to anything. No, we are not using -multihome within the container. Yes, this is an issue we need to wait for them to fix.

They've confirmed that the patch will be released in the next few days (week of September 9th)!

[chichi13]

Good Luck!

[wolveix]

Might have found the issue, hold tight!

[ikiris]

ok what did i miss? XD

[richardbenson]

Just in case you haven't seen it, I assume it's because of this:

LogHttpListener: Created new HttpListener on 127.0.0.1:7777

[wolveix]

No, it's not because of that.

The API binds to a random port right now, looking for a config flag for it

[wolveix]

You can get around the issue for now by running net=host for the container

https://docs.docker.com/engine/network/drivers/host/

[Fabricio20]

For those on docker-compose, that is network_mode: 'host', server works fine for me with this workaround.

[wolveix]

I'll continue searching for the flag, assuming CoffeeStain added one that is

[iceyy0044]

Can i somehow do that when iam using the docker image inside pterodactyl egg ? Or i need to wait for the author to fix it aswell ?

[Tctcl]

Can i somehow do that when iam using the docker image inside pterodactyl egg ? Or i need to wait for the author to fix it aswell ?

I'll fork the official egg and send a link in here for that

[iceyy0044]

Okay, thanks.

[ankemp]

You can get around the issue for now by running net=host for the container

https://docs.docker.com/engine/network/drivers/host/

Can't do this when you bind to a static IP on a different subnet, ideally we can configure the port manually.

[megamertag]

by any chance, i deployed it on a truenas scale instance custom app, how do i change the network mode, if somehow someone know that

[dbaje]

The network host workaround is not a one size fits all solution. If you are forwarding requests from one server to another, that's also an issue.

[dbaje]

by any chance, i deployed it on a truenas scale instance custom app, how do i change the network mode, if somehow someone know that

You can't. One way to do it in scale, is to bind your container to the network bridge so it can get an IP address and then you connect to that IP.

[DenuxPlays]

The image only downloaded 60MB is this right?
So the server from steam is 60MB?

[EuleMitKeule]

How can I fix it when using Docker Swarm? I don't think network_mode: host is an option there.

[stirkage]

The image only downloaded 60MB is this right? So the server from steam is 60MB?

It will download the game server files on first launch

[DenuxPlays]

The image only downloaded 60MB is this right? So the server from steam is 60MB?

It will download the game server files on first launch

The container is running
The container logs reported that he downloaded 60MB

[ankemp]

@wolveix

From the official docs (found in game install dir):

Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777.
If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the
specified port instead.

[DenuxPlays]

The image only downloaded 60MB is this right? So the server from steam is 60MB?

It will download the game server files on first launch

The container is running
The container logs reported that he downloaded 60MB

Folder itself is 4.1G which sounds more like it
I don't know 🤷‍♂️
Maybe I am missing something

[Fabricio20]

For future reference, these seem to be all available command options under unix, includes one for the http api -httpproxy=ADDRESS:PORT.

[iceyy0044]

@wolveix

From the official docs (found in game install dir):

Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777. If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the specified port instead.

Does not help me sadly.. running my server on port 2010 and still getting "Failed to Connect to the Server API" when joining using port 2010. Idk if i understood it right tho..

[wolveix]

@wolveix

From the official docs (found in game install dir):

Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777. If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the specified port instead.

Where are you seeing these docs?

[EuleMitKeule]

@wolveix steamapps\common\Satisfactory\CommunityResources\DedicatedServerAPIDocs.md

[ankemp]

@wolveix

PATH\TO\YOUR\INSTALL\CommunityResources\DedicatedServerAPIDocs.md

[wolveix]

Thanks guys!

[wolveix]

Those docs don't seem to be right. It's completely disregarding the flags

[ImKringle]

My own with that set seems to accept it, but it doesnt do anything with it.. Weird.

[2024.09.10-15.59.54:814][  0]LogOnlineVoice: OSS: Voice interface disabled by config [OnlineSubsystem].bHasVoiceEnabled
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: request failed, libcurl error: 56 (Failure when receiving data from the peer)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 0 (  Trying 50.20.249.105:2305...)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 1 (Connected to 50.20.249.105 (50.20.249.105) port 2305)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 2 (CONNECT tunnel: HTTP/1.1 negotiated)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 3 (allocate connect buffer)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 4 (Establish HTTP proxy tunnel to api.ipify.org:443)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 5 (Proxy CONNECT aborted)
[2024.09.10-15.59.54:815][  1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 6 (Closing connection)

[wolveix]

As far as I can tell, there's just no way to specify the API port right now. The bind works for the game port, but not the API port

[ankemp]

@wolveix You should lock this issue, its gone way off the rails.

[LevantinLynx]

[2024.09.10-20.50.12:882][  0]LogHttpListener: Created new HttpListener on 127.0.0.1:7777
[2024.09.10-20.50.12:883][  0]LogServer: Display: Server API listening on '0.0.0.0:7777' (Standalone)

This seams to be the problem. The tcp port always binds on 127.0.0.1, while udp correctly binds to 0.0.0.0

This also happens if one explicitly sets the SERVERIP: '0.0.0.0'. Even if network_mode is set to host...

[wolveix]

It has a little, but I'm fine with leaving it for general discussion.

Please do try to keep the conversation inline with connectivity issues. Game bugs shouldn't really be brought up here, as there's nothing any of us can do about it :)

Not to mention, I suspect many people are watching this thread waiting for a fix. So let's be mindful.

[wolveix]

[2024.09.10-20.50.12:882][  0]LogHttpListener: Created new HttpListener on 127.0.0.1:7777
[2024.09.10-20.50.12:883][  0]LogServer: Display: Server API listening on '0.0.0.0:7777' (Standalone)

This seams to be the problem. The tcp port always binds on 127.0.0.1, while udp correctly binds to 0.0.0.0

This also happens if one explicitly sets the SERVERIP: '0.0.0.0'. Even if network_mode is set to host...

No, once again, both of these issues have been addressed countless times today. Coffee Stain confirmed that the 127.0.0.1 bind is irrelevant, and the SERVERIP variable has been removed from the image. It only served the multihome parameter, which was already deprecated. Please read the opening issue, where I directly explain what Coffee Stain and I were able to determine the issue to be :)

[daniel5gh]

curl -L http://<server-ip>:7777

it should be https. add -v for more info and -k to accept self signed cert. You can also experiment with -4 or -6 to force either ipv4 or ipv6 in case you want more specific tests.

This is the last reply from me here today. It's not that I'm not willing to help out, and while I think this helps multiple people debug their setups, as wolveix mentioned peeps are watching this thread and I don't want to spam semi-unrelated notifications.

[wolveix]

Coffee Stain have now identified the underlying issue, and will release a patch tomorrow 🎉

[wolveix]

We have a fix!! Pushing the code now!

[wolveix]

This issue should now be closed 🎉

Please read the opening issue to ensure that you're running the latest image before reporting that things aren't working for you. Thanks!

[Zblocker64]

Verified I am running correct image, still same error. Running on k8s. Maybe this?

LogNet: Created socket for bind address: 0.0.0.0:0

can verify that it looks like the API server is on the correct port

[2024.09.10-21.57.18:259][  0]LogHttpListener: Warning: HttpListener unable to set desired buffer size (524288): Limited to 425984
[2024.09.10-21.57.18:259][  0]LogHttpListener: Created new HttpListener on 0.0.0.0:31000
[2024.09.10-21.57.18:260][  0]LogServer: Display: Server API listening on '0.0.0.0:31000' (Standalone)```

[LevantinLynx]

And the fix is literally to bind the tcp port to any... [HTTPServer.Listeners]:DefaultBindAddress=any

[Zblocker64]

And the fix is literally to bind the tcp port to any... [HTTPServer.Listeners]:DefaultBindAddress=any

That's why I said maybe.

[wolveix]

@Zblocker64 please open a new issue and fill out the issue template, curious as to what the issue could be! Did you allow both TCP and UDP through for your custom port in your service/ingress files?

[kivle]

This issue should now be closed 🎉

Please read the opening issue to ensure that you're running the latest image before reporting that things aren't working for you. Thanks!

Can verify that the fix immediately worked for me. Thanks for all the effort to get things working. :)

[Zblocker64]

@Zblocker64 please open a new issue and fill out the issue template, curious as to what the issue could be! Did you allow both TCP and UDP through for your custom port in your service/ingress files?

I can do that. Yes I did

[Sociopathssive]

This issue should now be closed 🎉

Please read the opening issue to ensure that you're running the latest image before reporting that things aren't working for you. Thanks!

Thanks you for all the work to drill down to resolve the issue, looking forward to the applied fixes in a day or so!

[wolveix]

@Sociopathssive to be clear, it works 100% right now :) The fix Coffee Stain should release tomorrow will remove the necessity for the current workaround in our launch parameters

[tlewis17]

Works for me too. Also, one note for anyone like me, I had previously mapped multiple TCP/UDP ports as per an older version of the documentation back when I had originally set up my server. When updating to this new version you need to make sure you map 7777 on both TCP and UDP.

[pixelwave]

"Could not connect to the server. Failed to connect to the Server API"

Same issue here ... running Pterodactyl VM on Proxmox Server. Version 0.8 was all fine ... now with 1.0 I have the same error message. Will there be a server update in the next days or do I have to fix configuration manually because of the IP6 issue?

[Tuumke]

Another fix is to bind port 7778 in addition to port 7777 to the container.

networks:
  satisfactory:
    name: satisfactory
    driver: bridge
    enable_ipv6: true
    ipam:
      config:
        - subnet: 192.168.100.0/24
        - subnet: 2001:db8::/64
services:
    satisfactory-server:
        container_name: 'satisfactory-server'
        hostname: 'satisfactory-server'
        image: 'wolveix/satisfactory-server:latest'
        networks:
          satisfactory:
            ipv4_address: 192.168.100.230
        ports:
            - '7777:7777/udp'
            - '7777:7777/tcp'
            - '7778:7778/udp'
            - '7778:7778/tcp'
        volumes:
            - "$DOCKERDIR/games/satisfactory/config:/config"
        environment:
            - PGID=$PGID                  #set the group ID of the user the server will run as
            - PUID=$PUID                  #set the user ID of the user the server will run as
            - AUTOPAUSE=false             #pause game when no player is connected
            - AUTOSAVEINTERVAL=1800       #autosave interval in seconds 1800 == 30 minutes
            - AUTOSAVENUM=5               #number of rotating autosave files
            - AUTOSAVEONDISCONNECT=true   #autosave when last player disconnects
            - CRASHREPORT=true            #automatic crash reporting
            - DEBUG=false                 #for debugging the server
            - DISABLESEASONALEVENTS=true  #disable the FICSMAS event (you miserable bastard)
            - MAXOBJECTS=2162688          #set the object limit for your server
            - MAXPLAYERS=6                #set the player limit for your server
            - MAXTICKRATE=60              #set the maximum sim tick rate for your server
            - NETWORKQUALITY=3            #set the network quality/bandwidth for your server
            - SERVERIP=192.168.100.230        #set the game's ip (usually not needed)
            - SKIPUPDATE=false            #avoid updating the game on container start/restart
            - STEAMBETA=false             #set experimental game version
            - TIMEOUT=300                 #set client timeout (in seconds)
            #- SERVERSTREAMING=true
        restart: unless-stopped
        deploy:
          resources:
            limits:
              memory: 24G
            reservations:
              memory: 12G

[Regtervegter]

I keep reading about the issue on docker but i am running my server on windows and im getting the same issue when trying to remotely connect to my server, but locally i can connect? Not sure if im missing anything on my router even though it used to work before the update? I have allowed UDP 15777 7777 and 15000 via my router.

[wolveix]

@pixelwave you need to update your image. This has been fixed already.

@Regtervegter that's the game bug that will be patched by Coffee Stain tomorrow. But for clarity, you JUST need port 7777/tcp AND port 7777/udp. You can circumvent the bug using the launch param you can see in our run.sh file (on the last line)

[wolveix]

@Tuumke no, again, this does not fix the underlying issue. Update to the latest image, and everything is fixed :) You do not need the IPv6 or net=host workarounds. See the opening post to this issue for more information.

[wolveix]

FOR ANYONE ELSE THAT STUMBLES ACROSS THIS :

If you're still experiencing API connectivity issues, you just need to update the image. You can manually change from:
wolveix/satisfactory-server:latest
To:
wolveix/satisfactory-server:v1.8.1

You also need to ensure that BOTH ports 7777/udp AND 7777/tcp are port forwarded etc. You do not need ANY other ports.

If you see issues about the port binding in the log file, Coffee Stain confirmed to me that these messages are meaningless, please disregard them. The same goes for the certificate being self-signed. If you're getting a certificate key missing error when trying to join, make sure you've added the server through the in-game server manager FIRST.

I have also just updated the README with the details you'd need to upgrade from an old deployment to a new deployment.