@poulterer wrote:

Was this intended functionality or an oversight?

Posts: 1

Participants: 1

Read full topic

@Amine97 wrote:

Hi,
i’m using Haproxy 1.8 on Debian 9 and under /etc/haproxy/ i have splitted my config file into haproxy.cfg , haproxyListen.cfg , haproxyRule1.cfg and haproxyRule2.cfg , the first file contains sections Global and default , the second file contains stats web page , and the last files contain frontend and backend rules…
i’m trying to load the config using the command haproxy -f /etc/haproxy/ it works but generates many pids ( 2 usual pids and third one ) and it causes problem after cuz the third PID ruin the service and doesn’t go away, and when i tried with haproxy -c -f /etc/haproxy/ i got “configuration file is valid” but it doesn’t load the other files … tried also to chain all files with their path together in the same command using -f but did’nt work also … Help plz

Posts: 1

Participants: 1

Read full topic

@squigley wrote:

Hi,

I have configured HAProxy with stick tables and syncing between proxies, on 2 hosts using CARP with a shared IP, however when I cause a failover between the hosts by making the CARP IP move, my existing connection via HAProxy gets terminated.

My expectation is that these are being terminated as the tcp connections don’t exist on the CARP slave which takes over, however from my experience using pfSense, with CARP and pf-sync, I know it’s possible to have 2 machines share both an IP, and all the states which exist, in order to do failover and maintain existing connections.

I am wondering if it is possible to use both CARP with pf-sync and HAProxy with stick tables/peering, so that in the case of a CARP failover, the connection between the client and backend server can be maintained.

At the moment I am trying to get pf configured correctly, (and wondering if I have to do something funny like routing/natting the connection back to itself from the CARP ip to HAProxy on localhost)… Is this scenario something that is likely to work, or am I wasting my time, and regardless of what failover method is implemented, the connection is going to be broken when a failover takes place?

Posts: 1

Participants: 1

Read full topic

@krisarmstrong wrote:

Hi,

I want first to state I am very new to HAProxy so there very well may be a configuration issue here.

I am hosting guacamole behind HAProxy, and the connection seems to reset. I have a copy of the logs from the guacamole Syslog server.

HAProxy is running on a PFSense firewall.

The below only occurs when accessing from the external URL. When accessing from the internal network, it works fine no issues.

i.e. guacamole.domain.net (resets) public IP
10.0.1.225:8080 (dose not reset)

I’m not sure where the HAProxy logs are on the PFSense box yet if anyone knows I’m happy to gather those and the configuration files as well.

