Quantcast
Channel: HAProxy community - Latest topics
Viewing all articles
Browse latest Browse all 4731

Haproxy replies with TCP FIN on HTTP GET

$
0
0

Hello,

I am happily using haproxy 2.0.17 (also happens with 2.0.19) with quite such configuration:

global
  pidfile haproxy.pid
  master-worker

log log.sck local0
defaults
  log global
  mode http
  option httplog
  timeout queue 60s
  timeout server 600s
  timeout client 600s
  timeout connect 5s
  retries 3

frontend http-backend
  bind <ip>:41080

  acl is_<N> hdr_reg(host) -i ^<N>.example.com($|:.*)
  use_backend <N>-http if is_<N>

backend <N>-http
  timeout server 600s
  timeout connect 5s
  retries 3
  server backend ip:v6:port ssl verify none

Where I have N about 3000 configurations.

It works pretty well ~99,995% of time, but sometimes haproxy replies with TCP FIN to proper HTTP GET from a client on a long lasting connection, on which before it responded a lot with proper reply, see:

This requires the client to reconnect (and for now this is how I workarounded it on client side, by retrying connection when lost).

In the log file for this source port I only find quite correct entries, and none related to the problem I have:

10.0.251.170:42742 [07/Jan/2021:13:02:00.837] haproxy A-http/backend 0/0/222/57/279 304 154 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"
10.0.251.170:42742 [07/Jan/2021:13:02:02.565] haproxy B-http/backend 0/0/3/378/381 200 5044 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"
10.0.251.170:42742 [07/Jan/2021:13:02:03.984] haproxy C-http/backend 0/0/218/168/386 304 154 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"
10.0.251.170:42742 [07/Jan/2021:13:02:05.927] haproxy D-http/backend 0/0/350/56/406 304 154 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"
10.0.251.170:42742 [07/Jan/2021:13:02:07.229] haproxy E-http/backend 0/0/217/55/272 304 154 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"
10.0.251.170:42742 [07/Jan/2021:13:02:10.614] haproxy F-http/backend 0/0/100/78/178 304 96 - - ---- 29/3/0/0/0 0/0 "GET /REDACTED/ HTTP/1.1"

So, is it possible that source of this TCP FIN is not haproxy itself? Or shall I look in some other place?

If needed I can try to reproduce this problem with any given version or additional debugging configuration.

Regards,
Łukasz

1 post - 1 participant

Read full topic


Viewing all articles
Browse latest Browse all 4731

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>