@quanzhao wrote:

The problem:

when I reload haproxy, my backend server goes DOWN each time because of DNS timeout, and the output logging is:

[WARNING] 014/190450 (22) : Reexecuting Master process
[WARNING] 014/191701 (22) : parsing [/usr/local/etc/haproxy/haproxy.cfg:51]: 'log-format' overrides previous 'option httplog' in 'defaults' section.
[WARNING] 014/191701 (22) : Setting tune.ssl.default-dh-param to 1024 by default, if your workload permits it you should set it to at least 2048. Please set a value >= 1024 to make this warning disappear.
[WARNING] 014/191701 (22) : [haproxy.main()] Cannot raise FD limit to 2097186, limit is 1048576.
Jan 15 19:17:01 localhost haproxy[22]: Proxy name_resolver_http started.
Jan 15 19:17:01 localhost haproxy[22]: Proxy nginx_nginx-80-servers started.
Jan 15 19:17:01 localhost haproxy[47]: Stopping proxy stats in 0 ms.
Jan 15 19:17:01 localhost haproxy[47]: Stopping frontend name_resolver_http in 0 ms.
Jan 15 19:17:01 localhost haproxy[47]: Stopping backend nginx_nginx-80-servers in 0 ms.
Jan 15 19:17:01 localhost haproxy[47]: Proxy stats stopped (FE: 1676 conns, BE: 10 conns).
Jan 15 19:17:01 localhost haproxy[47]: Proxy name_resolver_http stopped (FE: 1707 conns, BE: 0 conns).
Jan 15 19:17:01 localhost haproxy[47]: Proxy nginx_nginx-80-servers stopped (FE: 0 conns, BE: 3 conns).
[WARNING] 014/191701 (22) : [haproxy.main()] FD limit (1048576) too low for maxconn=1048576/maxsock=2097186. Please raise 'ulimit-n' to 2097186 or more to avoid any trouble.
Jan 15 19:17:01 localhost haproxy[58]: Health check for server nginx_nginx-80-servers/nginx_nginx_9151bcdcd9d17452534689968a4ca067b3da3164a171de7731369a5862c9d646_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 UP.
[WARNING] 014/191701 (22) : Former worker 47 exited with code 0
Jan 15 19:17:12 localhost haproxy[58]: Server nginx_nginx-80-servers/nginx_nginx_9151bcdcd9d17452534689968a4ca067b3da3164a171de7731369a5862c9d646_80 is going DOWN for maintenance (DNS timeout status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
Jan 15 19:17:12 localhost haproxy[58]: backend nginx_nginx-80-servers has no server available!

My haproxy.conf:

global
    maxconn 1048576
    stats socket /var/run/haproxy-admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    pidfile /var/run/haproxy.pid
    log 127.0.0.1 local0
    max-spread-checks 60s
    master-worker no-exit-on-failure
    nbthread 2

resolvers mydns
    nameserver dns1 127.0.0.11:53
    resolve_retries       3
    timeout retry          1s
    hold other             10s
    hold refused          10s
    hold nx                  10s
    hold timeout          10s
    hold valid              10s

defaults
    mode http
    maxconn 1048576

    balance roundrobin
    timeout connect 5000ms
    timeout client 65000ms
    timeout server 65000ms
    timeout tunnel 3600s
    timeout check 5s

    option httplog
    option dontlognull
    option http-server-close
    option abortonclose
    option log-health-checks
    log global
    log-format %ci:%cp\ [%t]\ %Tr\ %s\ %ST\ %B\ %hr\ %hs\ %H\ %{+Q}r

    # If sending a request to one server fails, try to send it to another, 3 times
    # before aborting the request
    retries 3
    #http-reuse safe
    option forwardfor
    # Do not enforce session affinity (i.e., an HTTP session can be served by
    # any Mongrel, not just the one that started the session
    option redispatch
    no option checkcache
    option accept-invalid-http-response
    option accept-invalid-http-request
    default-server init-addr last,libc,none

frontend name_resolver_http
    bind *:80
    errorfile 503 /usr/local/etc/haproxy/errors/503.http
    capture request header Host len 80
    monitor-uri /haproxy-monitor
    acl is_websocket hdr(Upgrade) -i WebSocket

    acl is_appone.example.com hdr_reg(host) -i ^appone.example.com(:[0-9]+)?$
    acl is_appone.example.com_port hdr(host) -i appone.example.com:80
    use_backend nginx_nginx-80-servers if is_appone.example.com or is_appone.example.com_port

backend nginx_nginx-80-servers
    server nginx_nginx_9151bcdcd9d17452534689968a4ca067b3da3164a171de7731369a5862c9d646_80 nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2:80 cookie 9151bcdcd9d17452534689968a4ca067b3da3164a171de7731369a5862c9d646 weight 100 check resolvers mydns

At the same time, I have captured the packets used by tcpdump:

19:17:01.297238 Out 02:42:ac:11:00:04 ethertype IPv4 (0x0800), length 101: (tos 0x0, ttl 64, id 21822, offset 0, flags [DF], proto UDP (17), length 85)
    172.17.0.4.56594 > 100.100.2.138.53: [bad udp cksum 0x1356 -> 0x967e!] 44772+ A? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. (57)
19:17:01.307256  In 02:42:39:3e:c5:dd ethertype IPv4 (0x0800), length 176: (tos 0x0, ttl 63, id 23130, offset 0, flags [none], proto UDP (17), length 160)
    100.100.2.138.53 > 172.17.0.4.56594: [udp sum ok] 44772 NXDomain q: A? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. 0/1/0 ns: . [3h] SOA a.root-servers.net. nstld.verisign-grs.com. 2018011500 1800 900 604800 86400 (132)
19:17:01.307382  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 176: (tos 0x0, ttl 64, id 9331, offset 0, flags [DF], proto UDP (17), length 160)
    127.0.0.11.53 > 127.0.0.1.50611: [bad udp cksum 0xfea9 -> 0xc9b2!] 44772 NXDomain q: A? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. 0/1/0 ns: . [3h] SOA a.root-servers.net. nstld.verisign-grs.com. 2018011500 1800 900 604800 86400 (132)
19:17:01.417324  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 156: (tos 0x0, ttl 64, id 9348, offset 0, flags [DF], proto UDP (17), length 140)
    127.0.0.11.53 > 127.0.0.1.55220: [bad udp cksum 0xfe95 -> 0x49ce!] 51922 q: A? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. 1/0/0 nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. [10m] A 10.254.0.5 (112)
19:17:01.417499  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 156: (tos 0x0, ttl 64, id 9349, offset 0, flags [DF], proto UDP (17), length 140)
    127.0.0.11.53 > 127.0.0.1.53913: [bad udp cksum 0xfe95 -> 0x7275!] 42822 q: A? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. 1/0/0 nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. [10m] A 10.254.0.5 (112)
19:17:01.447001  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 101: (tos 0x0, ttl 64, id 9353, offset 0, flags [DF], proto UDP (17), length 85)
    127.0.0.11.53 > 127.0.0.1.60407: [bad udp cksum 0xfe5e -> 0xf1d5!] 48670 q: AAAA? nginx_nginx.1.uh0hgakyv1pe5pigo2xrligm2. 0/0/0 (57)

We can see the successful DNS response at 19:17:01, but the haproxy process set my nginx backend server DOWN at 19:17:12.

What happened? And the problem is never found in haproxy 1.8.2

Posts: 2

Participants: 2

Read full topic

@yyjdelete wrote:

Tested with make TARGET=cygwin

gcc  -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o src/proto_http.o src/cfgparse.o src/server.o src/stream.o src/flt_spoe.o src/stick_table.o src
/stats.o src/mux_h2.o src/checks.o src/haproxy.o src/log.o src/dns.o src/peers.o src/standard.o src/sample.o src/cli.o src/stream_interface.o src/proto_tcp.o src/backend.o src/proxy.o src/tcp_rules.o src/listener.o src/flt_http_comp.o src/pattern.o src/cache.o src/filter
s.o src/vars.o src/acl.o src/payload.o src/connection.o src/raw_sock.o src/proto_uxst.o src/flt_trace.o src/session.o src/ev_select.o src/channel.o src/task.o src/queue.o src/applet.o src/map.o src/frontend.o src/freq_ctr.o src/lb_fwlc.o src/mux_pt.o src/auth.o src/fd.o
src/hpack-dec.o src/memory.o src/lb_fwrr.o src/lb_chash.o src/lb_fas.o src/hathreads.o src/chunk.o src/lb_map.o src/xxhash.o src/regex.o src/shctx.o src/buffer.o src/action.o src/h1.o src/compression.o src/pipe.o src/namespace.o src/sha1.o src/hpack-tbl.o src/hpack-enc.o
 src/uri_auth.o src/time.o src/proto_udp.o src/arg.o src/signal.o src/protocol.o src/lru.o src/hdr_idx.o src/hpack-huff.o src/mailers.o src/h2.o src/base64.o src/hash.o
src/mux_h2.o: In function `h2s_frt_make_resp_data':
/home/***/haproxy-1.8.3/src/mux_h2.c:3278: undefined reference to `trace'
/home/***/haproxy-1.8.3/src/mux_h2.c:3278:(.text+0x39d0): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:898: haproxy] Error 1

