Bug: Control Server on TCP Port 8000 Giving ERROR 400: Bad Request.

[JZ-SmartThings]

Is this urgent?

Yes

Host OS

XPenology --- Container Manager (Docker)

CPU arch

x86_64

VPN service provider

Windscribe

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2024-05-18T18:08:57.405Z (commit 4218dba)

What's the problem 🤔

Control Server on port 8000 gives the following result when running directly from the Gluetun container's shell:

/ # wget http://localhost:8000                                                   
--2024-05-22 07:45:26--  http://localhost:8000/                                  
Resolving localhost (localhost)... 127.0.0.1, ::1                                
Connecting to localhost (localhost)|127.0.0.1|:8000... connected.                
HTTP request sent, awaiting response... 400 Bad Request                          
2024-05-22 07:45:26 ERROR 400: Bad Request.                       

Would love to get this fixed as I use Dashy with the Gluetun widget where I can compare my public IP vs. Gluetun's. This feature broke approximately 2-3 weeks ago and I tried everything to fix it. Once I saw that it doesn't behave the same as before within the container itself, I finally decided to bug it.

Thank you!

Share your logs (at least 10 lines)

2024/05/22 00:40:47	stdout	2024-05-22T07:40:47Z INFO [http server] 400 GET  wrote 41B to 127.0.0.1:47240 in 7.92µs
2024/05/22 00:36:01	stdout	2024-05-22T07:36:01Z INFO [http server] 400 GET /status wrote 41B to 127.0.0.1:46338 in 5.171µs
2024/05/22 00:35:43	stdout	2024-05-22T07:35:43Z INFO [http server] 400 GET  wrote 41B to 127.0.0.1:46292 in 6.862µs
2024/05/22 00:34:43	stdout	2024-05-22T07:34:43Z INFO [http server] 400 GET  wrote 41B to 192.168.100.3:40590 in 5.615µs
2024/05/22 00:34:38	stdout	2024-05-22T07:34:38Z INFO [http server] 400 GET  wrote 41B to 192.168.100.3:40558 in 6.7µs
2024/05/22 00:34:20	stdout	2024-05-22T07:34:20Z INFO [vpn] You are running on the bleeding edge of latest!
2024/05/22 00:34:20	stdout	2024-05-22T07:34:20Z INFO [ip getter] Public IP address is 1.1.1.1 (United States, Somewhere, Somewhere)
2024/05/22 00:34:19	stdout	2024-05-22T07:34:19Z INFO [healthcheck] healthy!
2024/05/22 00:34:19	stdout	2024-05-22T07:34:19Z INFO [dns] ready
2024/05/22 00:34:19	stdout	2024-05-22T07:34:19Z INFO [dns] generate keytag query aaaaaa. NULL IN

Share your configuration

version: "3.9"
networks:
    net_vpn:
        driver: bridge
        ipam:
            driver: default
            config:
                - subnet: 192.168.100.0/24
services:
    vpn:
        image: qmcgaw/gluetun
        container_name: vpn
        restart: always
        volumes:
            - /volume1/docker/vpn:/config:rw
        networks:
            net_vpn:
                ipv4_address: 192.168.100.3
        deploy:
          restart_policy:
            condition: on-failure
            delay: 15s
            max_attempts: 5
            window: 120s
        cap_add:
            - NET_ADMIN
        devices:
          - /dev/net/tun:/dev/net/tun
        environment:
            - VPN_SERVICE_PROVIDER=windscribe
            - VPN_TYPE=openvpn
            - OPENVPN_USER=hidden
            - OPENVPN_PASSWORD=hidden
            - SERVER_REGIONS="US East"

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[JZ-SmartThings]

Apologies, this is working as expected. The correct way to do this is to expose port 8000 on the container and call this URL sample for testing and not just the root of port 8000: wget http://192.168.100.1:8000/v1/publicip/ip

[github-actions]

Closed issues are NOT monitored, so commenting here is likely to be not seen.
If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because @qdm12 is the sole maintainer of this project
which became too popular to monitor issues closed.