1. He&#x27;s not wrong, those are not healthchecks, essentially when connection fails (nginx immediatelly tries next server) this works well when service is stopped and host sends response that the port is closed. It fails miserable when host is actually down (which is what happens most of the time in real world). This also won&#x27;t help you when the server is up and application is broken and returns errors, which is another very common scenario.<p>2. This test is unfair, it relies on default settings, where nginx has defaults to retry immediately and never give up. HAProxy by default has this option (option redispatch) disabled because it offers larger range of load balancing algorithms and in some cases this setting might not make sense. The point is that you can configure it to behave the same way.<p>3. In terms of in-flight health checks HAProxy has actual ones (in addition to the above redispatch mechanism) with observe option[1] and on-error[2] it can be programmed to for example simulate healthcheck down when application generates too many 5xx errors.<p>[1] <a href="http:&#x2F;&#x2F;cbonte.github.io&#x2F;haproxy-dconv&#x2F;configuration-1.6.html#observe" rel="nofollow">http:&#x2F;&#x2F;cbonte.github.io&#x2F;haproxy-dconv&#x2F;configuration-1.6.html...</a><p>[2] <a href="http:&#x2F;&#x2F;cbonte.github.io&#x2F;haproxy-dconv&#x2F;configuration-1.6.html#on-error" rel="nofollow">http:&#x2F;&#x2F;cbonte.github.io&#x2F;haproxy-dconv&#x2F;configuration-1.6.html...</a>