Hi William, On Sat, Jul 16, 2022 at 06:43:09PM +0200, William Edwards wrote: > Hi, > > Sorry to bump this, but I haven't made any progress with this on my own. > Does anyone see what I'm missing here? > > > The Tc timer is documented as: > > > > > - Tc: total time to establish the TCP connection to the server. It's > > > the time > > > elapsed between the moment the proxy sent the connection request, > > > and the > > > moment it was acknowledged by the server, or between the TCP SYN > > > packet and > > > the matching SYN/ACK packet in return. The value "-1" means that the > > > connection never established. > > > > The `timeout server` option is documented as: > > > > > The inactivity timeout applies when the server is expected to > > > acknowledge or > > > send data. > > > > However, I have a few connections with a higher Tc than `timeout > > server` (5m), e.g.: > > > > May 25 20:15:33 admin-msh haproxy[1015]: ::ffff:127.0.0.1:33406 > > [25/May/2022:03:18:44.905] redis > > redis/http-msh02.efw.ha.cyberfusion.cloud 1/0/61008353 87670 -- > > 134/113/112/112/0 0/0 > > > > Shouldn't the `timeout server` have closed the connection with the sD > > termination state after 5m if it took 61008353 ms for the server to > > acknowledge the connection request? Or, more likely, am I misreading > > the documentation?
Here you're using TCP logs so the timer you're seeing is the total connection life time from connect to close. The connect time was zero. In addition to this, "timeout server" doesn't affect the connect timeout, only the transfers. It's "timeout connect" which affects the connect timeout. Hoping this helps, Willy
