@hans0r wrote:

Hi all,

I have some problem with the cache functions. cached is filled I checked it over socat but there is no reference count and the cache is not used. I use haproxy 1.8.3

0x7fade115f42c hash:794218 size:760 (1 blocks), refcount:0, expire:3183
0x7fade10cc90c hash:996187 size:2367 (3 blocks), refcount:0, expire:3182
0x7fade10d512c hash:20539863 size:1702 (2 blocks), refcount:0, expire:3182

The response header from the backend-server contain the following headers.
Cache-Control:max-age=563395, must-revalidate
Content-Length:823
Content-Type:image/png
Etag:“20170530182128”

Is any of this headers block haproxy to deliver from cache?

the backend looks like that

backend events_BE_static
mode http
timeout server 300s
timeout connect 2s
timeout http-keep-alive 1s
option http-server-close

    timeout check 2s

    balance roundrobin

    http-request cache-use events
    http-response cache-store events

    no option redispatch
    server s1-104-8080 xxx:8080 check weight 100 maxconn 75
    server s2-104-8081 xxx:8081 check weight 100 maxconn 75
    server s3-102-8081 xxx:8081 check maxconn 75 backup inter 1s fall 3

cache events
total-max-size 200
max-age 3600

Thanks for your help.

cheers hans0r

Posts: 1

Participants: 1

Read full topic

@scarey wrote:

Hi,

It looks like HAProxy 1.8.3 doesn’t obey the number of SRV records and instead just uses the server-template num servers.

For the following 3 SRV records:

;; ANSWER SECTION:
_app._tcp.marathon.mesos. 15 IN SRV 10 0 11016 host3.marathon.mesos.
_app._tcp.marathon.mesos. 15 IN SRV 10 0 24353 host1.marathon.mesos.
_app._tcp.marathon.mesos. 15 IN SRV 10 0 11751 host5.marathon.mesos.

And the following HAProxy config:

server-template www 5 _app._tcp.marathon.mesos check resolvers mydns resolve-prefer ipv4

It initialized 5 servers, 3 from the DNS records but also 2 others:

[WARNING] 037/130543 (7409) : Server nodes/www1 is DOWN, reason: Socket error, check duration: 0ms. 4 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 037/130543 (7409) : nodes/www1 changed its IP from to 192.168.0.163 by mydns/dns1.
[WARNING] 037/130543 (7409) : nodes/www2 changed its IP from to 192.168.0.165 by mydns/dns1.
[WARNING] 037/130543 (7409) : nodes/www3 changed its IP from to 192.168.0.207 by mydns/dns1.
[WARNING] 037/130543 (7409) : Server nodes/www2 is DOWN, reason: Layer4 connection problem, info: “Connection refused”, check duration: 50ms. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 037/130544 (7409) : Server nodes/www3 is DOWN, reason: Layer4 connection problem, info: “Connection refused”, check duration: 49ms. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 037/130544 (7409) : Server nodes/www4 is DOWN, reason: Socket error, check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 037/130545 (7409) : Server nodes/www5 is DOWN, reason: Socket error, check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

I think the expected behavior would be to configure only 3 servers? Please let me know if you need more information.

Thanks,
scarey

Posts: 1

Participants: 1

Read full topic

@Ismael wrote:

Hello Sirs,
I have set up proxy ha to balance my websense gateway proxy, however, haproxy is not redirecting authentication, ie haproxy is not categorizing, without suggestion?

Posts: 1

Participants: 1

Read full topic

@eva2000 wrote:

Hi I just installed Haproxy 1.8.3 via source compile to compare against Nginx 1.13.8 also source compiled in proxy config with and without caching.

I setup HTTP/2 HTTPS to see how they fair for nghttp2’s h2load HTTP/2 HTTPS load tester and noticed differences in header compression ratio and compression size of requests. What settings control Haproxy’s HTTP/2 compression ?