Guacamole Syslog:
indent preformatted text by 4 spaces
Jun 19 23:04:37 guacamole guacd[1904]: Internal RDP client disconnected
Jun 19 23:04:37 guacamole guacd[1049]: Connection “$aaef4b02-bccf-4260-87f5-70be270b9a68” removed.
Jun 19 23:04:37 guacamole guacd[1049]: Creating new client for protocol “rdp”
Jun 19 23:04:37 guacamole guacd[1049]: Connection ID is “$2dfe14bf-c43b-4e36-98d3-14969ba3d352”
Jun 19 23:04:37 guacamole guacd[1920]: Security mode: ANY
Jun 19 23:04:37 guacamole guacd[1920]: Resize method: none
Jun 19 23:04:37 guacamole guacd[1920]: User “@390854a2-21dd-418a-9b70-63cfd79fa5bb” joined connection “$2dfe14bf-c43b-4e36-98d3-14969ba3d352” (1 users now present)
Jun 19 23:04:37 guacamole guacd[1920]: Loading keymap “base”
Jun 19 23:04:37 guacamole guacd[1920]: Loading keymap “en-us-qwerty”
Jun 19 23:04:38 guacamole guacd[1920]: guacdr connected.
Jun 19 23:04:38 guacamole guacd[1920]: guacsnd connected.
Jun 19 23:04:40 guacamole guacd[1920]: Connected to RDPDR 1.12 as client 0x0004
Jun 19 23:04:40 guacamole guacd[1920]: Ignoring server capability set type=0x0001, length=44
Jun 19 23:04:40 guacamole guacd[1920]: Ignoring server capability set type=0x0002, length=8
Jun 19 23:04:40 guacamole guacd[1920]: Ignoring server capability set type=0x0003, length=8
Jun 19 23:04:40 guacamole guacd[1920]: Ignoring server capability set type=0x0004, length=8
Jun 19 23:04:40 guacamole guacd[1920]: Ignoring server capability set type=0x0005, length=8
Jun 19 23:04:40 guacamole guacd[1920]: Sending capabilities…
Jun 19 23:04:40 guacamole guacd[1920]: Capabilities sent.
Jun 19 23:04:40 guacamole guacd[1920]: Client ID confirmed
Jun 19 23:04:46 guacamole guacd[1920]: Connected to RDPDR 1.12 as client 0x0001
Jun 19 23:04:46 guacamole guacd[1920]: Ignoring server capability set type=0x0001, length=44
Jun 19 23:04:46 guacamole guacd[1920]: Ignoring server capability set type=0x0002, length=8
Jun 19 23:04:46 guacamole guacd[1920]: Ignoring server capability set type=0x0003, length=8
Jun 19 23:04:46 guacamole guacd[1920]: Ignoring server capability set type=0x0004, length=8
Jun 19 23:04:46 guacamole guacd[1920]: Ignoring server capability set type=0x0005, length=8
Jun 19 23:04:46 guacamole guacd[1920]: Sending capabilities…
Jun 19 23:04:46 guacamole guacd[1920]: Capabilities sent.
Jun 19 23:04:46 guacamole guacd[1920]: Client ID confirmed
Jun 19 23:04:46 guacamole guacd[1920]: User logged on
Jun 19 23:04:46 guacamole guacd[1920]: All supported devices sent.

Posts: 1

Participants: 1

Read full topic

@safari wrote:

We got a coredump with our haproxy latest version 2.0.0, this process only handles just SSL traffic.

“bt full” gdb output as follow:

Program terminated with signal 6, Aborted.
#0 0x00007f44f3cef207 in __GI_raise (sig=sig@entry=6) at …/nptl/sysdeps/unix/sysv/linux/raise.c:55
55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt full
#0 0x00007f44f3cef207 in __GI_raise (sig=sig@entry=6) at …/nptl/sysdeps/unix/sysv/linux/raise.c:55
resultvar = 0
pid = 6653
selftid = 6658
#1 0x00007f44f3cf08f8 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x55555554, sa_sigaction = 0x55555554}, sa_mask = {__val = {1179670597, 22142000, 8, 0 <repeats 13 times>}}, sa_flags = 5418867,
sa_restorer = 0xfffffffffffdfed8}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x000000000053a87c in ha_panic () at src/debug.c:164
No locals.
#3 0x000000000053aa78 in wdt_handler (sig=14, si=, arg=) at src/wdt.c:123
p = 3
thr = 5
#4
No locals.
#5 si_state_bit (state=) at include/proto/stream_interface.h:147
No locals.
#6 si_state_in (mask=, state=) at include/proto/stream_interface.h:154
No locals.
#7 process_stream (t=t@entry=0x7f44ca722b20, context=0x7f449e73fd70, state=) at src/stream.c:2418
s = 0x7f449e73fd70
sess =
rqf_last = 1300234240
rpf_last = 2147483648
rq_prod_last =
rq_cons_last =
rp_cons_last = 8
rp_prod_last = 3
req_ana_back =
req = 0x7f449e73fd80
res = 0x7f449e73fde0
si_f = 0x7f449e740018
si_b = 0x7f449e740070
#8 0x00000000005192b5 in process_runnable_tasks () at src/task.c:412
t = 0x7f44ca722b20
state =
ctx =
process =
lrq =
grq =
t =
max_processed = 6
#9 0x000000000048b407 in run_poll_loop () at src/haproxy.c:2513
next =
wake =
#10 run_thread_poll_loop (data=) at src/haproxy.c:2634
ptaf =
ptif =
ptdf =
ptff =
init_left = 0
init_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = ‘\000’ <repeats 39 times>, __align = 0}
init_cond = {__data = {__lock = 0, __futex = 18, __total_seq = 9, __wakeup_seq = 9, __woken_seq = 9, __mutex = 0xae5ea0 <init_mutex.42992>, __nwaiters = 0, __broadcast_seq = 5},
__size = “\000\000\000\000\022\000\000\000\t\000\000\000\000\000\000\000\t\000\000\000\000\000\000\000\t\000\000\000\000\000\000\000\240^\256\000\000\000\000\000\000\000\000\000\005\000\000”, __align = 77309411328}
#11 0x00007f44f4295dd5 in start_thread (arg=0x7f44d27b7700) at pthread_create.c:307
__res =
pd = 0x7f44d27b7700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139933565810432, -2451856451746657714, 0, 8392704, 0, 139933565810432, 2553793320893811278, 2553727761988323918}, mask_was_saved = 0}},
priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
pagesize_m1 =
sp =
freesize =
#12 0x00007f44f3db6ead in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

