/api/health endpoint response time grows over time until container restart

I am seeing that on an otherwise idle server a simple api call to the health endpoint already takes more than 800ms. What is a good way to find out why it takes so long? A typical log entry:

{
"message": "2026/05/30 16:11:22.187 \u001b[1;44m[D]\u001b[0m |2a01:488:66:1000:5c33:9112:0:1|\u001b[97;42m 200 \u001b[0m| 856.493976ms| match|\u001b[97;44m GET \u001b[0m /api/health r:/api/health",
"container": {
"id": "a67a7d99a3ea31303b2081833994b83320168930b061385d13c07eb6eba8270e",
"imageName": "jumager/casdoor:local_deploy",
"created": "2026-05-30T15:41:37.651225711Z",
"imageId": "sha256:fa077721152293705a24194b23dcc4bd293f9cd01bc7538aaef6ac8e6f42a6bf",
"name": "/casdoor"
},
"instance": {
"zone": "europe-west3-a",
"id": "opc5"
}
}

The message above is a bit unreadable, but I could not get rid of the color escapes in the log.

As I am following head, I looked in my monitoring when this did start, and since May 29, where I installed the last head it started to get slower over some time, until it restarts the container and it starts all over again

@jumager can you switch to different casdoor versions to see which version starts to have this issue?

@hsluoyz I have found the issue, the problem appears to be related to ipv6 being configured but not properly working. The node runs on oracle cloud infrastructure, and the default receipt for enabling ipv6 in docker does not work there, one has to use the ipv6nat solution. I would believe the problem was some outbound connections resolved to IPv6 but timed out, maybe triggering a memory leak as the /api/health endpoint was getting slower over time until the docker container was restarted. The average response time is now 10ms.

so it's not casdoor related

Well, casdoor still behaved a bit bad, as the memory did grow until it crashed. It should not have a memory leak in an error path.

Well, I managed to reproduce it again, and it is probably a fault in the way I configured my docker environment. If I restart the container, the problem disappears. I believe it is a problem with dns resolution via the docker network. To pinpoint the problem I played with it a bit, and for other services I can get the problem to go away by letting the docker container listen on an Unix domain socket for all traffic. Is that possible to do with casdoor as well?