System is CentOS 7.4 64bit based with haproxy enabled multithreading with 6 threads on Xeon E3-1270v6 4C/8T server Vultr Baremetal with 10Gbps network. With 2x Vultr baremetal Xeon E3-1270v5 64GB ram Nginx backends. Full tests at https://community.centminmod.com/posts/59266/

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     = native
  CC      = gcc
  CFLAGS  = -march=native -m64 -march=x86-64 -O2 -g
  OPTIONS = USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_THREAD=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1

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

Built with OpenSSL version : OpenSSL 1.1.0g  2 Nov 2017
Running on OpenSSL version : OpenSSL 1.1.0g  2 Nov 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.4
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.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : yes
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

Haproxy 1.8.3 HTTP/2 h2load test 7x runs

Haproxy 1.8.3 HTTP/2 h2load stress test
4192.64 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492141) total, 20.44MB (21434340) headers (space savings 8.92%), 80.73MB (84650000) data
43055.35 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492162) total, 20.44MB (21434379) headers (space savings 8.92%), 80.73MB (84650000) data
43342.96 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492323) total, 20.44MB (21434369) headers (space savings 8.92%), 80.73MB (84650000) data
4225.61 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492273) total, 20.44MB (21434355) headers (space savings 8.92%), 80.73MB (84650000) data
4462.79 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492048) total, 20.44MB (21434355) headers (space savings 8.92%), 80.73MB (84650000) data
4238.36 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107492414) total, 20.44MB (21434388) headers (space savings 8.92%), 80.73MB (84650000) data
4452.79 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 102.51MB (107491991) total, 20.44MB (21434379) headers (space savings 8.92%), 80.73MB (84650000) data

Centmin Mod Nginx 1.13.8 HTTP/2 h2load test 7 runs with proxy_cache

with proxy_cache CentminMod.com Nginx 1.13.8 HTTP/2 h2load stress test
41114.53 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.02MB (103825021) total, 17.41MB (18250521) headers (space savings 22.34%), 80.73MB (84650000) data
41366.07 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.17MB (103985124) total, 17.56MB (18410624) headers (space savings 22.32%), 80.73MB (84650000) data
44522.57 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.15MB (103970551) total, 17.54MB (18396051) headers (space savings 22.32%), 80.73MB (84650000) data
43232.74 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.12MB (103938667) total, 17.51MB (18364167) headers (space savings 22.32%), 80.73MB (84650000) data
42330.59 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103973060) total, 17.55MB (18398560) headers (space savings 22.32%), 80.73MB (84650000) data
44525.14 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.18MB (103998511) total, 17.57MB (18424011) headers (space savings 22.32%), 80.73MB (84650000) data
42880.43 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.13MB (103949287) total, 17.52MB (18374787) headers (space savings 22.32%), 80.73MB (84650000) data

Centmin Mod Nginx 1.13.8 HTTP/2 h2load test 7 runs without proxy_cache

no proxy_cache CentminMod.com Nginx 1.13.8 HTTP/2 h2load stress test
3255.46 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3270.14 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3206.48 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3256.87 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3236.25 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3304.80 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data
3270.14 req/s 100% completed  status codes: 50000 2xx, 0 3xx, 0 4xx, 0 5xx  traffic: 99.16MB (103975000) total, 17.55MB (18400500) headers (space savings 22.20%), 80.73MB (84650000) data

h2load header space savings differences for Haproxy = 8.92% vs Nginx = 22+%

Posts: 3

Participants: 2

Read full topic

@Multihomed wrote:

I’m running haproxy 1.5.18-6.el7 plus openssl 1.0.2k, and some clients are getting random SSL handshake errors. Looking at the network level, almost all of them fails with this message: Bad Record MAC.

The only information related to haproxy and openssl that I could find is this thread:

https://www.mail-archive.com/haproxy@formilux.org/msg26496.html

I had double checked that the openssl version I’m running has the fix but the failures still happen. So I’m in a dead end here, can someone help me?