haproxy -vv output

HA-Proxy version 2.0.0 2019/06/16 - https://haproxy.org/
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-format-truncation -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered -Wno-missing-field-initializers -Wno-implicit-fallthrough -Wno-stringop-overflow -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
OPTIONS = USE_PCRE2_JIT=1 USE_PTHREAD_PSHARED=1 USE_STATIC_PCRE2=1 USE_LINUX_SPLICE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_TFO=1
Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT -PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD +PTHREAD_PSHARED -REGPARM -STATIC_PCRE +STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=8).
Built with OpenSSL version : OpenSSL 1.1.1c 28 May 2019
Running on OpenSSL version : OpenSSL 1.1.1c 28 May 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built with PCRE2 version : 10.33 2019-04-16
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
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 multiplexer protocols :
(protocols marked as cannot be specified using ‘proto’ keyword)
h2 : mode=HTX side=FE|BE mux=H2
h2 : mode=HTTP side=FE mux=H2
: mode=HTX side=FE|BE mux=H1
: mode=TCP|HTTP side=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace

Have no idea for what happened.

Posts: 1

Participants: 1

Read full topic

@pogingbagsik wrote:

Hello All,

I’m trying to achieve an asterisk monitoring via HAProxy.
The FOP2 has a url path XX.XX.XX.XX/fop2 and have a websocket of tcp 4445.

When I configure it with the code below.

acl front_growth hdr_beg(host) -i growth.XXX.com
use_backend backend_growth if front_growth

backend backend_acl
server front_acl XX.XX.XX.XX:80 check

I can reach the FOP via dns however it prompts me with error could not connect to port 4445.

BTW:
We have multiple backend termination of servers.

Is there anyway for me to achieve this?

Thanks,
Pogi

Posts: 1

Participants: 1

Read full topic

@Plutus9396 wrote:

Hello everyone,
I am a newbie for HAProxy, and tried to install 3 SMTP servers with postfix.
Finally, it seems that I got the correct result with telnet testing.
It replied like below when I used telnet on terminal

$ telnet x.x.x.1 25
Trying x.x.x.1…
Connected to x.x.x.1.
Escape chracter is ‘^]’
220 mail1.example.com ESMTP Postfix (Ubuntu)

$ telnet x.x.x.1 25
Trying x.x.x.1…
Connected to x.x.x.1.
Escape chracter is ‘^]’
220 mail2.example.com ESMTP Postfix (Ubuntu)

$ telnet x.x.x.1 25
Trying x.x.x.1…
Connected to x.x.x.1.
Escape chracter is ‘^]’
220 mail3.example.com ESMTP Postfix (Ubuntu)

By the way, my concern is how to send real email from my pc via HAProxy.
Any suggestion or help would be appreciated.
Regards,
Jason.