Comment the trace in mux_h2.c works, but is there something wrong with the src or compiler?

nm src/standard.o | grep trace Show

0000000000006300 T .weak.trace.ulltoa
                 w trace

---

Posts: 1

Participants: 1

Read full topic

@GLform wrote:

Hello all,

I use HAProxy for load balancing my HTTP requests. I have 3 front-end servers, let’s say s1, s2, and s3.I would like to know if there is any way to customize the selection of server based on connection session to my application. For example, user1 connecting to http://myapp.com and proxy links user to s1 and all his future requests will be handled only by s1. Then user2 connects to http://myapp.com and his session will be handled only by s2… I would like to know whether its possible to use such kind of routing. Because currently, I see that user’s session is switched between all frontend servers, which is not acceptable for us.

Posts: 1

Participants: 1

Read full topic

@simplexion wrote:

Hi all,
I am still learning how to use haproxy well and was hoping I could receive some feedback for my configuration.

I am using Cloudflare with my setup and SNI to direct traffic. It all appears to be working how I want including PROXY protocol passthrough. Although I could only get that working by adding "option forwardfor header X-Forwarded-For to the SNI pass-through frontend.

My main concern is whether the way I have configured this is secure and/or the most efficient way to configure this set up.

# Global parameters
defaults
    # Slowloris protection
    timeout http-request 5s
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    timeout http-keep-alive 4s

    # Close the backend connection
    option http-server-close

global
	log 10.0.0.10 local0
    maxconn 32000
    ulimit-n 65535
    uid 0
    gid 0
    daemon
    nosplice
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDH
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:EC
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

listen local_health_check
    bind :60000
    mode health

# Frontend for SNI Passthrough
frontend frontend_snipt
    bind *:443
    mode tcp
	log global
	option forwardfor header X-Forwarded-For
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    use_backend backend_snipt_1 if { req_ssl_sni -i 1.domain.com }
    use_backend backend_snipt_2 if { req_ssl_sni -i 2.domain.com }
    use_backend backend_snipt_3 if { req_ssl_sni -i 3.domain.com }
	use_backend backend_snipt_4 if { req_ssl_sni -i 4.domain.com }
	use_backend backend_snipt_5 if { req_ssl_sni -i 5.domain.com }
    default_backend backend_1

# Backend for SNI Passthrough
backend backend_snipt_1
    mode tcp
    server localhost 127.0.0.1:7000 check

backend backend_snipt_2
    mode tcp
    server localhost 127.0.0.1:7001 check

backend backend_snipt_3
    mode tcp
    server localhost 127.0.0.1:7002 check

backend backend_snipt_4
	mode tcp
	server localhost 127.0.0.1:7003 check

backend backend_snipt_5
	mode tcp
	server localhost 127.0.0.1:7004 check

# Normal frontend
frontend frontend_1
	bind *:7000 ssl strict-sni crt /etc/ssl/cloudflare/domain.com.pem
	mode http
	use_backend backend_1

frontend frontend_2
	bind *:7001 ssl strict-sni crt /etc/ssl/cloudflare/domain.com.pem
	mode http
	use_backend backend_2

frontend frontend_3
	bind *:7002 ssl strict-sni crt /etc/ssl/cloudflare/domain.com.pem
	mode http
	use_backend backend_3

frontend frontend_4
	bind *:7003 ssl strict-sni crt /etc/ssl/cloudflare/domain.com.pem
	mode http
	use_backend backend_4

frontend frontend_5
	bind *:7004 ssl strict-sni crt /etc/ssl/cloudflare/domain.com.pem
	mode tcp
	option clitcpka
	timeout client 3h
	timeout server 3h
	use_backend backend_5

# Normal backend
backend backend_1
    mode http
    server server01 10.0.0.10:80 check

backend backend_2
    mode http
    server server01 10.0.0.10:8080 check

backend backend_3
    mode http
    server server02 10.0.0.254:80 check

backend backend_4
	mode http
	server server01 10.0.0.10:8081 check

backend backend_5
	mode http
	server server01 10.0.0.10:8082 check

Posts: 1

Participants: 1

Read full topic

@jtl wrote:

Server: HAProxy 1.7.5 in HTTP/SSL termination mode.

The problem is SSL sites behind my HAProxy load balancer are able to be connected to with Chrome/Firefox/Internet Explorer on Windows OSX and Linux (for the first two). But I’m unable to connect to said sites when using an OS X or iOS client with Safari.

vuYvwPX.png1578x658 16.7 KB

I can connect to http sites terminated at my load balancer from Safari/iOS just fine, just not https sites.

I’m using SSL configuration parameters derived from the Mozilla TLS configuration tool, but have tried weaking them with no success.

    ssl-dh-param-file /etc/ssl/dhparam.pem
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

I get an A result on dev.ssllabs.com so that’s not an issue, per se, but it is something between my SSL setup and something Safari doesn’t like.

Any help is appreciated.

Thanks

Posts: 1

Participants: 1

Read full topic

@vamsiha wrote:

Hi All,

I am facing below issue, Please help.

Jan 17 06:07:15 localhost haproxy[83847]: Proxy LMS_Web started.
Jan 17 06:07:15 localhost haproxy[83847]: Proxy jasperserver-pro started.
Jan 17 06:07:15 localhost haproxy[83847]: Proxy LMS_App started.
Jan 17 06:07:15 localhost haproxy[83849]: Server jasperserver-pro/xyz.domain.com is DOWN, reason: Layer7 wrong status, code: 404, info: “Not Found”, check duration: 8ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
Jan 17 06:07:15 localhost haproxy[83849]: backend jasperserver-pro has no server available!

Below is the my configuration Please help…