2018-02-07 14_13_46-2018-05-2.pcap.png1105x215 28.5 KB

Posts: 1

Participants: 1

Read full topic

@jkim711 wrote:

Hi

I am using Root CA generated SSL certificate to setup a SSL connection for HAProxy which connects to a web server that only support http. When the browser connects there is a invalid certificate error but if the user proceeds despite the warning, the browser connects with an insecure connection. Is there a way to know if the browsers is using an insecure connection because the browser rejected to use the invalid certificate? I have read posts saying the latest browsers are more strict about certificate . How can we check if haproxy/browser SSL exchange was successful?
The haproxy setup could be the culprit too.
I will attach the log in the following reply

Thanks Jae Kim

Posts: 1

Participants: 1

Read full topic

@vikas wrote:

We occasionally use haproxy to return a static API response (using the errorfile directive).
However, we’ve noticed that when we do so, haproxy closes the connection (instead of respecting the Connection: Keep-Alive header).

Is there any way to get haproxy to keep the connection alive, instead of closing it right away?

I’ve tried various permuations of setting option http-keep-alive, option httpclose, forcepersist, to no avail. We use haproxy 1.8.

Here’s the backend configuration:

### backend for blackholing heartbeats
backend mybackend
  mode http
  errorfile 503 /srv/www/response.http

Here are the contents of the errorfile:

HTTP/1.1 200 Ok
Content-Type: application/json; charset=utf-8
Connection: Keep-Alive
Content-Length: 17

{"success":false}

Posts: 1

Participants: 1

Read full topic

@dyadaval wrote:

Hi All,

I have one question related to same with haproxy 1.8.3 version
Can I do ACL at front end or backend check if its http2, send to grpc backend, else forward to nginx??

Configuration

frontend https-in

HTTP/2 - see https://www.haproxy.com/blog/whats-new-haproxy-1-8/

h2 is HTTP2 with TLS - see https://http2.github.io/faq/

Order matters, so h2 before http1.1

mode http
bind *:443 ssl ca-file /f0/base/haproxy/ca.pem  crt /f0/base/haproxy/server.pem alpn h2,http/1.1
#option httpclose
#option forwardfor
use_backend nodes-http2 if { ssl_fc_alpn -i h2 }
default_backend nodes-http

backend nodes-http
mode http
http-response set-header Strict-Transport-Security "max-age=16000000; includeSubDomains; preload;"
http-request add-header X-Forwarded-Proto https
server node1 0.0.0.0:4443 check send-proxy

#This way browsers which do support HTTP/2 are still able to connect to our website
backend nodes-http2
mode http
# HSTS (15768000 seconds = 6 months)
http-request add-header X-Forwarded-Proto https
http-response set-header Strict-Transport-Security max-age=15768000

# path: /helloworld.Greeter/SayHello
# path: /package.servicename/methodname
#use-server grpcServer if { req.hdr(Content-Type) -i application/grpc }
#use-server grpcServer if { path_beg -i /gnmi }
use-server grpcServer if { url_sub  -i <grpc> }
#use-server grpcServer if { path_sub grpcserver }
server grpcServer localhost:6666 weight 0
# all the rest is forwarded to this server
server default localhost:4443 check

haproxy -f /f0/base/haproxy/haproxy.grpc.cfg -d
Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result FAILED
Total: 2 (1 usable), will use poll.