Posts: 2

Participants: 2

Read full topic

@jazzl0ver wrote:

Hi,

After deploying the new HAProxy version (the previous was 1.9.5), the access.log is flooding with messages like:
Jun 21 11:08:04 172.30.1.153:4594 [21/Jun/2019:11:08:04.294] lb-useast/lb-useast_frontend: SSL handshake failure
Jun 21 11:08:04 172.30.1.30:38852 [21/Jun/2019:11:08:04.410] lb-useast/lb-useast_frontend: SSL handshake failure
Jun 21 11:08:04 172.30.2.55:45926 [21/Jun/2019:11:08:04.670] lb-useast/lb-useast_frontend: SSL handshake failure
Jun 21 11:08:14 172.30.1.153:4602 [21/Jun/2019:11:08:14.295] lb-useast/lb-useast_frontend: SSL handshake failure
Jun 21 11:08:14 172.30.1.30:38950 [21/Jun/2019:11:08:14.409] lb-useast/lb-useast_frontend: SSL handshake failure
Jun 21 11:08:14 172.30.2.55:45982 [21/Jun/2019:11:08:14.670] lb-useast/lb-useast_frontend: SSL handshake failure

The HAProxy instances is located behind AWS Elastic Load Balancer (in classic mode). After a little investigation, I’ve come up that those errors are caused by AWS ELB TCP health checks.
tcpdump pcap is here https://www.dropbox.com/s/bwnadkmbkn6fgx6/elbhc.pcap?dl=0

Is there a way to hide such errors? Notice that version 1.9.5 does not show them.

Thanks in advance!

Posts: 1

Participants: 1

Read full topic

@VirtualFn wrote:

Hi,

after hours of searching and following sites like https://www.ssltrust.com.au/help/setup-guides/haproxy-reverse-proxy-setup-guide and https://discourse.haproxy.org/t/why-does-my-simplified-config-not-work-1-8-tcp-reverse-proxy-with-domain-name-checks/2448
i still can’t figure out, why haproxy won’t pass through https-requests:

My Setup:
domain1.com -------->:80, :443 1.2.3.4 ------> :81, :444 haproxy on pi1 --> :80, :443 pi1
else -------->:80, :443 1.2.3.4 ------> :81, :444 haproxy on pi1 --> :80, :443 pi2

so i have 2 domains, pointing to one ip, but should be handled by a separate raspberrypi, depending on the url.

pi1 is the target and the HAproxy host at the same time, which is why the apache webserver listens to ports 80 and 443, haproxy to 81 and 444.

The config of HAproxy:

global
        log /dev/log    local0 debug
        log /dev/log    local1 debug
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s


defaults
        log     global
        mode    tcp
        option  tcplog
        timeout connect 5000
        timeout client  50000
        timeout server  50000

backend pi2 _80
        mod http
        balance roundrobin
        server pi2  pi2 :80 check

backend pi2_443
        mode tcp
        balance roundrobin
        option ssl-hello-chk
        server pi2  pi2 :443 check

backend pi1_80
        mode http
        balance roundrobin
        server pi11 pi1:80

backend pi1_443
        mode tcp
        balance roundrobin
        option ssl-hello-chk
        server pi11 pi1:443 check

frontend http
 mode http
 bind :81
 use_backend pi2_80 if { hdr(host) -i domain2.com }
 default_backend pi1_80

frontend https
 mode tcp
 bind :444
 tcp-request inspect-delay 5s
 tcp-request content accept if { req_ssl_hello_type 1 }
 use_backend pi2_443 if { req_ssl_sni -i domain2.com }
 default_backend pi1_443

More info:

My modem redirects from port 80 to 81, if it forwards directly to one of the two apache2 servers, it works perfectly fine.

When using curl -vvkl pi1 and curl -vvkl pi2 the apacheserver redirects from port :80 to port :443 and works perfectly fine. So the problem defenitely is haproxy here, but i cant figure out why.

haproxy -c -f /etc/haproxy/haproxy.cfg shows Configuration file is valid

changing the hostnames to IPs does not make a difference

Thanks for the help

Posts: 1

Participants: 1

Read full topic

@jdyke wrote:

When using haproxy 1.8 and before in order to use h2, i simply checked the ssl_fc_alpn and then sent traffic to the correct server depending on if the client(browser) supported h2. Now with h2 available on the backend in 1.9 and 2.0, i thought i may be able to remove this check and clean up the configuration, but am clearly missing something.

– haproxy 1.8 –

frontend https
  mode tcp
  bind 0.0.0.0:443 ssl crt /etc/haproxy/certs alpn h2,http/1.1 ecdhe secp384r1
  timeout http-request 10s
  #send all HTTP/2 traffic to a specific backend
  use_backend http2-nodes if { ssl_fc_alpn -i h2 }
  #send HTTP/1.1 and HTTP/1.0 to default, which don't speak HTTP/2
  default_backend http1-nodes

backend http1-nodes
  mode http
  balance roundrobin
  default-server inter 1s fall 2 on-marked-down shutdown-sessions on-marked-up shutdown-backup-sessions

  server web01 10.X.X.12:80 check send-proxy
  server web02 10.X.X.14:80 check send-proxy

backend http2-nodes
  mode tcp
  balance roundrobin
  default-server inter 1s fall 2 on-marked-down shutdown-sessions on-marked-up shutdown-backup-sessions

  server web01 10.X.X.12:81 check send-proxy
  server web02 10.X.X.14:81 check send-proxy

Nginx is behind these servers and has http2 on port 81 and regular 1.1 on 80

In haproxy 1.9 and 2.0 i was thinking i could use one backend for haproxy and drop the 2nd port for Nginx. Something like the following:

frontend https
  mode http
  bind 0.0.0.0:443 ssl crt /etc/haproxy/certs alpn h2,http/1.1 ecdhe secp384r1
  option http-use-htx
  timeout http-request 10s
  default_backend http-nodes

backend http-nodes
  mode http
  option http-use-htx
  balance roundrobin
  default-server inter 1s fall 2 on-marked-down shutdown-sessions on-marked-up shutdown-backup-sessions

  server web01 10.X.X.12:80 send-proxy check alpn h2 #check-alpn http/1.1 send-proxy alpn h2,http1.1
  server web02 10.X.X.14:80 send-proxy check alpn h2 #check-alpn http/1.1 send-proxy alpn h2,http1.1

Then the nginx listen directive is simply
listen 80 http2 proxy_protocol

I’ve tried a number of things with the haproxy backends(alpn h2/http1.1 and proto h2) and am mainly running into 502’s from HAProxy and an error message in nginx stating:
recv() failed (104: Connection reset by peer) while processing HTTP/2 connection, client: 10.X.X.11, server: 0.0.0.0:80

Ultimately i think my question is simple: Can i use one backend for both h2 and http1.1, or should i still use the port routing based on ssl_fc_alpn. I’m trying to gain a better understanding of the new h2 backends and how option http-use-htx works.

One last bit. If i change to send-proxy check alpn h2 to send-proxy check proto h2, it seems to work well with h2 browsers and even when i curl --http1.1 -nvL -o /dev/null https://www.site.com it states that they request was in 1.1, but the nginx logs show its 2.0.

Hopefully this is clear, for older browsers, like IE10, it seems that i’m going to have to use the port redirect, but would love any further clarification.

Thank You,
Jeff

Posts: 1

Participants: 1

Read full topic

@newtreme wrote:

Can i run an HAProxy as ReverseProxy with diabled load balancer?

Posts: 1

Participants: 1

Read full topic

@KenynMacCormik wrote:

Hi, on my installation of HAproxy

[root@haproxy1 haproxy]# rpm -qa | grep haproxy
haproxy18u-1.8.19-1.ius.centos7.x86_64

the following ACLs are working

