# Haproxy replies with TCP FIN on HTTP GET

**URL:** <https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150>\
**Category:** Help!\
**Created:** [January 19, 2021, 1:15pm UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150 "2021-01-19T13:15:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![luke](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@luke](https://discourse.haproxy.org/u/luke)\
**Post date:** [January 19, 2021, 1:15pm UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/1 "2021-01-19T13:15:59Z")

</div>

Hello,

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

```auto
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:

 ![shark-ts-ha](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/2X/c/c9953357667620f86e75008bdbcfa46fc5be1b7f.png)

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:

```nohighlight
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

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [January 20, 2021, 10:12pm UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/2 "2021-01-20T22:12:42Z")

</div>

> [@luke](#):
>
> In the log file for this source port I only find quite correct entries, and none related to the problem I have:

Sounds like haproxy is stopped (or crashes). How long those the PID of haproxy that served your request live after this happened?

When Haproxy disconnects it is supposed to [log the state at disconnection](https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#8.5), always.

> [@luke](#):
>
> This requires the client to reconnect (and for now this is how I workarounded it on client side, by retrying connection when lost).

Whatever the root cause here may be, retrying idempotent transactions on temporary failures is always a good idea.

---

<div class="post-metadata">

**Author:** ![luke](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@luke](https://discourse.haproxy.org/u/luke)\
**Post date:** [February 8, 2021, 8:29am UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/3 "2021-02-08T08:29:02Z")

</div>

Hello,

> [@lukastribus](#):
>
> Sounds like haproxy is stopped (or crashes). How long those the PID of haproxy that served your request live after this happened?

Haproxy PID stays the same, many days while having such connectivity issue.

Regards,  
Łukasz

---

<div class="post-metadata">

**Author:** ![luke](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@luke](https://discourse.haproxy.org/u/luke)\
**Post date:** [February 8, 2021, 8:31am UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/4 "2021-02-08T08:31:47Z")

</div>

> [@luke](#):
>
> Haproxy PID stays the same, many days while having such connectivity issue.

Like:

```plaintext
user 2273 0.0 2.2 195564 88932 ? S Feb01 0:34 haproxy -sf 10884 -f haproxy.cfg
user 16301 0.2 2.1 201664 87280 ? Sl Feb02 24:39 haproxy -sf 10884 -f haproxy.cfg

```

And since that time I had those issue few times.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [February 8, 2021, 9:34pm UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/5 "2021-02-08T21:34:21Z")

</div>

Can you provide the original screenshot above? The “problem FIN” overlay hides the most important information, which is the timestamp of the FIN’s.

---

<div class="post-metadata">

**Author:** ![luke](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@luke](https://discourse.haproxy.org/u/luke)\
**Post date:** [February 9, 2021, 8:56am UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/6 "2021-02-09T08:56:50Z")

</div>

Hi,

> [@lukastribus](#):
>
> Can you provide the original screenshot above? The “problem FIN” overlay hides the most important information, which is the timestamp of the FIN’s.

Sure:

 ![full-screenshot](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/2X/d/d01f9b936feaea5e0b00953d8c1bf424b5b38993.png)

Regards,  
Łukasz

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [February 9, 2021, 9:06am UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/7 "2021-02-09T09:06:00Z")

</div>

I’m unsure what happens here, I think it would be best to file an bug on github so we can troubleshoot further there:

> **[Build software better, together](https://github.com/haproxy/haproxy/issues/new/choose)**
>
> xy/haproxy/issues/new/choose

---

<div class="post-metadata">

**Author:** ![luke](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@luke](https://discourse.haproxy.org/u/luke)\
**Post date:** [February 9, 2021, 10:05am UTC](https://discourse.haproxy.org/t/haproxy-replies-with-tcp-fin-on-http-get/6150/8 "2021-02-09T10:05:07Z")

</div>

> [@lukastribus](#):
>
> I’m unsure what happens here, I think it would be best to file an bug on github so we can troubleshoot further there:

Done: [Haproxy replies with TCP FIN on HTTP GET · Issue #1109 · haproxy/haproxy · GitHub](https://github.com/haproxy/haproxy/issues/1109)