Available filters :
[TRACE] trace
[COMP] compression
[SPOE] spoe
Using poll() as the polling mechanism.
00000000:https-in.accept(0003)=0004 from [192.168.1.1:48291] ALPN=h2
00000000:https-in.clireq[0004:ffffffff]: POST /gnmi.gNMI/Capabilities HTTP/1.1
00000000:https-in.clihdr[0004:ffffffff]: password: PA$$WORD
00000000:https-in.clihdr[0004:ffffffff]: routerid:
00000000:https-in.clihdr[0004:ffffffff]: username: TestUser
00000000:https-in.clihdr[0004:ffffffff]: grpc-encoding: identity
00000000:https-in.clihdr[0004:ffffffff]: grpc-accept-encoding: identity,deflate,gzip
00000000:https-in.clihdr[0004:ffffffff]: te: trailers
00000000:https-in.clihdr[0004:ffffffff]: content-type: application/grpc
00000000:https-in.clihdr[0004:ffffffff]: user-agent: grpc-c++/1.1.0-dev grpc-c/2.0.0-dev (linux; chttp2; good)
00000000:https-in.clihdr[0004:ffffffff]: host: localhost
00000000:nodes-http2.srvcls[0004:adfd]
00000000:nodes-http2.clicls[0004:adfd]
00000000:nodes-http2.closed[0004:adfd]
00000001:https-in.accept(0003)=0004 from [192.168.1.1:48293] ALPN=h2
00000001:https-in.clireq[0004:ffffffff]: POST /gnmi.gNMI/Subscribe HTTP/1.1
00000001:https-in.clihdr[0004:ffffffff]: filter: FAN
00000001:https-in.clihdr[0004:ffffffff]: password: PA$$WORD
00000001:https-in.clihdr[0004:ffffffff]: routerid:
00000001:https-in.clihdr[0004:ffffffff]: username: TestUser
00000001:https-in.clihdr[0004:ffffffff]: grpc-encoding: identity
00000001:https-in.clihdr[0004:ffffffff]: grpc-accept-encoding: identity,deflate,gzip
00000001:https-in.clihdr[0004:ffffffff]: te: trailers
00000001:https-in.clihdr[0004:ffffffff]: content-type: application/grpc
00000001:https-in.clihdr[0004:ffffffff]: user-agent: grpc-c++/1.1.0-dev grpc-c/2.0.0-dev (linux; chttp2; good)
00000001:https-in.clihdr[0004:ffffffff]: grpc-timeout: 24H
00000001:https-in.clihdr[0004:ffffffff]: host: localhost
00000001:nodes-http2.srvcls[0004:adfd]
00000001:nodes-http2.clicls[0004:adfd]
00000001:nodes-http2.closed[0004:adfd]

netstat -an | grep -i 6666
tcp 0 0 ::ffff:127.0.0.1:6666 :::* LISTEN
tcp 0 0 ::ffff:127.0.0.1:6666 ::ffff:127.0.0.1:33635 TIME_WAIT

Can you please give me pointers on how to fix this?
Thanks,

Posts: 1

Participants: 1

Read full topic

@proxyuser wrote:

Hi,

I am currently using some squid forwarding proxies to provide internet access to a number of desktops in a locked down vlan.

A new application is being deployed that will send a lot of requests to an external api.
My squid proxies are currently configured to perform user authentication.
What I would like to do is to intercept requests from certain ip’s going to certain urls and send them directly to the endpoint, bypassing the squid proxies.

simliar to:
frontend proxyin
bind *:8081
mode http
use_backend apihttp if { base_dom -i example.com }

default_backend proxyout

backend proxyout
mode http
server proxyout1 XX.XX.XX.XX:3128 maxconn 100 weight 10 check

backend apihttp
mode http
server apiserver1 XX.XX.XX.XX:443 check ssl verify none

The problem is that as the platforms are setup to talk via Proxy, the requests going to the api server are CONNECT requests that the oldish api platform doesn’t understand.

Is there any way to get HAProxy to replicate proxy functionality for these requests?

Thanks

Posts: 1

Participants: 1

Read full topic

@jose wrote:

Hi there!!

I’m new here and also in the HA world, in version 1.4 on the left of the web view of backends we had a check in order to disable them for maintenance…how can i get this on version 1.7?

Thks!!!

Posts: 1

Participants: 1

Read full topic

@dpupov wrote:

Hi I have ACL for block access for some sources

