Bad Request when added link is deleted on reverse proxy

[update-freak]

Describe the bug
After trying to delete a selected link I got the info:

Bad Request
The browser (or proxy) sent a request that this server could not understand.

I use a reverse proxy (e.g. changedetection.beispiel.dynv6.net) on my Synology NAS.

Version
Exact version in the top right area: 0.52.6

How did you install?
Docker

To Reproduce
Steps to reproduce the behavior:

1. Go to a already added link and try to delete it

Expected behavior
No error

Desktop (please complete the following information):

• OS: Windows 11
• Browser: Firefox (Windows)

[dgtlmoon]

no logs from the application, i dont know how to help hmm

can you add any logs?

[dgtlmoon]

this is defintely tested for so hmmm

[update-freak]

yes, sry. Created the issue via mobile and plan was to add logs. So here are the logs:

log from Portainer:
changedetection_logs.txt

docker compose:

services:
  changedetection:
    container_name: changedetection
    image: ghcr.io/dgtlmoon/changedetection.io
    restart: always
    ports:
      - 5054:5000
    volumes:
      - /volume1/docker/changedetection:/datastore:rw
    environment:
     - BASE_URL=https://changedetection.beispiel.dynv6.net
     - TZ=Europe/Berlin
     - LOGGER_LEVEL=ERROR

[dgtlmoon]

I see no 'submit' from that in your logs, did you actually click "loschen" and is that in the logs?

[dgtlmoon]

are you using some reverse proxy?

[update-freak]

yes, I clicked on "Löschen".
And I also use a reverse proxy.

I tried now to delete a item for both URLs:
http://192.168.178.27:5054 -> here it works
https://changedetection.beispiel.dynv6.net -> here it does not work

=> conclusion: seams that using a reverse proxy (I use the integrated one from Synology DSM) caused this issue

[dgtlmoon]

I'll move this to discussions for now, i'm wrunning it also behind reverse proxy (nginx) without problem, so its something with your setup, unfortunatley I cant debug that for you tho, but its good to know. other people run it on DSM without problem

I would say run tcpdump between the two and see what is spits out

[dgtlmoon]

BTW

172.23.0.1 - - [16/Jan/2026 12:34:12] "�[31m�[1mGET /socket.io/?EIO=4&transport=websocket HTTP/1.1�[0m" 400 -
172.23.0.1 - - [16/Jan/2026 12:34:17] "�[31m�[1mGET /socket.io/?EIO=4&transport=websocket HTTP/1.1�[0m" 400 -
172.23.0.1 - - [16/Jan/2026 12:34:19] "�[31m�[1mPOST /form/checkbox-operations HTTP/1.1�[0m" 400 -
172.23.0.1 - - [16/Jan/2026 12:34:25] "�[36mGET /static/favicons/site.webmanifest HTTP/1.1�[0m" 304 -
172.23.0.1 - - [16/Jan/2026 12:34:25] "�[31m�[1mGET /socket.io/?EIO=4&transport=websocket HTTP/1.1�[0m" 400 -
172.23.0.1 - - [16/Jan/2026 12:34:31] "�[31m�[1mGET /socket.io/?EIO=4&transport=websocket HTTP/1.1�[0m" 400 -
172.23.0.1 - - [16/Jan/2026 12:34:41] "�[31m�[1mGET /socket.io/?EIO=4&transport=websocket HTTP/1.1�[0m" 400 -

this is only the HTTP logs, not from the actual process in the container either so hmm

[update-freak]

ok, clear. But strange that it worked before also on my system without changing anything on my NAS. I detected this issue after I saw that different languages (in my case German) are available. Maybe I can trace back the exact version where it worked and the next version where it did not work.

[dgtlmoon]

Heya, yes good point... maybe the language session is adding something extra hmm, if you clear the browser "application" of all cookies etc, does it load? btw, try to find the actual container/code logs

[update-freak]

• 0.52.1 -> since then it does not work
• 0.51.4 -> here it still worked

Log screenshot from 0.52.6: