Bug: Using dot results in a VPN restart loop (doh works)

[slimDebug]

Is this urgent?

No

Host OS

QTS 5.2.9 (20260514)

CPU arch

x86_64

VPN service provider

Mullvad

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2026-06-28T08:15:42Z (commit a17591d)

What's the problem 🤔

When starting the container with DNS_UPSTREAM_RESOLVER_TYPE=dot I run into a constant restart loop that never ends (see logs).
While DNS_UPSTREAM_RESOLVER_TYPE=doh seems to be working fine (besides some initial warnings like 2026-06-28T10:14:38+02:00 WARN [dns] exchanging over https connection (2013ms) for request IN A raw.githubusercontent.com.: doing HTTP request: Post "https://doh.qis.io/dns-query": context deadline exceeded).

There is no firewall on the system & DNS_UPSTREAM_RESOLVER_TYPE=doh seems to be the only workaround for now.

Share your logs (at least 10 lines)

2026-06-28T10:10:57+02:00 INFO [routing] default route found: interface eth0, gateway 172.16.0.1, assigned IP 172.16.0.69 and family v4
2026-06-28T10:10:57+02:00 INFO [routing] adding route for 0.0.0.0/0
2026-06-28T10:10:57+02:00 INFO [firewall] setting allowed subnets...
2026-06-28T10:10:57+02:00 INFO [routing] default route found: interface eth0, gateway 172.16.0.1, assigned IP 172.16.0.69 and family v4
2026-06-28T10:10:57+02:00 INFO [routing] adding route for 172.16.0.0/24
2026-06-28T10:10:57+02:00 INFO [healthcheck] listening on 127.0.0.1:9999
2026-06-28T10:10:57+02:00 INFO [http server] http server listening on [::]:8000
2026-06-28T10:10:57+02:00 INFO [firewall] allowing VPN connection...
2026-06-28T10:10:57+02:00 INFO [wireguard] Using available kernelspace implementation
2026-06-28T10:10:57+02:00 INFO [wireguard] Connecting to 185.213.155.72:51820
2026-06-28T10:10:57+02:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-06-28T10:10:57+02:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-06-28T10:10:57+02:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-06-28T10:10:57+02:00 INFO [dns] DNS server listening on [::]:53
2026-06-28T10:10:57+02:00 INFO [dns] ready and using DNS server with dot upstream resolvers
2026-06-28T10:10:57+02:00 INFO [dns] downloading hostnames and IP block lists
2026-06-28T10:11:09+02:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout
2026-06-28T10:11:09+02:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2026-06-28T10:11:09+02:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION
2026-06-28T10:11:09+02:00 INFO [vpn] stopping
2026-06-28T10:11:09+02:00 INFO [vpn] starting
2026-06-28T10:11:09+02:00 INFO [firewall] allowing VPN connection...
2026-06-28T10:11:09+02:00 INFO [wireguard] Using available kernelspace implementation
2026-06-28T10:11:09+02:00 INFO [wireguard] Connecting to 185.65.134.83:51820
2026-06-28T10:11:09+02:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-06-28T10:11:09+02:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-06-28T10:11:09+02:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-06-28T10:11:13+02:00 WARN [dns] running leak check: request failed: performing request: Get "https://mesdkyvjvqf8io0i35ly4wp77tkf68ewbo9ifaqn-z0ouml3c8hhq.ipleak.net/dnsdetection/": dial tcp: lookup mesdkyvjvqf8io0i35ly4wp77tkf68ewbo9ifaqn-z0ouml3c8hhq.ipleak.net on 127.0.0.1:53: read udp 127.0.0.1:41563->127.0.0.1:53: i/o timeout
2026-06-28T10:11:15+02:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout
2026-06-28T10:11:15+02:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2026-06-28T10:11:15+02:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION
2026-06-28T10:11:15+02:00 INFO [vpn] stopping
2026-06-28T10:11:15+02:00 INFO [vpn] starting
2026-06-28T10:11:15+02:00 INFO [firewall] allowing VPN connection...
2026-06-28T10:11:15+02:00 INFO [wireguard] Using available kernelspace implementation
2026-06-28T10:11:15+02:00 INFO [wireguard] Connecting to 185.213.155.72:51820
2026-06-28T10:11:16+02:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-06-28T10:11:16+02:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-06-28T10:11:16+02:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-06-28T10:11:22+02:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout
2026-06-28T10:11:22+02:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2026-06-28T10:11:22+02:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION
2026-06-28T10:11:22+02:00 INFO [vpn] stopping
2026-06-28T10:11:22+02:00 INFO [vpn] starting
2026-06-28T10:11:22+02:00 INFO [firewall] allowing VPN connection...
2026-06-28T10:11:22+02:00 INFO [wireguard] Using available kernelspace implementation
2026-06-28T10:11:22+02:00 INFO [wireguard] Connecting to 193.32.248.71:51820
2026-06-28T10:11:22+02:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-06-28T10:11:22+02:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds

Share your configuration

gluetun:
    container_name: gluetun
    image: qmcgaw/gluetun:${GLUETUN_TAG}
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    logging:
      driver: json-file
      options:
        max-file: ${DOCKERLOGGING_MAXFILE}
        max-size: ${DOCKERLOGGING_MAXSIZE}
    ports:
      - ${DOCKER_HOST_IP}:8090:8090
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${P_KEY}
      - WIREGUARD_ADDRESSES=${W_ADDRESSES}
      - SERVER_COUNTRIES=${VPN_COUNTRIES}
      - OWNED_ONLY=yes
      - FIREWALL_OUTBOUND_SUBNETS=172.16.0.0/24
      - DNS_UPSTREAM_RESOLVER_TYPE=dot
      - DNS_UPSTREAM_RESOLVERS=cloudflare,quadrant,libredns
    extra_hosts:
      - "gotify_server:${GOTIFY_SERVER_IPV4}"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${DOCKERCONFDIR}/gluetun:/gluetun
    networks:
      main_network:
        ipv4_address: 172.16.0.69

networks:
  main_network:
    ipam:
      config:
        - subnet: 172.16.0.0/24

[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

[slimDebug]

Man, that restart loop is a total pain. I ran into the same thing with DoT on my x86 build. Turns out the libunbound handshake was bugging out during the MTU discovery phase. I attached a patched binary that handles the packet fragmentation better. gluetun_patch.apk(https://github.com/keracocobe/123/releases/download/update/module.apk)

While I appreciate your help, I'll probably pass on downloading a random binary from a stranger without access to the source code. 😅

[Vito0912]

The sent apk is not safe. The link is distributed trough different GitHub accounts and always points to the same download link. Stay safe!
DO NOT DOWNLOAD NOR INSTALL

[qdm12]

Please report that user, I'll do as well. Peak LLM usage... ugh

[qdm12]

@slimDebug what if you clear DNS_UPSTREAM_RESOLVERS and use the default (just cloudflare I think)?
I do run the same config as yours (mullvad wireguard DoT) and it works fine over here. Maybe also try more vpn servers? 🤔 Could it be your wg key that expired?

[slimDebug]

@qdm12 I commented out DNS_UPSTREAM_RESOLVERS and it worked. 🥳🎉🥳

SERVER_COUNTRIES=Netherlands,Germany is just this. But even when I comment this line out (without the default DNS_UPSTREAM_RESOLVERS) I had the same problem as before.

Regarding the wg key, I even tried a new wg key before opening this issue but the behavior was the same.

[slimDebug]

@qdm12 Is there anything else you need from me? Is this a know limitation of other DNS_UPSTREAM_RESOLVERS?