acl custom_deny    src -f /etc/haproxy/geo/custom_deny.subnets
tcp-request content reject if  custom_deny

ands question are ,

1. how many lines can contain file custom_deny.subnets , or total size?
2. how do it influent to performance

–thanks

Posts: 1

Participants: 1

Read full topic

@satya wrote:

Hi,

I am trying to simple route all the HTTP requests made to the server to redirect as HTTPS to external server.

Can you please help with the it?

Code:
frontend localhost
bind :80
option tcplog
mode tcp
default_backend nodes

backend nodes
mode tcp
option ssl-hello-chk
server sv1 10.192.x.x:443

Also I am trying to use curl (below command) and it should redirect to https://v1/health to fetch the data.
The https url works without any issue, so there is no connectivity issue from the machine. But the localhost url
doesn’t work.

curl -X GET http://localhost/health
curl: (52) Empty reply from server

curl -X GET https://sv1/health
{“status”:“UP”,“diskSpace”:{“status”:“UP”,“total”:1073741824,“free”:913141760,“threshold”:10485760}}

Posts: 1

Participants: 1

Read full topic

@mr.proxy wrote:

Hello, I have a question.

I use HAProxy to redirect incomming traffic on post 80, 443 and 8000 and use a lot of different virtual hosts.

All incomming traffic on 443 is decrypted and forwared on port 80 to the web-servers on a closed network (using private IP addresses). Port 8000 is forwarded as is to the same internal web-servers. The web-servers have docker containers forwarding port 8000 to 443 inside the docker container.

I want to get rid of the port 8000 by replacing it by a new virtual host , lets call it foobar.mydomain.com. So in stead of calling existing-virtual-host.mydomain.com:8000 using SSL, the client will call foobar.mydomain.com

Can HAProxy be configured to handle traffic to foobar.mydomain.com (on 443) by forwarding it directly to the internal web-servers on port 8000?

Posts: 1

Participants: 1

Read full topic

@dyadaval wrote:

Hi,

I am trying to convert my nginx configuraiton to haproxy:
nginx configuration:
location / {
proxy_pass http://[::1]:8088;
}

frontend fe_http
mode http
bind *:80
option forwardfor

Redirect to https

redirect scheme https code 301 if ! { ssl_fc }

default_backend nodes-http-80

backend nodes-http-80
mode http
server default [::1]:8088

