I'm having the same issues since the latest update (1.5.18-9.el7). I'am using the tcp-checks for a high available redis cluster which is not working after this update.

When reverted back to 1.5.18-8.el7 it's working again.

I'm not convinced this is a bug. Please see rhbz#1677420. Note that this bug refers to multiple tcp-checks and only the last tcp-check is ignored/invalidated. The last tcp-check was never actually checked and therefore always returned 'success'. If I recall, this also applied to single tcp-check configurations. The single tcp-check is also the last, and it was never validated. In short, it appeared the tcp-check was working when it was not. Consider this a false positive. Now that it has been fixed, users may (correctly) see failed tcp-checks that they previously seemed to work correctly.

All this said, I'm happy to investigate if we can prove that haproxy is indeed mishandling tcp-check. In order to determine this, use tcpdump to show the connections are actually happening as expected. If using send/expect, also try to verify the server is responding correctly. If you're seeing a timeout, consider increasing the timeout. Also, it is highly advisable that you specify the port in a 'tcp-check connect' statement.

The upstream bug referenced in comment #2 does not seem applicable here since were are talking about haproxy-1.5.

Pretty sure this is at last for tcp-check expect string a bug:
haproxy opens the connection, I send the expected string, and haproxy never closes the connection. Even if the server closes it, haproxy keeps the connection open until the timeout happens. (For the three minute timeout after the tcp-fin was received.)

(In reply to Curtis Taylor from comment #0)
> Description of problem:
> haproxy with tcp-check send followed by tcp-check expect gets:
> haproxy[1153]: Server kairosdb_telnet/kaip1.site.com is DOWN, reason: Layer7
> timeout, info: " at step 1 of tcp-check (send)", check duration: 10001ms. 1
> active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining
> in queue.
> 
> Version-Release number of selected component (if applicable):
> haproxy 1.5.18-9.el7
> 
> How reproducible:
> (Customer can.. still working on local reproduction)
> RHEL7.7 haproxy server
> 
> Steps to Reproduce:
> 1. With RHEL7.7 haproxy server
> 2. Listen stanza like:
> listen kairosdb_telnet
>   bind 10.0.0.1:4210 
>   mode tcp
>   balance roundrobin
>   option tcplog
>   option tcp-check
>   tcp-check send version\n
>   tcp-check expect rstring KairosDB \d+\..*
>   server kaip1.site.com 10.0.0.55:4210 check
>   server kaip2.site.com 10.0.0.56:4210 check

There is no 'tcp-check connect' rule. This is required. Upstream documentation [1] states:

"In a tcp-check ruleset a 'connect' is required, it is also mandatory to start
the ruleset with a 'connect' rule. Purpose is to ensure admin know what they
do."

[1] http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4-tcp-check%20connect

Thanks Ryan!  That solved the issue in the case for which I opened this BZ.  

Now an example working listen stanza is:

listen sshapp
  bind 192.168.122.121:2222
  mode tcp
  balance roundrobin
  option tcplog
  option tcp-check
  tcp-check connect port 22
  tcp-check send \n
  tcp-check expect string SSH-2.0-OpenSSH_7.4
  server cutaylor 192.168.100.1:22 check port 22

Since a correct configuration worksforme, I'm closing the BZ.

Thanks,

So the Red Hat version works like documented.
Adding tcp-check connect helps for me too.
But neither haproxy 2.0 nor haproxy 1.5 from upstream needs this IMHO redundant statement.
So I think it will still break a lot of configurations out there.
Btw: SSH is not a text/line based protocol. It just sends the Version string if you connect: 
tcp-check send \n makes no sense. (Also it dosen't break anything at the moment.)
But maybe some other Red Hat Maintainer patches OpenSSH to remove this undocumented working configuration.

But for me it works too.