frontend LMS_Web
bind :80
bind :443 ssl crt /etc/ssl/certificate.pem
redirect scheme https if !{ ssl_fc }
option httplog
mode http
stats enable
stats uri /stats
stats realm Strictly\ Statistics
stats auth user:pass
acl url_jasperserver-pro path_reg -i jasperserver-pro
acl url_jasperserver-pro url_reg -i jasperserver-pro
use_backend jasperserver-pro if url_jasperserver-pro
default_backend LMS_App

#---------------------------------------------------------------------

static backend for serving up images, stylesheets and such

#---------------------------------------------------------------------
backend jasperserver-pro
balance roundrobin
option httpchk HEAD /keepAlive.txt HTTP/1.0
cookie SERVERid insert indirect nocache
server <URW_hostname> <URW_IP>:8080 check cookie server1

#---------------------------------------------------------------------

round robin balancing between the various backends

#---------------------------------------------------------------------
backend LMS_App
balance roundrobin
option httpchk HEAD /keepAlive.txt HTTP/1.0
cookie SERVERid insert indirect nocache
server <UUW_hostname> <UUW_IP>:80 check cookie server1

Posts: 1

Participants: 1

Read full topic

@onetech-it wrote:

Is there a way to enable the official HAProxy repo, to be able to install the most current builds of HAProxy Community Edition, on CentOS 7.x?

Posts: 1

Participants: 1

Read full topic

@ASA wrote:

resolvers awsdns
nameserver dns 172.30.0.2:53
resolve_retries 3
timeout retry 1s
hold valid 10s
accepted_payload_size 819
global
maxconn 41666
nbproc 6

backend hosts-us-east-1e
balance leastconn

http-reuse aggressive

http-check expect status 200
option httpchk GET /status_emserver

server-template host-rr 70 _http._tcp.us-east-1e.com resolvers awsdns resolve-prefer ipv4 check inter 1s downinter 60s fall 3 weight 1

haproxy -vv
HA-Proxy version 1.8.3-205f675 2017/12/30
Copyright 2000-2017 Willy Tarreau willy@haproxy.org

Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1

Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.1k-fips 8 Jan 2015
Running on OpenSSL version : OpenSSL 1.0.1k-fips 8 Jan 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.21 2011-12-12
Running on PCRE version : 8.21 2011-12-12
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built with network namespace support.

Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

for i in $(seq 1 6); do echo “show servers state” | socat unix-connect:/var/run/haproxy-$i.sock stdio|grep .int|wc -l; done
25
37
25
25
25
25