8088 is what webserver listneing to.
I am getting like error as below:
00000000:fe_http.accept(0006)=0007 from [:20842]
00000000:fe_http.clireq[0007:ffffffff]: GET / HTTP/1.1
00000000:fe_http.clihdr[0007:ffffffff]: Host:
00000000:fe_http.clihdr[0007:ffffffff]: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
00000000:fe_http.clihdr[0007:ffffffff]: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
00000000:fe_http.clihdr[0007:ffffffff]: Accept-Language: en-US,en;q=0.5
00000000:fe_http.clihdr[0007:ffffffff]: Accept-Encoding: gzip, deflate
00000000:fe_http.clihdr[0007:ffffffff]: Connection: keep-alive
00000000:fe_http.clihdr[0007:ffffffff]: Upgrade-Insecure-Requests: 1
00000000:nodes-http-80.srvrep[0007:0008]: HTTP/1.1 404 Not Found
00000000:nodes-http-80.srvhdr[0007:0008]: Connection: close
00000000:nodes-http-80.srvhdr[0007:0008]: Server:
00000000:nodes-http-80.srvhdr[0007:0008]: Date: Mon, 12 Feb 2018 14:05:17 GMT
00000000:nodes-http-80.srvhdr[0007:0008]: Content-Length: 169
00000000:nodes-http-80.srvhdr[0007:0008]: Content-Type: text/html
00000000:nodes-http-80.srvhdr[0007:0008]: Content-Encoding: gzip
00000000:nodes-http-80.srvhdr[0007:0008]: Vary: Accept-Encoding
00000000:nodes-http-80.srvcls[0007:0008]
00000001:fe_http.clireq[0007:ffffffff]: GET /favicon.ico HTTP/1.1
00000001:fe_http.clihdr[0007:ffffffff]: Host: 172.18.138.3
00000001:fe_http.clihdr[0007:ffffffff]: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
00000001:fe_http.clihdr[0007:ffffffff]: Accept: /
00000001:fe_http.clihdr[0007:ffffffff]: Accept-Language: en-US,en;q=0.5
00000001:fe_http.clihdr[0007:ffffffff]: Accept-Encoding: gzip, deflate
00000001:fe_http.clihdr[0007:ffffffff]: Connection: keep-alive
00000001:nodes-http-80.srvcls[0007:0008]
00000001:nodes-http-80.clicls[0007:0008]
00000001:nodes-http-80.closed[0007:0008]
00000002:fe_http.accept(0006)=0007 from [10.220.22.107:20844]
00000002:fe_http.clireq[0007:ffffffff]: GET /favicon.ico HTTP/1.1
00000002:fe_http.clihdr[0007:ffffffff]: Host:
00000002:fe_http.clihdr[0007:ffffffff]: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
00000002:fe_http.clihdr[0007:ffffffff]: Accept: /
00000002:fe_http.clihdr[0007:ffffffff]: Accept-Language: en-US,en;q=0.5
00000002:fe_http.clihdr[0007:ffffffff]: Accept-Encoding: gzip, deflate
00000002:fe_http.clihdr[0007:ffffffff]: Connection: keep-alive
00000002:nodes-http-80.srvrep[0007:0008]: HTTP/1.1 404 Site or Page Not Found
00000002:nodes-http-80.srvhdr[0007:0008]: Server: GoAhead-Webs
00000002:nodes-http-80.srvhdr[0007:0008]: Date: Mon Feb 12 14:05:17 2018
00000002:nodes-http-80.srvhdr[0007:0008]: Pragma: no-cache
00000002:nodes-http-80.srvhdr[0007:0008]: Cache-Control: no-cache
00000002:nodes-http-80.srvhdr[0007:0008]: Content-Type: text/html

Thanks

Posts: 1

Participants: 1

Read full topic

@the_glu wrote:

Hello,

I have a strange errors occurring only on one specific HTTP endpoint and only with some backends.

I have a Haproxy in front of 4 nginx in front of one python application. Two nginx backends are using https (and are in docker containers, but that should not be relevent ^^) and other two are using http (and not in docker containers).

Configuration :

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

# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private

ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
log global
mode http
option httplog
option dontlognull
option dontlog-normal
option http-ignore-probes
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

backend pc-backend
balance roundrobin

server -1 185.:5000 check ssl verify none weight 25
server -2 34.:5000 check ssl verify none weight 25
server -3 34.:80 check weight 25
server -4 54.:80 check weight 25

frontend http
bind *:80
mode http
option forwardfor
default_backend pc-backend

frontend https
bind *:443 ssl crt /etc/apache2/ssl/.key.pem
mode http
option forwardfor

default_backend pc-backend

listen stats
bind *:8999 ssl crt /etc/apache2/ssl/.key.pem
mode http
stats enable
stats realm Haproxy\ Statistics
stats uri /haproxy_stats

