# TCP ReadTimeout and Minecraft Server

**URL:** https://community.traefik.io/t/tcp-readtimeout-and-minecraft-server/24082
**Category:** Traefik v2
**Tags:** tcp
**Created:** [August 20, 2024, 6:05pm UTC](https://community.traefik.io/t/tcp-readtimeout-and-minecraft-server/24082 "2024-08-20T18:05:16Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Ziroy](https://sea2.discourse-cdn.com/flex020/user_avatar/community.traefik.io/ziroy/32/9205_2.png) [@Ziroy](https://community.traefik.io/u/Ziroy)
#### Post date: [August 20, 2024, 6:05pm UTC](https://community.traefik.io/t/tcp-readtimeout-and-minecraft-server/24082/1 "2024-08-20T18:05:16Z")

</div>

Hello everyone,

I have set up a Minecraft Server on my Kubernetes cluster. I have set up a IngressRouteTCP crd and can successfully connect via the Traefik load balancer to the Minecraft Server. For some reason, however, I always get disconnected from the Server after exactly **60** seconds.

The error message I got is this:

`time="2024-08-20T17:47:25Z" level=error msg="Error while handling TCP connection: readfrom tcp 10.1.182.26:43382->10.1.182.63:25565: read tcp 10.1.182.26:25565->x.x.x.x:19887: i/o timeout"`

Putting this into google, one arrives at the following issue, which tracks setting the default limit for ReadTimeouts to **60** seconds.

> <https://github.com/traefik/traefik/issues/10598>
>
> \### Welcome!
> 
> \- \[X\] Yes, I've searched similar issues on \[GitHub\](https://gith…ub.com/traefik/traefik/issues) and didn't find any.
> \- \[X\] Yes, I've searched similar issues on the \[Traefik community forum\](https://community.traefik.io) and didn't find any.
> 
> \### What did you do?
> 
> 2.11.1 shouln't breaks connections.
> 
> \### What did you see instead?
> 
> 2.11.1 breaks connections in some use cases.
> 
> There is currently a CVE which affects Traefik, it's not yet published (work in progress).
> The 2.11.1 release was packed with this \[PR\](https://github.com/traefik/traefik/pull/10569), introducing \`respondingTimeouts.lingeringTimeout\` to mitigate the vulnerability. This implementation was carefully chosen after many discussions to avoid being breaking at all costs. Sadly, we haven't anticipated all use cases, and many issues have been opened by the community since the release.
> 
> We made the decision to rollback the \[lingeringTimeout PR\](\[PR\](https://github.com/traefik/traefik/pull/10569)), and to provide a simpler fix by tomorrow.
> ⚠️ \*\*We haven't been able to find a fix for this vulnerability that is not breaking at some point\*\*. However, the new fix we are going to provide is simpler to understand and configure to fit your needs.
> 
> We will update this issue while progress is made. 
> 
> \### What version of Traefik are you using?
> 
> 2.11.1 & 3.0.0-rc4

Sure enough, change the value to 10 and you get disconnected after 10 seconds.

The migration guide for v3 also states this change:

> starting with `v2.11.2` the entryPoints readTimeout option default value changed to 60 seconds.
> 
> For HTTP, this option defines the maximum duration for reading the entire request, including the body. For TCP, this option defines the maximum duration for the first bytes to be read on the connection.

> **[Traefik Migration Documentation - Traefik](https://doc.traefik.io/traefik/v3.0/migration/v2/#entrypointtransportrespondingtimeoutsreadtimeout)**
>
> Learn the steps needed to migrate to new Traefik Proxy v2 versions, i.e. v2.0 to v2.1 or v2.1 to v2.2. Read the technical documentation.

It is confusing to me how this can happen since the Minecraft Server and the client are clearly communicating to each other as can be verified by the network activity of my localhost.

 ![image](https://us1.discourse-cdn.com/flex020/uploads/containo/original/2X/7/79a8836de40a69beb5b55da467d7602d7e799804.png)

Until all of a sudden, the TCP connection is closed.

 ![image](https://us1.discourse-cdn.com/flex020/uploads/containo/original/2X/b/bd1b0cf3f1a8d3a3c85a304b1919543517e2ee9f.png)

I have also tested increasing the read timeout to 10 minutes and still get the same results. Setting it to infinite fixes the issue but makes the service vulnerable to denial of service attacks ([Possible DoS vulnerability with Content-length header · Advisory · traefik/traefik · GitHub](https://github.com/traefik/traefik/security/advisories/GHSA-4vwx-54mw-vqfw)).

Do you think this is an issue in the way Traefik determines whether the first bites have been sent or does this have to do with the way Minecraft communicates?

* * *

For reference: Traefik Version: 2.11