echo “show servers state” | socat unix-connect:/var/run/haproxy-1.sock stdio
1
be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port
4 hosts-us-east-1e 1 host-rr1 192.168.12.234 2 0 25 1 75258 15 3 4 6 0 0 0 ip-192-168-12-234.internal 80
4 hosts-us-east-1e 2 host-rr2 192.168.13.108 2 0 25 1 75540 15 3 4 6 0 0 0 ip-192-168-13-108.internal 80
4 hosts-us-east-1e 3 host-rr3 192.168.13.243 2 64 25 1 10287 15 3 4 6 0 0 0 ip-192-168-13-243.internal 80
4 hosts-us-east-1e 4 host-rr4 192.168.15.41 2 64 25 1 70953 15 3 4 6 0 0 0 ip-192-168-15-41.internal 80
4 hosts-us-east-1e 5 host-rr5 192.168.15.26 2 64 25 1 10654 15 3 4 6 0 0 0 ip-192-168-15-26.internal 80
4 hosts-us-east-1e 6 host-rr6 192.168.13.106 2 64 25 1 18817 15 3 4 6 0 0 0 ip-192-168-13-106.internal 80
4 hosts-us-east-1e 7 host-rr7 192.168.13.215 2 64 25 1 18821 15 3 4 6 0 0 0 ip-192-168-13-215.internal 80
4 hosts-us-east-1e 8 host-rr8 192.168.14.114 2 64 25 1 10288 15 3 4 6 0 0 0 ip-192-168-14-114.internal 80
4 hosts-us-east-1e 9 host-rr9 192.168.15.175 2 64 25 1 25514 15 3 4 6 0 0 0 ip-192-168-15-175.internal 80
4 hosts-us-east-1e 10 host-rr10 192.168.14.5 2 0 25 1 76103 15 3 4 6 0 0 0 ip-192-168-14-5.internal 80
4 hosts-us-east-1e 11 host-rr11 192.168.15.189 2 64 25 1 71322 15 3 4 6 0 0 0 ip-192-168-15-189.internal 80
4 hosts-us-east-1e 12 host-rr12 192.168.12.87 2 0 25 1 75511 15 3 4 6 0 0 0 ip-192-168-12-87.internal 80
4 hosts-us-east-1e 13 host-rr13 192.168.13.86 2 0 25 1 75612 15 3 4 6 0 0 0 ip-192-168-13-86.internal 80
4 hosts-us-east-1e 14 host-rr14 192.168.13.88 2 0 25 1 75367 15 3 4 6 0 0 0 ip-192-168-13-88.internal 80
4 hosts-us-east-1e 15 host-rr15 192.168.15.228 2 64 25 1 49206 15 3 4 6 0 0 0 ip-192-168-15-228.internal 80
4 hosts-us-east-1e 16 host-rr16 192.168.12.25 2 64 25 1 23400 15 3 4 6 0 0 0 ip-192-168-12-25.internal 80
4 hosts-us-east-1e 17 host-rr17 192.168.14.29 2 0 25 1 75771 15 3 4 6 0 0 0 ip-192-168-14-29.internal 80
4 hosts-us-east-1e 18 host-rr18 192.168.12.50 2 64 25 1 15702 15 3 4 6 0 0 0 ip-192-168-12-50.internal 80
4 hosts-us-east-1e 19 host-rr19 192.168.15.184 0 96 25 1 32707 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 20 host-rr20 192.168.15.46 2 0 25 1 76010 15 3 4 6 0 0 0 ip-192-168-15-46.internal 80
4 hosts-us-east-1e 21 host-rr21 192.168.15.68 0 96 25 1 29974 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 22 host-rr22 192.168.12.103 2 0 25 1 75015 15 3 4 6 0 0 0 ip-192-168-12-103.internal 80
4 hosts-us-east-1e 23 host-rr23 192.168.14.234 0 96 25 1 71661 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 24 host-rr24 192.168.12.154 2 0 25 1 75085 15 3 4 6 0 0 0 ip-192-168-12-154.internal 80
4 hosts-us-east-1e 25 host-rr25 192.168.12.190 2 0 25 1 75171 15 3 4 6 0 0 0 ip-192-168-12-190.internal 80
4 hosts-us-east-1e 26 host-rr26 192.168.12.206 0 96 25 1 70922 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 27 host-rr27 192.168.12.222 2 0 25 1 75354 15 3 4 6 0 0 0 ip-192-168-12-222.internal 80
4 hosts-us-east-1e 28 host-rr28 192.168.12.230 0 96 25 1 25499 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 29 host-rr29 192.168.12.231 2 0 25 1 75787 15 3 4 6 0 0 0 ip-192-168-12-231.internal 80
4 hosts-us-east-1e 30 host-rr30 192.168.12.139 0 96 25 1 34178 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 31 host-rr31 192.168.14.72 0 96 25 1 30499 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 32 host-rr32 192.168.14.141 0 96 25 1 30476 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 33 host-rr33 192.168.15.160 0 96 25 1 68571 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 34 host-rr34 192.168.13.8 0 96 25 1 32355 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 35 host-rr35 192.168.13.79 0 96 25 1 32326 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 36 host-rr36 192.168.14.254 0 96 25 1 27167 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 37 host-rr37 192.168.15.74 0 96 25 1 27190 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 38 host-rr38 192.168.12.198 0 96 25 1 23412 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 39 host-rr39 192.168.12.117 0 96 25 1 29348 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 40 host-rr40 192.168.14.86 0 96 25 1 29328 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 41 host-rr41 192.168.12.134 0 96 25 1 29976 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 42 host-rr42 192.168.15.104 0 96 25 1 68576 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 43 host-rr43 192.168.14.137 0 96 25 1 95956 8 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 44 host-rr44 192.168.13.60 0 96 25 1 26844 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 45 host-rr45 192.168.12.44 0 96 25 1 112406 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 46 host-rr46 192.168.13.222 0 96 25 1 101111 8 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 47 host-rr47 192.168.15.95 0 96 25 1 71291 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 48 host-rr48 192.168.14.74 0 96 25 1 113828 8 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 49 host-rr49 192.168.13.151 0 96 25 1 113117 8 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 50 host-rr50 192.168.12.70 0 96 25 1 115651 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 51 host-rr51 192.168.13.203 0 96 25 1 114944 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 52 host-rr52 192.168.12.109 0 96 25 1 103180 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 53 host-rr53 192.168.15.157 0 96 25 1 56958 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 54 host-rr54 192.168.12.112 0 96 25 1 114180 8 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 55 host-rr55 192.168.15.233 0 96 25 1 56963 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 56 host-rr56 192.168.13.237 0 96 25 1 132812 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 57 host-rr57 192.168.12.126 0 96 25 1 26847 7 2 0 14 0 0 0 - 80
4 hosts-us-east-1e 58 host-rr58 192.168.12.228 2 0 25 1 75936 15 3 4 6 0 0 0 ip-192-168-12-228.internal 80
4 hosts-us-east-1e 59 host-rr59 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 60 host-rr60 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 61 host-rr61 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 62 host-rr62 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 63 host-rr63 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 64 host-rr64 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 65 host-rr65 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 66 host-rr66 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 67 host-rr67 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 68 host-rr68 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 69 host-rr69 0 0 1 1 171432 5 2 0 6 0 0 0 - 0
4 hosts-us-east-1e 70 host-rr70 0 0 1 1 171432 5 2 0 6 0 0 0 - 0

After restart

for i in $(seq 1 6); do echo “show servers state” | socat unix-connect:/var/run/haproxy-$i.sock stdio|grep ec2.int|wc -l; done
37
37
37
37
37
37

CC: @lukastribus @Baptiste

Posts: 1

Participants: 1

Read full topic

@hookprocess wrote:

