# AppSec stops responding every few weeks essentially lockin me out

**URL:** <https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577>\
**Category:** crowdsec\
**Created:** [June 1, 2025, 2:05pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577 "2025-06-01T14:05:24Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![doney](https://avatars.discourse-cdn.com/v4/letter/d/a88e57/32.png) [@doney](https://discourse.crowdsec.net/u/doney)\
**Post date:** [June 1, 2025, 2:05pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/1 "2025-06-01T14:05:24Z")

</div>

I am using traefik with crowdsec bouncer plugin which has the ability to send request to AppSec. By default this plugin is set to block traffic on AppSec unreachable and failure. And there lies the problem because about every 3 week AppSec will stop responding and essentially block all traffic. I can restart crowdsec docker container and everything is back to normal. This problem correlates with following log entries:

```auto
time="2025-05-31T18:56:13Z" level=error msg="Error performing request: Head \"http://0.0.0.0:8080/v1/decisions/stream\": dial tcp 0.0.0.0:8080: connect: cannot assign requested address" type=appsec
time="2025-05-31T18:56:13Z" level=error msg="Unauthorized request from '172.18.0.28:33508' (real IP = 10.0.0.30)" type=appsec

```

I had to restart to get my things back, so there is not much I can do to test right now until it happens again.

---

<div class="post-metadata">

**Author:** ![zengateway](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/zengateway/32/1127_2.png) [@zengateway](https://discourse.crowdsec.net/u/zengateway)\
**Post date:** [June 3, 2025, 7:05pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/2 "2025-06-03T19:05:47Z")

</div>

same problem, restarting docker container fixed problem, eventually after 4-5 weeks problem returns

---

<div class="post-metadata">

**Author:** ![blotus](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/blotus/32/109_2.png) [@blotus](https://discourse.crowdsec.net/u/blotus)\
**Post date:** [June 5, 2025, 12:31pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/3 "2025-06-05T12:31:47Z")

</div>

Hello,

Can you confirm the value of `CrowdsecMode` in the bouncer config ?  
If set to `appsec`, then the bouncer will never contact the decision endpoint of LAPI, which will make Crowdsec think the bouncer is dead (for technical reasons, forwarded requests to the appsec are not taken into account when deciding if a bouncer is still alive or not).

If you have also bouncer auto-delete configured (`db_config.flush.bouncers_autodelete` in the crowdsec config), then the bouncer will be automatically deleted after some time (based on what you said, I’d guess you have a 3 weeks configuration).

In your case, the restart fixes it thanks to a side effect: you probably have set the bouncer API key in the env of the container, so it will be automatically recreated when the container starts.

For now, the “proper” workaround is to update the configuration of the bouncer:

- Set `CrowdsecMode` to `stream`
- Set `CrowdsecAppsecEnabled` to `true`

With this configuration, the bouncer will contact crowdsec to get the list of IPs to block, which will properly update its last query timestamp in the database, keeping it alive.

---

<div class="post-metadata">

**Author:** ![doney](https://avatars.discourse-cdn.com/v4/letter/d/a88e57/32.png) [@doney](https://discourse.crowdsec.net/u/doney)\
**Post date:** [June 6, 2025, 4:09am UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/4 "2025-06-06T04:09:04Z")

</div>

I already have the settings as you proposed:

```auto
    crowdsec:
      plugin:
        bouncer:
          enabled: true
          logLevel: INFO
          crowdsecMode: stream
          crowdsecAppsecEnabled: true
          crowdsecAppsecHost: crowdsec:7422
          crowdsecAppsecFailureBlock: true
          crowdsecAppsecUnreachableBlock: true
          crowdsecLapiKey: <API key>
          crowdsecLapiHost: crowdsec:8080
          crowdsecLapiScheme: http

```

When this happens, I am unable to get a response from crowdsec:8080 even when testing with curl. Normally I get 404.

---

<div class="post-metadata">

**Author:** ![blotus](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/blotus/32/109_2.png) [@blotus](https://discourse.crowdsec.net/u/blotus)\
**Post date:** [June 18, 2025, 1:44pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/5 "2025-06-18T13:44:01Z")

</div>

Hello,

1.6.9 was released yesterday (the docker image will likely be released today), and it includes a mitigation for this: if the appsec cannot contact LAPI, but the key used by the bouncer was validated in the past, the appsec will still process the request.

This is not a proper fix, as we are still unsure what can cause this (apart from a slow database), but it should help in most cases.

---

<div class="post-metadata">

**Author:** ![doney](https://avatars.discourse-cdn.com/v4/letter/d/a88e57/32.png) [@doney](https://discourse.crowdsec.net/u/doney)\
**Post date:** [June 19, 2025, 2:40pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/6 "2025-06-19T14:40:39Z")

</div>

Thank you. I do have port monitoring set up for 8080 now, so even if traefik does not out right ban me, I will still know when LAPI stops responding. I can report back and maybe leave it in that state for a day or two if we need to troubleshoot.

---

<div class="post-metadata">

**Author:** ![doney](https://avatars.discourse-cdn.com/v4/letter/d/a88e57/32.png) [@doney](https://discourse.crowdsec.net/u/doney)\
**Post date:** [June 19, 2025, 3:48pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/7 "2025-06-19T15:48:39Z")

</div>

@blotus I started digging into the error specifics and one thing that never made sense was `cannot assign requested address`. Intuitively one would assume that this is the server/LAPI not being able to bind to 8080, but this message comes from the client side. So the only thing it can mean is ephemeral port exhaustion. My docker restarted at 4am this morning and there are already 800+ connections `ESTABLISHED`:

```auto
# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.11:35698 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:60048 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:46656 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:55006 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:53728 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:50920 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:49788 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:55730 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:59606 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:45748 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:50156 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:46298 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:45804 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:42612 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:53966 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:49310 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:49056 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:51168 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:52848 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:43820 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:44272 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:33206 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:42968 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:51704 127.0.0.1:8080 ESTABLISHED 1/crowdsec
tcp 0 0 127.0.0.1:45246 127.0.0.1:8080 ESTABLISHED 1/crowdsec
...

```

I am going to guess that something is not properly closing connections. I will let it run a few days and will report back.

---

<div class="post-metadata">

**Author:** ![iiAmLoz](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/iiamloz/32/386_2.png) [@iiAmLoz](https://discourse.crowdsec.net/u/iiAmLoz)\
**Post date:** [June 20, 2025, 10:35am UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/8 "2025-06-20T10:35:06Z")

</div>

> <https://github.com/crowdsecurity/crowdsec/pull/3693>
>
> ref: https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-es…sentially-lockin-me-out/2577/7
> 
> By default http clients do not close connecting ports until the http client is GC'ed or the developer has explicit set the reject keepalives. 
> 
> This change reuses a http client so that the default transport internal cache can manage this optimally.

We dont reuse the http client so go cannot manage the connections optimally so this will improve it.

---

<div class="post-metadata">

**Author:** ![doney](https://avatars.discourse-cdn.com/v4/letter/d/a88e57/32.png) [@doney](https://discourse.crowdsec.net/u/doney)\
**Post date:** [July 12, 2025, 2:28pm UTC](https://discourse.crowdsec.net/t/appsec-stops-responding-every-few-weeks-essentially-lockin-me-out/2577/9 "2025-07-12T14:28:46Z")

</div>

I can confirm that the latest release no longer shows connections left open. Thank you