Some specific queries (on /v2/batch) are sometime (not always) failing with the following logs, only on server -1 and -2 (with https). (Image #1)

On nginx side, requests are fine and there are no errors. (Image #2)

I didn’t manage to reproduce those queries (it’s in production and there is too many queries / seconds), but I was able to capture a working and failing transaction on the haproxy machine and on the backend:

I put all images here since I’m limited as a new user: https://imgur.com/a/JyQsi

The only difference seems to be the [FIN, ACK] packet from the backend arriving after (working) or before (error) the [RST, ACK] sent from HAProxy, on HAProxy side.

I don’t really understand why queries are failling, this is the only difference I see. Do someone have any idea ?

Thanks!

Posts: 1

Participants: 1

Read full topic

@flygirl wrote:

Hi,

Is there any a way to disable https (443) in haproxy.cfg?
and Just allow http connection? (backend only)

Thanks!

Posts: 4

Participants: 2

Read full topic

@Shankar wrote:

I was using haproxy for load balancing my backend servers. I am on
HA-Proxy version 1.5.2 2014/07/12.
The problem is that after changing my haproxy.cfg configuration and reloading and restarting my haproxy service i can see that i am getting a “503 service not available”. Now when i look at my haproxy logs, I can see that some of the requests are still being redirected to a backend configuration which was removed long time back , I do not have “DSIS_DATA” in my configuration (haproxy.cfg ) as of now . I had done reload and restart of my haproxy service. Why are my requests still being directed to the old backend

Logs

Feb 13 11:14:18 localhost haproxy[19407]: 34.36.74.147:60290 [13/Feb/2018:11:14:18.394] HTTP_PROXY~ DSIS_DATA/ 3/-1/-1/-1/3 503 212 - - SCNN 2/1/0/0/0 0/0 “GET /dsdataserver-console/faces/security.jsf HTTP/1.1"
”

Posts: 3

Participants: 2

Read full topic

@bshi wrote:

(using HAproxy 1.8.3)

I’m attempting to use the DNS resolver to load balance traffic to Kubernetes pods. It works well for around 100 backends. When we bump the backends to ~150, HAproxy starts thrashing backend UP/DOWN messages.

Is this related to DNS limitations? What happens when the SRV records don’t fit in 8192 bytes?

Per https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.3.2-accepted_payload_size

Defines the maximum payload size accepted by HAProxy and announced to all the
name servers configured in this resolvers section.
<nb> is in bytes. If not set, HAProxy announces 512. (minimal value defined
     by RFC 6891)

Note: to get bigger responses but still be sure that responses won't be
  dropped on the wire, one can choose a value between 1280 and 1410.

Note: the maximum allowed value is 8192.

Posts: 1

Participants: 1

Read full topic

@rruiz wrote:

Hi,

I have some graphs haproxy values ​​and the stot is one of them. This value in the haproxy guide (https://cbonte.github.io/haproxy-dconv/1.6/management.html) is:

7. stot [LFBS]: cumulative number of connections

When it plots this value shows something like this:

image.png1111x295 53.5 KB

Values in average increase but produces decreases sometimes in this value.

I see the same behavior when I try to collect, each second, this value directly from socket:

echo ‘show info;show stat;show table’ | socat stdio unix-connect:/run/haproxy.sock …
[…]
11998
10606
10607
11998
2270
10609
11998
10609
2271
11998
11999
11999
2271
2271
11999
10612
2271
10612
[…]

I don’t understand this behavior, may be haproxy configuration? I think that the normal behavior should be only increase with time, isn’t?

if it necessary i can send the configuration or any information that would be required to understand this behavior.

Thanks!

Posts: 2

Participants: 2

Read full topic

@jvwag wrote:

Hi,

I have read the PROXY protocol specification and I expected a check from HAproxy to a backend server to have the command set to LOCAL.

In my setup of HAproxy (tested 1.6 and 1.8, mode TCP) this does not seem to be the case. I wanted to use it to determine the difference between a health check and a proxy connection.

I’m receiving PROXY protocol frames with the command set to PROXY and the the src and dst address/port set to the expected values of the proxy server and the backend server respectively.

Back-tracking the source code I saw there is a case in make_proxy_line_v2 where the remote flag is not set, the frame would be constructed as a LOCAL command.

Is sending a PROXY command correct behavior when doing a health check? Should I test and compare this with a HTTP proxy setup (because maybe this is only flawed in TCP mode)?

With kind regards,
Joffrey

Posts: 1

Participants: 1

Read full topic