I have a frontend in http mode where I use this with great success:
use_backend %[req.hdr(host),lower,map_dom(/etc/haproxy/maps.map,be_default)]

Is it possible to do the same for tcp mode and do mapping on req.ssl_sni somehow?

(HA-Proxy version 1.7.5-2 2017/05/17)

Posts: 2

Participants: 2

Read full topic

@jurgenhaas wrote:

What’s the regex syntax used by HaProxy ACL, is that somehow HaProxy specific ore is it using a specific library. I’m asking because each programming language is using their own falvour of regular expressions and I wonder what’s being used by ACL in HaProxy.

Posts: 3

Participants: 2

Read full topic

@ChronosWS wrote:

My understanding of HAProxy is very limited but I think what I am asking here is not possible with HAProxy, and would like confirmation or disconfirmation.

Based on the contents of the first packet, which contains the name of the server, I would map that name to the actual backend servicing the request, possibly starting the server if it is not already started, and then transparently proxying the connection. If my understanding of HAProxy is correct, it cannot do packet inspection on layer 4 proxies (non-HTTP). Is this correct?

If HAProxy cannot do it, is there some other recommendation short of a fully custom proxy which could do this?

Thanks!

Posts: 2

Participants: 2

Read full topic

@bofinity wrote:

Hello,

can somebody tell me how to upgade my haproxy version from 1.5.18 to 1.7.x or 1.8.x ( Running on last Debian Wheezy ) without losing my configuration.
The Tutorial on haproxy.debian.net does not work.

Thanks in advance and nice evening !

Posts: 3

Participants: 2

Read full topic

@Victor wrote:

Hi,

Since upgrading from 1.7.9 to 1.7.10 I’m getting intermittent 504 errors with sR-- for the session termination state. Downgrading back to 1.7.9 fixes the issue. The log for those requests looks like:
%ac 2
%bc 1
%bq 0
%tsc sR–
%TR 0
%Tw 0
%Tc 5
%Tr -1
%Ta 5
%Th 0
%Ti 5874
%B 194
%ac 2
%fc 1
%bc 1
%sc 0
%rc 0
%sq 0
%bq 0

From the point of view of the the app on the backed, the request was processed and the answer sent back in 13ms.

Full haproxy config:

global
  node apne-proxy-1c
  log-send-hostname apne-proxy-1c
  log         127.0.0.1 local5
  chroot      /var/lib/haproxy
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  user        haproxy
  group       haproxy
  daemon

  # Turn on stats unix socket
  stats socket /var/lib/haproxy/stats mode 750 level admin
  stats timeout 30s
  server-state-base /var/state/haproxy/
  server-state-file global

  # Tune TLS
  tune.ssl.default-dh-param 2048
  ssl-default-bind-ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA
  ssl-default-bind-options no-sslv3 no-tls-tickets
  ssl-default-server-options no-tls-tickets
  # The backend servers have self-signed certs
  ssl-server-verify none

  # Tune compression
  maxcompcpuusage 50
  tune.comp.maxlevel 3

  # Tune buffering to accomodate voice + client_cert
  tune.bufsize 32768
  tune.maxrewrite 4096

defaults
  mode     http
#  log      global
  log         127.0.0.1 format rfc5424 local4
  option   httplog
  log-format §apne-proxy-1c§%ci§%cp§%tr§%HM§%[capture.req.hdr(0)]§%HP§%HQ§%HV§%CC§%CS§%[capture.req.hdr(2)]§%[capture.res.hdr(0)]§%ST§%[capture.req.hdr(1)]§%ID§%sslc§%sslv§%[ssl_fc_sni]§%ft§%b§%s§%tsc§%TR,%Tw,%Tc,%Tr,%Ta,%Th,%Ti,%Ts,%B,%ac,%fc,%bc,%sc,%rc,%sq,%bq
  option   log-separate-errors
  option   dontlognull
  option   http-keep-alive
  option   forwardfor
  # Slow POST protection
  option   http-buffer-request
  http-reuse  safe
  load-server-state-from-file global
  retries  3
  timeout  http-request    10s
  timeout  queue           1m
  timeout  connect         10s
  timeout  client          1m
  timeout  server          1m
  timeout  http-keep-alive 10s
  timeout  check           10s
  maxconn  3000
  # Enable compression
  compression algo gzip
  compression type text/html text/plain text/css text/javascript application/javascript application/json application/x-javascript application/xhtml+xml application/xml application/rss+xml application/atom_xml image/svg+xml

peers mypeers
  peer apne-proxy-1b 10.29.0.75:1024
  peer apne-proxy-1c 10.29.1.247:1024

backend idx-backend
  balance roundrobin

  # The sessions to the admin portal are sticky
  stick-table type string len 32 size 1M expire 600s peers mypeers
  stick on req.cook(idx)
  stick store-response res.cook(idx)

  # Health Check
  option  httpchk GET /DaonIdentityX/Monitor/View
  http-check  expect rstring Overall\ Status:\ (OK|WARN)


  # Servers
  server apne-idx-1b apne-idx-1b.local:8443 ssl check inter 3000
  server apne-idx-1c apne-idx-1c.local:8443 ssl check inter 3000
  server apne-idx-1b-02 apne-idx-1b-02.local:8443 ssl check inter 3000
  server apne-idx-1c-02 apne-idx-1c-02.local:8443 ssl check inter 3000