frontend web_frt
        acl     not_https       ssl_fc,not
        acl     is_ecp          path_beg        -m beg -i /ecp/
        acl     is_healthcheck  path_beg        -m end -i healthcheck.htm

        http-response   deny                            if is_ecp
        http-response   deny                            if is_healthcheck
        http-request    redirect scheme https code 301  if not_https

But on newer version

[root@LB1 haproxy]# rpm -qa | grep haproxy
haproxy18u-1.8.20-1.el7.ius.x86_64

I get an error

Jun 25 17:30:12 LB1 haproxy[18640]: [WARNING] 175/173012 (18640) : parsing [/etc/haproxy/haproxy.cfg:90] : acl 'is_ecp' will never match because it only involves keywords that are incompatible with 'frontend http-response header rule'
Jun 25 17:30:12 LB1 haproxy[18640]: [WARNING] 175/173012 (18640) : parsing [/etc/haproxy/haproxy.cfg:91] : acl 'is_healthcheck' will never match because it only involves keywords that are incompatible with 'frontend http-response header rule'

Any idea why this is happening?

Posts: 1

Participants: 1

Read full topic

@shamsimam wrote:

We are noticing haproxy sometimes converts responses with content-length headers to responses with chunked transfer-encoding and no content length headers. Is it possible to disable this behavior and always have haproxy respect the backend response headers?

Example: request to backend directly

$ curl http://localhost:8080/content.js
...
< HTTP/1.1 200 OK
< Content-Type: application/javascript
< Content-Length: 1234567
...

Example: request to via haproxy (note content-length header is dropped and transfer-encoding is introduced)

$ curl http://localhost:9090/some.js
...
< HTTP/1.1 200 OK
< content-type: application/javascript
< transfer-encoding: chunked
...

Our tuning parameters in haproxy.cfg:

tune.maxrewrite 32768
tune.bufsize 65536

Posts: 1

Participants: 1

Read full topic

@fkarakas wrote:

Hi,

We want to try to load balance grpc request with haproxy (evaluating many other solutions).

We have a headless service used as a grpc backend in haproxy in a kubernetes cluster.
Haproxy doesn’t seem to load balance on all ips, just the first ip is used.

Anynone having this issue ?

Latest version of haproxy is used.

regards

Posts: 2

Participants: 2

Read full topic

@yas19 wrote:

Can not use command line for load balancing configuration?
I tried to use HAProxy as LB, but I couldn’t find a command line for LB.

Posts: 1

Participants: 1

Read full topic

@newbie91 wrote:

hi, I newbie in haproxy, I already install and configure haproxy for load balance on centos7, I have 2 backend server with diferent subnet IP. is this work in different subnets? haproxy canot start and show error mesage “backend app has no server available!”

1. Load balancer server = 192.168.12.100 <== HAproxy I want install in this server
2. Bacnkend server = 192.168.10.100
3. Backend server2 = 192.168.11.100

haproxy.cfg

frontend app_servers *:80
default_backend apps

frontend main
bind *:5000
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js

use_backend static          if url_static
default_backend             web-servers

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

static backend for serving up images, stylesheets and such

#---------------------------------------------------------------------
backend static
balance roundrobin
server static 127.0.0.1:4331 check

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

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

backend web-servers
server servera server1.local:80 check
server serverb server2.local:80 check

Posts: 1

Participants: 1

Read full topic

@romor wrote:

Hi,

i installed HAProxy 2.0 (i also tested it on 2.0.1) and i added text alpn h2,http/1.1 to SSL frontend.
But when i activate onfiguration with alpn, i can’t display websites (browser always waiting for web) in some browsers (i did test with Firefox and Chrome). In another browser is all working (IE and Edge).
I tried also clear config only with one frontend and backend, but with same result.
In log isn’t any record about access, when i use Firefox or Chrome.
When i use IE or Edge, i see all HTTP/2 requests.
I tried it on two sepparate servers with same result.

Do you know, what is bad, when it doesn’t work with clear config too?

Thanks

Posts: 1

Participants: 1

Read full topic

@koleo wrote:

I am using HAProxy (Community Edition) for a Redis Server access (High Availability for a master-slave Redis setup).
It runs on a Debian Stretch (9.9) LXC container installed from the apt repository haproxy.debian.net.

After upgrading from HAProxy 1.9.8-1~bpo9+1 to 2.0.1-1~bpo9+1, I noticed a server connection issue: Server connections on Redis grew up from about 50 connections to 4000, making Redis Server unavailable under peak periods.

After downgrading to 1.9.8-1~bpo9+1, everything was back to its original state (server connections came back to around 50).

Usually, the number of client connections is around 50, but can reach 500 under certain circumstances.

Is there a change between 1.9.x and 2.0.x that could explain this problem?

Here is my HAProxy configuration file (same conf used for v1.9.8 and 2.0.1):

global
        log /dev/log local0
        log /dev/log local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon
        maxconn 32000

defaults
        log global
        mode http
        option httplog
        option dontlognull
        option dontlog-normal
        timeout connect 5000
        timeout client  50000
        timeout server  50000

frontend redis_master
    bind 10.2.1.100:6379,10.2.1.101:6379
    option tcplog
    mode tcp
    timeout client 10s
    default_backend redis_master

backend redis_master
    mode tcp
    balance first
    timeout connect 4s
    timeout server 10s
    option tcp-check
    default-server rise 1 on-marked-down shutdown-sessions
    server 10.2.1.3 10.2.1.3:6379 check #disabled
    server 10.2.1.4 10.2.1.4:6379 check disabled

Posts: 3

Participants: 2

Read full topic

@jazzl0ver wrote:

Hi,

While researching an issue, I’ve found out doubling tcp resets:

# tcpdump -nn "host 172.30.2.194 and port 3443" | grep "[R]"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:53:27.454475 IP 172.30.2.194.3443 > 172.30.1.30.10434: Flags [R], seq 4150895860, win 0, length 0
16:53:27.454628 IP 172.30.2.194.3443 > 172.30.1.30.10434: Flags [R], seq 4150895860, win 0, length 0
16:53:28.540711 IP 172.30.2.194.3443 > 172.30.1.30.10578: Flags [R], seq 4211144735, win 0, length 0
16:53:28.540730 IP 172.30.2.194.3443 > 172.30.1.30.10578: Flags [R], seq 4211144735, win 0, length 0
16:53:30.741290 IP 172.30.2.194.3443 > 172.30.2.55.34986: Flags [R], seq 4066360692, win 0, length 0
16:53:30.741376 IP 172.30.2.194.3443 > 172.30.2.55.34986: Flags [R], seq 4066360692, win 0, length 0
16:53:36.051007 IP 172.30.2.194.3443 > 172.30.1.30.8370: Flags [R], seq 3608015152, win 0, length 0
16:53:36.051020 IP 172.30.2.194.3443 > 172.30.1.30.8370: Flags [R], seq 3608015152, win 0, length 0
16:53:45.898741 IP 172.30.2.194.3443 > 172.30.2.55.35228: Flags [R], seq 3409875850, win 0, length 0
16:53:45.898780 IP 172.30.2.194.3443 > 172.30.2.55.35228: Flags [R], seq 3409875850, win 0, length 0
16:53:46.603130 IP 172.30.2.194.3443 > 172.30.2.55.34398: Flags [R], seq 1417708259, win 0, length 0
16:53:46.603242 IP 172.30.2.194.3443 > 172.30.2.55.34398: Flags [R], seq 1417708259, win 0, length 0

Can anyone explain them?

PS HAProxy v.1.9.5 running under Amazon Linux on AWS EC2 instance
PPS There’re two EC2 instances and both of them send tcp reset twice.

Posts: 1

Participants: 1

Read full topic

@Thoufiq wrote:

We lose the HAProxy stats in every restart but we want the stats to be available till we flush it… Is it possible? Is there any setting available in HAProxy to keep the stats persistent.

Posts: 1

Participants: 1

Read full topic