Mathieu, 

I have often been fooled like this by multiple haproxy instances running at the 
same time.
Whenever I had restarted them with config changes there were sometimes open 
client connections keeping instances with older configs alive. Those would 
respond to a random set of the connections.
So I suggest you make sure first you have exactly one instance running, e. g. 
with “ps aux | grep haproxy”.

Daniel

-- 
Daniel Schneller
Principal Cloud Engineer
 
CenterDevice GmbH                  | Hochstraße 11
                                   | 42697 Solingen
tel: +49 1754155711                | Deutschland
daniel.schnel...@centerdevice.de   | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431


> On 13. Feb. 2017, at 15:45, Mathieu Poussin <math...@lodgify.com> wrote:
> 
> Hello.
> 
> I have setup HAProxy on our environment and I can see a very strange 
> behaviour. 
> 
> I have the following configuration (Just a part of it) :
> 
> global
>         chroot /var/lib/haproxy
>         user haproxy
>         group haproxy
>         daemon
>         tune.maxrewrite 4096
> 
> ################
> ### Defaults ###
> ################
> 
> defaults
>         mode    http
>         option  httplog
>         option  dontlog-normal
>         option  dontlognull
>         option  log-health-checks
>         option  redispatch
>         option http-server-close
>         unique-id-header X-LB-Request-ID
>         log-format %{+Q}r\ %ST\ "%CC"\ "%hr"\ "%CS"\ "%hs"\ %ID
> 
>         timeout connect 5000
>         timeout client 50000
>         timeout server 50000
> 
> frontend websitemanager
>         bind *:8004
>         log global
>         capture request header Host len 128
>         capture request header X-Real-IP len 128
>         capture request header X-LB-Request-ID len 128
>       capture request header X-HAProxy-Key len 128
>       http-request set-var(txn.x_haproxy_key) req.hdr(X-HAProxy-Key)
>       http-request set-var(txn.x_real_ip) req.hdr(X-Real-IP)
>         http-request set-var(txn.url) url
>         mode http
>         default_backend websitemanager
> 
> backend websitemanager
>         mode http
>         log global
>         balance roundrobin
>         option httpchk GET /health/ HTTP/1.0
>         http-check expect ! string false
>       acl debug_headers var(txn.x_real_ip) xxx.xxx.xxx.xxx
>         acl debug_headers var(txn.x_haproxy_key) -m str -i xxx
>         acl debug_headers var(txn.referer) -m sub -i haproxy-key=xxx
>         acl debug_headers var(txn.url) -m sub -i haproxy-key=xxx
>         http-response set-header X-HAProxy-Frontend-Name "%f" if debug_headers
>         http-response set-header X-HAProxy-Frontend-Socket "%fi:%fp" if 
> debug_headers
>         http-response set-header X-HAProxy-Backend-Group "%b" if debug_headers
>         http-response set-header X-HAProxy-Backend-Name "%s" if debug_headers
>         http-response set-header X-HAProxy-Backend-Socket "%si:%sp" if 
> debug_headers
>         http-response set-header X-HAProxy-Via "%H" if debug_headers
>         http-response set-header X-HAProxy-TerminationState "%ts" if 
> debug_headers
>         http-response set-header X-Real-IP "%[var(txn.x_real_ip)]"
>         server gc-certmgr-live-1 10.0.0.49:80 check observe layer7 on-error 
> mark-down slowstart 10s weight 100
>         server gc-certmgr-live-2 10.0.0.50:80 check observe layer7 on-error 
> mark-down slowstart 10s weight 100
>         server gc-certmgr-live-3 10.0.0.51:80 check observe layer7 on-error 
> mark-down slowstart 10s weight 100
> 
> And many other fronted/backend combo with the same configuration (The same 
> ACL).
> Basically, I want the X-HAProxy headers to appears in any of the following 
> condition :
> - The connection is coming from HQ (Specific X-Real-IP header)
> - The header X-HAProxy-Key header is present and set to the correct key
> - The Referer contains the key
> - The URL contains the key as parameter
> 
> I have a nginx in front of this setup, that is setting up the X-Real-IP.
> I’ve checked the logs, and the connection is forwarded to HAProxy in all the 
> cases, so nginx is not the cause of the issue (Or at least it’s still 
> forwarding to HAProxy)
> 
> 
> Almost half of the requests are failing the ACL where they should work 
> without issue (Because the source IP matches or because of the connection 
> string.
> 
> It’s completely random, I have no idea why it’s doing that.
> 
> What could be the cause ? I could not find much googling for this issue.
> 
> My version is HA-Proxy version 1.7.2-6edf8f-4
> 
> Thank you.
> Best regards,
> Mathieu
> 

Reply via email to