frontend  idx-direct-server-auth-frontend-apne
  # Regular TLS
  bind  10.29.1.247:443 ssl crt /etc/haproxy/tls/example.com.pem

  # tcp current connections, tcp frequency counter, http frequency counter, http err frequency counter
  stick-table type ip size 1m expire 30s store gpc0,conn_cur,conn_rate(3s),http_req_rate(10s),http_err_rate(30s) peers mypeers

  # Track the connections
  tcp-request connection track-sc1 src

  # No tcp restrictions
  acl no_tcp_restrictions src -f /etc/haproxy/lists/no_tcp_restrictions.txt
  # Allowed IPs
  acl trusted_ips src -f /etc/haproxy/lists/trusted_ips.txt

  # No TCP connection restrictions from inside (RP servers and stuff)
  tcp-request connection accept if no_tcp_restrictions or trusted_ips

  # Reject over 50 concurrent connections per ip
  tcp-request connection reject if { src_conn_cur ge 50 }
  # Reject if more than 30 connections in 3 seconds
  tcp-request connection reject if { src_conn_rate ge 30 }

  # No TCP content restrictions from inside (RP servers and stuff)
  tcp-request content accept if no_tcp_restrictions or trusted_ips

  # Reject more than 30 http requests in 10 seconds
  tcp-request content reject if { src_http_req_rate ge 30 }
  # Reject if more than 10 http errors in 30 seconds
  tcp-request content reject if { src_http_err_rate ge 10 }

  # Cert pinning
  rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
  rspadd Public-Key-Pins:\ pin-sha256=\"enWPCYJtvn0yn99pyDJyBRNyw/iBUohykJd9EcFs+Js=\";\ pin-sha256=\"Sv0HHas+e1t1pseiclwN8WZ1i0h4w1/UxerXa2MKG0o=\";\ max-age=15768000;\ includeSubDomains

  # Hide the server info
  # 1.7.x bug
  #rspidel ^Server:.*$
  rspirep ^Server:.*$ Server:\ Hidden

  # Delay to catch L7 info
  tcp-request inspect-delay 5s
  # Capture the host header
  capture request header Host len 64
  # Capture the user agent header
  capture request header User-Agent len 128
  # Capture the SOAP action header
  capture request header SOAPAction len 128
  # Capture the REST correlation ID  header
  capture response header X-Idx-RequestReference len 64
  # Capture the idx cookie
  capture cookie idx len 32

  # Monitor uri
  acl site_dead nbsrv(idx-backend) eq 0
  monitor-uri /test
  monitor fail  if site_dead

  # Check the host
  acl correct_host hdr_reg(host) -i ^apne.example.com(:443)?$
  tcp-request content reject unless correct_host

  # IdX endpoints
  acl admin_portal path_reg ^(/[a-zA-Z0-9-]+)?/IdentityXServices
  acl monitor path_beg /DaonIdentityX/Monitor
  acl favicon path /favicon.ico

  # Allow the Admin portal
  http-request allow if admin_portal
  # Allow the monitor page from trusted IPs only
  http-request allow if monitor trusted_ips
  # Allow the favicon
  http-request allow if favicon

  # The default deny
  http-request deny

  # Backend
  default_backend idx-backend

Not sure if there is something I’m doing wrong, and I was relying on a bug fixed in 1.7.10, or there was a bug introduced in 1.7.10

Thanks,
Victor

Posts: 1

Participants: 1

Read full topic

@newbee wrote:

I am facing connection churn issue when I am using keep-alive and http-tunnel introduces un-even load balancing at the backend.

Should I use below -

option http-keep-alive
optiuon http-server-close
http-reuse always

Posts: 1

Participants: 1

Read full topic

@happy wrote:

Apache benchmark shows a lot of SSL failures during reloads. Failures appear after a reload is finished.

Possibly, it is not a problem, because conditions are very specific and the same shows also qdisc-method.

SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).
SSL read failed (1) - closing connection
139687255426944:error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:…/ssl/ssl_lib.c:1735:

Conditions:

• Debian 8 x64, 4.9, systemd + HA-Proxy version 1.8.3-a91f55-27 (USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1)
• 30 test-threads + extremely low-end CPU + RSA-4096 to make it slow (about 25 requests \ sec, request time 1-1.5 sec)
• Very large cfg-file with a lot of backends and big lua-includes

Posts: 1

Participants: 1

Read full topic

@onetech-it wrote:

've got a clean JIRA 7.5.2 install running on CentOS. It uses the default 8080 port for http requests, and I’ve also enabled an SSL certificate to enable https requests on port 8443.

I want to run HAProxy in front as a reverse proxy server, to redirect http:80 -->8080 and https:443 --> 8443.

It looks as if using the very simple “listen” config setting in HAProxy is what I’ll need, however I’m not sure bout how to:

a) Modify the JIRA server.xml file so that the Connector 8443 configuration is properly set to return the correct values for reverse proxy from https (443)
b) How to configure a ‘listen’ entry in the haproxy.cfg file that properly references the SSL certs on my server, to allow for proper forwarding of https requests to the backend server’s SSL listener on 8443.

Posts: 1

Participants: 1

Read full topic

@onetech-it wrote:

I have a site doing simple reverse proxying (https 443 haproxy frontend --> http 8080 on the backend).

Is there a simple config entry for HAProxy to force http 80 requests on the front end, to redirect to https 443 on the front end and then get proxied to the backend?

Posts: 1

Participants: 1

Read full topic

@happy wrote:

Most of HTTPS requests with HTTP/2 are slower than normal.
And there are some requests that are slower in 3-10 times. An extra time appears on “read request” stage.

Example:

• HTTP/1.1 https://prnt.sc/i5p0hs
• HTTP/2 https://prnt.sc/i5p0vr

I’ve tested with GTMetrix (some pages have 3-5 longer average full-load time), DareBoost and local test with Hey

For local test I’ve used single 14MB file and 10 threads.

• Average request-time degradation 20-30%
• Slowest requests are 1.5-3 times worse

It is with default tune-h2 settings.

Changing to the maximum header-table-size and 512MB initial-window-size makes it a bit better, but it is still much worse than HTTP/1.1.

HA-Proxy version 1.8.3-a91f55-27 (USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1)

Posts: 1

Participants: 1

Read full topic

@onetech-it wrote:

I’ve got HAProxy running as a reverse proxy on a CentOS 7.4 box, with JIRA (Tomcat server) as the backend application and it proxies from https 443 to the non-SSL port on the JIRA server without issue.

However, on three other servers that are also running Tomcat apps on the backend, setting up the exact same reverse proxy and HAProxy haproxy.cfg (changing hosts and ports, of course) and they return 503 Service Unavailable errors. I can confirm that the Tomcat servers are up and running and accessible on their non-SSL ports so the servers are behaving exactly like the working one. This seems to be HAProxy related?
cfg is below. Any ideas?
#---------------------------------------------------------------------

Global settings

#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the ‘-r’ option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2

chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     4000
user        haproxy
group       haproxy
daemon

# turn on stats unix socket
stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------

common defaults that all the ‘listen’ and ‘backend’ sections will

use if not designated in their block

#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

#---------------------------------------------------------------------

main frontend which proxys to the backends

Tells HAProxy to start listening on for HTTPS requests. It uses the SSL key

and certificate found within the corp.company.com.pem file. All requests will

be routed to the confluence_http_backend

#---------------------------------------------------------------------
frontend confluence_http_frontend
bind *:443 ssl crt /etc/pki/tls/keystore/corp.company.com.pem
default_backend confluence_http_backend

#---------------------------------------------------------------------

static backend for serving up images, stylesheets and such

The confluence_http_backend simpl forwards all requests onto http://dev-wiki.corp.xperi.com:8090/.

It will only allow 1000 concurrent connections to the server at once.

#---------------------------------------------------------------------
backend confluence_http_backend
mode http
option httplog
option forwardfor

option httpchk

server server01 server.corp.mydomain.com:8090 maxconn 1000

balance roundrobin

#---------------------------------------------------------------------

round robin balancing between the various backends

#---------------------------------------------------------------------
#backend app

balance roundrobin

server app1 127.0.0.1:5001 check

server app2 127.0.0.1:5002 check

server app3 127.0.0.1:5003 check

server app4 127.0.0.1:5004 check

Posts: 1

Participants: 1

Read full topic

@quanzhao wrote:

When I add more than 100 servers e.g. 150 into the only one backend, the health check state is DRAIN, but when I reduce to no more than 100 e.g. 100, it’s UP.
Is this normal logic for haproxy?

haproxy version: 1.8.3

The partial output logging:

Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_85d113086d3fb578da40c194b8fd583fae5b2452f7cbad637737244ef0635738_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 DRAIN.
Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_88e4819756a7787ae6a6623196b9750de1862bb780167d3c135e483b84982c04_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 DRAIN.
Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_89dbcb2a67843c1bb9c1b0ecd16dd6610051bce6fc5c5e76bc53fd19ef51d425_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 DRAIN.
Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_8ae01f7d258b116870cbda5be591913aad7d79b94821ef5607ff12e4f10e4d15_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 DRAIN.
Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_8c327f4d456bec25d615f7a107a483353962ecc54a8434563c4b5a6f3c4fd403_80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 3/3 DRAIN.
time="2018-01-26T11:32:04+08:00" level=info msg="reloading haproxy | current pid: 1, master pid: 19"
[WARNING] 025/113203 (19) : Reexecuting Master process
Jan 26 11:32:04 localhost haproxy[2018]: Health check for server nginx_nginx-80-servers/nginx_nginx_8f1f7d5313626d5b32d17b0fe2e4aa2fc1b853c699c8177a86c69dced0974531_80 succeeded, reason: Layer4 check passed, check duration: 1ms, status: 3/3 DRAIN.

Posts: 1

Participants: 1

Read full topic