Is this urgent?
No
Host OS
Debian Trixie
CPU arch
x86_64
VPN service provider
ProtonVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2026-02-20T17:16:46.684Z (commit 0c3e5d9)
What's the problem 🤔
Control server returns empty IP address. Logs indicate that the context timeout was exceeded for all ip fetchers and for version checking. As you can see in the logs below, Gluetun identifies an external IP address; however, v1/publicip/ip returns {"public_ip":""}.
My auto-port-updater (mjmeli/qbittorrent-port-forward-gluetun-server) works, and qBittorrent allows uploads. The lack of a public IP in the control server response bothers Homepage and falsely alarms my monitoring. Therefore I consider this problem not urgent, and recognize others may disagree.
Restarting by sending {"status":"stopped"} and {"status":"running"} to the control server fixes the problem.
Issue #1855 and issue #2848 appear to be the same thing, but both have been closed.
I also see problems related to issue #2997 (portforward reverts to 0 and shuts down incoming connections), but I believe that to be a separate issue.
Share your logs (at least 10 lines)
2026-04-25T18:38:21Z INFO [storage] creating /gluetun/servers.json with 20604 hardcoded servers
2026-04-25T18:38:21Z INFO Alpine version: 3.22.3
2026-04-25T18:38:21Z INFO OpenVPN version: 2.6.16
2026-04-25T18:38:21Z INFO IPtables version: v1.8.11
2026-04-25T18:38:21Z INFO Settings summary:
├── VPN settings:
| ├── VPN provider settings:
| | ├── Name: protonvpn
| | ├── Server selection settings:
| | | ├── VPN type: wireguard
| | | ├── Countries: ****
| | | ├── Port forwarding only servers: yes
| | | └── Wireguard selection settings:
| | └── Automatic port forwarding settings:
| | ├── Redirection listening port: disabled
| | ├── Use port forwarding code for current provider
| | └── Forwarded port file path: /tmp/gluetun/forwarded_port
| ├── Wireguard settings:
| | ├── Private key: ****
| | ├── Interface addresses:
| | | └── ****/32
| | ├── Allowed IPs:
| | | ├── 0.0.0.0/0
| | | └── ::/0
| | └── Network interface: tun0
| | └── MTU: use path MTU discovery.
.
.
.
├── Public IP settings:
| ├── IP file path: /tmp/gluetun/ip
| ├── Public IP data base API: ipinfo
| └── Public IP data backup APIs:
| ├── ifconfigco
| ├── ip2location
| └── cloudflare
└── Version settings:
└── Enabled: yes
2026-04-25T18:38:21Z INFO [routing] default route found: interface eth0, gateway 172.24.0.1, assigned IP 172.24.0.2 and family v4
.
.
.
2026-04-25T18:38:32Z INFO [http server] 200 GET /v1/portforward wrote 11B to 172.24.0.2:55680 in 50.53µs
2026-04-25T18:38:32Z INFO [dns] ready
2026-04-25T18:38:32Z INFO [http server] 200 GET /v1/portforward wrote 11B to 172.24.0.2:55696 in 36.95µs
2026-04-25T18:38:33Z INFO [http server] 200 GET /v1/portforward wrote 11B to 172.24.0.2:55698 in 30.618µs
2026-04-25T18:38:35Z INFO [http server] 200 GET /v1/portforward wrote 11B to 172.24.0.2:55700 in 33.726µs
2026-04-25T18:38:37Z ERROR [vpn] getting public IP address information: fetching information: all fetchers failed: ipinfo: Get "https://ipinfo.io/": context deadline exceeded
ifconfig.co: Get "https://ifconfig.co/json": context deadline exceeded
ip2location: Get "https://api.ip2location.io/": context deadline exceeded
cloudflare: Get "https://speed.cloudflare.com/meta": context deadline exceeded
2026-04-25T18:38:38Z INFO [http server] 200 GET /v1/portforward wrote 11B to 172.24.0.2:55712 in 37.718µs
2026-04-25T18:38:42Z ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/commits": context deadline exceeded
2026-04-25T18:38:42Z INFO [port forwarding] starting
2026-04-25T18:38:42Z INFO [port forwarding] gateway external IPv4 address is 79.127.184.193
2026-04-25T18:38:43Z INFO [port forwarding] port forwarded is 51792
2026-04-25T18:38:43Z INFO [firewall] setting allowed input port 51792 through interface tun0...
Share your configuration
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
networks:
- ripperrnet
environment:
- TZ=${TZ}
- HTTP_CONTROL_SERVER_AUTH_CONFIG_FILEPATH=/config/auth.toml
- VPN_SERVICE_PROVIDER=protonvpn
- VPN_TYPE=wireguard
- WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
- SERVER_COUNTRIES=redacted,comma,separated,list # Best privacy laws
- SECURE_CORE_ONLY=off # Enable for better privacy, bolstering less-private server countries.
- PORT_FORWARD_ONLY=on # TODO: does port forwarding work with secure core?
- VPN_PORT_FORWARDING=on
- BORINGPOLL_GLUETUNCOM=on # Poll AI slop scamsite
ports:
- ${GLUETUN_SERVER_PORT}:${GLUETUN_SERVER_PORT}
- ${QBT_WEBUI_PORT}:${QBT_WEBUI_PORT}
- ${PROWLARR_PORT}:${PROWLARR_PORT}
- ${FLARESOLVERR_PORT}:${FLARESOLVERR_PORT}
volumes:
- /etc/localtime:/etc/localtime:ro
- ${APP_DIR}/gluetun:/gluetun
- ${APP_DIR}/gluetun/config:/config
restart: unless-stopped
logging:
driver: "json-file"
options:
max-size: "50m"
max-file: "3"
labels:
homepage.group: Network
homepage.name: Gluetun
homepage.icon: gluetun
homepage.href: "http://${OVERKILL}:${GLUETUN_SERVER_PORT}"
homepage.weight: 1000
homepage.description: Manages the ProtonVPN connection
homepage.widget.type: gluetun
homepage.widget.version: 2
homepage.widget.fields: '["public_ip", "country", "port_forwarded"]'
homepage.widget.url: "http://${OVERKILL}:${GLUETUN_SERVER_PORT}/"
homepage.widget.key: ${GLUETUN_API_KEY}
Is this urgent?
No
Host OS
Debian Trixie
CPU arch
x86_64
VPN service provider
ProtonVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2026-02-20T17:16:46.684Z (commit 0c3e5d9)
What's the problem 🤔
Control server returns empty IP address. Logs indicate that the context timeout was exceeded for all ip fetchers and for version checking. As you can see in the logs below, Gluetun identifies an external IP address; however,
v1/publicip/ipreturns{"public_ip":""}.My auto-port-updater (mjmeli/qbittorrent-port-forward-gluetun-server) works, and qBittorrent allows uploads. The lack of a public IP in the control server response bothers Homepage and falsely alarms my monitoring. Therefore I consider this problem not urgent, and recognize others may disagree.
Restarting by sending
{"status":"stopped"}and{"status":"running"}to the control server fixes the problem.Issue #1855 and issue #2848 appear to be the same thing, but both have been closed.
I also see problems related to issue #2997 (portforward reverts to 0 and shuts down incoming connections), but I believe that to be a separate issue.
Share your logs (at least 10 lines)
Share your configuration