[HELP] ERROR 56 net_tcpConnLimit

Because my server cannot enter more than 15 people if you delete this line from the server.cfg: set net_tcpConnLimit 100, but if I leave it the same when you enter more than 80 the same thing begins to happen. Roll an error 56.

What?

Are you using some kind of DDoS mitigation proxy? Or some really old FXServer build? What do you mean by ‘roll an error’?

1 Like

What happens is that if not I put this in server.cfg

net_tcpConnLimit 100

When more than 15 people enter, throw this error:

20210103_235428

1 Like

Having the same issue over here, I tried to remove rate limit on the config file but it seems like its not doing anything, web API is still rate-limiting the reverse proxy.

@nta Might you be able to help us with this? Still, we have not found a solution for this, some guidance would be extremely handy.

It’s hard to even tell what issue you’re experiencing. Try setting it even higher, assuming you are using a proxy?

I attempted to set it to the highest possible value (maximum value of an integer), it made things better until reaching 100 players. Could it be our proxy setup? we are using NAT forwarding for UDP/TCP and Nginx for HTTP.
The issue relies on the HTTP API, we end up getting a rate limit message when using the proxy.

It is very simple, people start connecting to the server, when the server has aproximately 15 users - they start getting the error ‘CURL error code 56’ (screenshot above)

If they put the command net_tcpConnLimit on the server.cfg or via console command, more than 15 people can join but when reaching 60 or more players, info.json starts getting ‘Rate limit exeeced’ via HTTP.
Also, when players want to join the server, they must try 2 or 3 times since they get the same error as above ‘CURL error code 56’

What does the command net_tcpConnLimit do exactly? there is no documentation whatsoever about this command.

Thanks

1 Like

You are most likely getting attacked, had this issue before OVH correctly setup their VAC config, but I had to send them like 4-5 tcp dumps.

If you are using OVH, which most likely looks like you are try to contact their support, and if you’re using another host, do the same for them and see what protection they have.

I am the hosting owner, there is no attack and no protection - so I assume it is a FiveM bug.

If it were a bug, why do the majority of servers not experience this issue?

Try finding the correlation in there, and you would probably find the underlying cause.

Either way, blaming it on a “lack of documentation” or “just a fivem bug, not my fault” won’t help get such an issue resolved.

Likely you are using an old server version, have a reverse proxy setup incorrectly, or are using an unconventional network setup for this to happen.

In addition to that, this topic appears to have turned into 4 people asking at least 2 different questions. Please, start a new topic if you have an independent issue and don’t hijack existing topics even if they sound tangentially related.

I have tried everything possible, that is why I came to the forums - changed server port, changed Windows OS and other things that do not come to my mind right now.

Either way, you are not helping too, I assume that it is a bug since there is nothing wrong in our side, the port forward is OK and there are no attacks, no dropped packets, no saturation on network.

Why without the net_tcpConnLimit does not work, and with the net_tcpConnLimit works?

I am only the server hoster, Daviten has a rental server with me, and I am trying to help him.

How would anyone here know, when again, it works fine for everyone else, and we don’t have access to your server?

Also, you’re still not answering any of the questions asked in this topic.

Ah, right, you’re providing FiveM-specific server hosting, then.

Bye!

If anyone has a similar unique issue, please post a new topic and answer the relevant questions.

Don’t ask via someone else (at least without specifying you’re related at first…?!), and remember the ground rules: don’t place blame unless you can back your blaming up, and don’t ask ‘why?’ when you know nobody can answer that question.