In my case I have multiple backends (Tomcats) all configured with the same virtual hosts and:
backend app1
option http
…
option httpchk GET /rest/util/setting HTTP/1.0\r\nHost:\ app1.virtualhosttomcat.local:8080\r\n
…
server talaiaclu01-app1 192.168.211.13:8080 cookie server1 maxconn 1000 check inter 5000
server talaiaclu02-app1 192.168.211.14:8080 cookie server2 maxconn 1000 check inter 5000
Behaviour seems to send this check with same header to each server. So in my scenario, different than yours, it’s working. Maybe you can achieve this approache in your scenario.
It’s a strange requirement to use different Host headers for the backend servers, when they are serving in the same backend and the same services.
How does your customer connect to the backend application, when your backend server requires different Host header and haproxy load-balances?
You could probably workaround this by not health checking in the actual backend but outsource the healthcheck to dedicated backends (with the track directive).
My Backend servers are deployed in cloudfoundry and as per cloudfoundry- only way to route traffic to an app is using the virtual hostname:
In Cloud Foundry, a hostname is the label that indicates a subdomain of the domain associated with the route. Given a domain shared-domain.example.com, a developer can create the route myapp.shared-domain.example.com in space my-space by specifying the hostname myapp with the cf create-route command as shown in this example:
Perhaps there can only be one healthcheck per backend, and HAProxy is using the last one you defined. I wonder why, if you have two backends, you don’t define two backends, iso. one backend with two servers.
That I understood. What I do not understand is how you expect your customers host header to be different for one server as opposed to another when haproxy is load balancing to different servers?
More specifically, how is the browser/app-client/customer supposed to send customerlookup.xxx.px-prd02.cf.xxxx.com:443 for one server and customerlookup.xxx.px-prd03.cf.xxxx.com:443 for the other?
I’m sure you have a valid use-case, I just not understand it yet.
It would look like this for example:
backend check_customerlookup.xxx.px-prd02.cf.xxxx.com
option httpchk GET /env HTTP/1.1\r\nHost:\ customerlookup.xxx.px-prd02.cf.xxxx.com:443\r\n
server prd02 192.168.211.13:8080 cookie server1 maxconn 1000 check inter 5000
backend check_customerlookup.xxx.px-prd03.cf.xxxx.com
option httpchk GET /env HTTP/1.1\r\nHost:\ customerlookup.xxx.px-prd03.cf.xxxx.com:443\r\n
server prd03 192.168.211.14:8080 cookie server1 maxconn 1000 check inter 5000
backend app1
server talaiaclu01-app1 192.168.211.13:8080 cookie server1 maxconn 1000 track check_customerlookup.xxx.px-prd02.cf.xxxx.com/prd02
server talaiaclu02-app1 192.168.211.14:8080 cookie server2 maxconn 1000 track check_customerlookup.xxx.px-prd03.cf.xxxx.com/prd03
here is my config , when i have one server in backend.
Clients talk to https://:8003 and if SOAPAction is “searchCustomer”- it will be routed to searchCustomer backend and then routed to server “customerlookup.xxx.px-prd02.cf.xxxx.com:443”.
Thank You @lukastribus. Your solution is working for me. Thank you for all the help. here is the latest config, which solved the issue. but I do have a curious question (no complains though!). We can close this issue for now.
is there an opportunity to concise this configuration? now for each backend, I have to write two additional healthcheck backends ( and this might go up, if my infra adds another environment). ?
