Bug: DNS over TLS Errors Cannot Resolve Hostname, Must use DoH

[emogu2]

Is this urgent?

No

Host OS

MacOS 26.2

CPU arch

armv7l

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-01-27T09:16:51.996Z (commit facc6df)

What's the problem 🤔

I've found a satisfactory way around this issue using DoH, hence it not being urgent, but I'm still very curious about what is failing between DoT and Cloudflare. This started abruptly and I first noticed it 4 days ago. The containers using network_mode: "container:gluetun" (including nzbget and prowlarr) were presenting errors such as:

Could not resolve hostname usenet.host1.com Error -3 - Try again
Could not resolve hostname usenet.host2.com: Error -3 - Try again
Blocking Usenet (usenet.host1.com) for 10 sec

Unable to connect to indexer. This is typically caused by DNS/SSL issues. Check DNS settings, ensure IPv6 is working or disabled, consider using different DNS servers, or try a VPN/proxy if needed. See: 'https://wiki.servarr.com/prowlarr/troubleshooting#dns-ssl-connection-issues' Resource temporarily unavailable (usenetindexer.com:443)

I tried generating a new Proton privatekey and pulling down the stack and restarting it with fresh pulls. Each time it would appear to work ok but after 20-30 minutes it would stop being able to resolve hostnames again.

So I started tweaking environment variables. Setting dot=off worked, so I determined the issue had something to do with DNS, TLS, or Cloudflare. I googled around for a couple days and tried alternatives such as setting DNS upstream resolvers to ones other than CF, setting DNS keep nameserver off, and block malicious to off, and several combinations thereof. I also tried shutting off my Pihole and other containers establishing network interfaces. Finally setting upstream resolver type to DoH seemed to be the most stable encrypted DNS option that worked. I'm ok leaving it like that, but if there's something I've done incorrectly that results in DoT being unable to resolve hostnames I'd like to correct it in the meantime.

Share your logs (at least 10 lines)

2026-02-04T09:53:22-05:00 WARN HEALTH_VPN_DURATION_INITIAL is obsolete
2026-02-04T09:53:22-05:00 INFO [routing] default route found: interface eth0, gateway redacted, assigned IP redacted and family v4
2026-02-04T09:53:22-05:00 INFO [routing] local ethernet link found: gretap0
2026-02-04T09:53:22-05:00 INFO [routing] local ethernet link found: erspan0
2026-02-04T09:53:22-05:00 INFO [routing] local ethernet link found: eth0
2026-02-04T09:53:22-05:00 INFO [routing] local ipnet found: redacted/16
2026-02-04T09:53:22-05:00 INFO [firewall] enabling...
2026-02-04T09:53:22-05:00 INFO [firewall] enabled successfully
2026-02-04T09:53:23-05:00 INFO [storage] merging by most recent 20717 hardcoded servers and 20717 servers read from /gluetun/servers.json
2026-02-04T09:53:23-05:00 INFO Alpine version: 3.22.2
2026-02-04T09:53:23-05:00 INFO OpenVPN 2.5 version: 2.5.10
2026-02-04T09:53:23-05:00 INFO OpenVPN 2.6 version: 2.6.16
2026-02-04T09:53:23-05:00 INFO IPtables version: v1.8.11
2026-02-04T09:53:23-05:00 INFO Settings summary:

├── VPN settings:
|   ├── VPN provider settings:
|   |   ├── Name: protonvpn
|   |   ├── Server selection settings:
|   |   |   ├── VPN type: wireguard
|   |   |   ├── Hostnames: redacted
|   |   |   ├── 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
|   |       ├── Forwarded port up command: /bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":$(echo {{PORTS}} | cut -d, -f1),\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8480/api/v2/app/setPreferences 2>&1'
|   |       └── Forwarded port down command: /bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":123}" http://127.0.0.1:8480/api/v2/app/setPreferences 2>&1'
|   └── Wireguard settings:
|       ├── Private key: redacted
|       ├── Interface addresses:
|       |   └── 10.2.0.2/32
|       ├── Allowed IPs:
|       |   ├── 0.0.0.0/0
|       |   └── ::/0
|       └── Network interface: tun0
|           └── MTU: 1320
├── DNS settings:
|   ├── Keep existing nameserver(s): no
|   ├── DNS server address to use: 127.0.0.1
|   ├── DNS forwarder server enabled: yes
|   ├── Upstream resolver type: dot
|   ├── Upstream resolvers:
|   |   └── cloudflare
|   ├── Caching: yes
|   ├── IPv6: no
|   ├── Update period: every 24h0m0s
|   └── DNS filtering settings:
|       ├── Block malicious: yes
|       ├── Block ads: no
|       └── Block surveillance: no
├── Firewall settings:
|   ├── Enabled: yes
|   └── Outbound subnets:
|       └── redacted
├── Log settings:
|   └── Log level: info
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target addresses:
|   |   ├── cloudflare.com:443
|   |   └── github.com:443
|   ├── Small health check type: ICMP echo request
|   |   └── ICMP target IPs:
|   |       ├── 1.1.1.1
|   |       └── 8.8.8.8
|   └── Restart VPN on healthcheck failure: yes
├── Shadowsocks server settings:
|   └── Enabled: no
├── HTTP proxy settings:
|   └── Enabled: no
├── Control server settings:
|   ├── Listening address: :8000
|   ├── Logging: yes
|   └── Authentication file path: /gluetun/auth/config.toml
├── Storage settings:
|   └── Filepath: /gluetun/servers.json
├── OS Alpine settings:
|   ├── Process UID: 501
|   ├── Process GID: 20
|   └── Timezone: america/new_york
├── Public IP settings:
|   ├── IP file path: /tmp/gluetun/ip
|   ├── Public IP data base API: ipinfo
|   └── Public IP data backup APIs:
|       ├── ifconfigco
|       ├── ip2location
|       └── cloudflare
├── Server data updater settings:
|   ├── Update period: 24h0m0s
|   ├── DNS address: 1.1.1.1:53
|   ├── Minimum ratio: 0.8
|   ├── Providers to update: protonvpn
|   ├── Proton API email: 
|   └── Proton API password: [not set]
└── Version settings:
    └── Enabled: yes

2026-02-04T09:53:23-05:00 INFO [firewall] setting allowed subnets...
2026-02-04T09:53:23-05:00 INFO [routing] default route found: interface eth0, gateway redacted, assigned IP redacted and family v4
2026-02-04T09:53:23-05:00 INFO [routing] adding route for redacted
2026-02-04T09:53:23-05:00 INFO [dns] using plaintext DNS at address 1.1.1.1
2026-02-04T09:53:23-05:00 INFO [healthcheck] listening on 127.0.0.1:9999
2026-02-04T09:53:23-05:00 INFO [http server] http server listening on [::]:8000
2026-02-04T09:53:23-05:00 INFO [firewall] allowing VPN connection...
2026-02-04T09:53:23-05:00 INFO [wireguard] Using available kernelspace implementation
2026-02-04T09:53:23-05:00 INFO [wireguard] Connecting to redacted
2026-02-04T09:53:23-05:00 INFO [wireguard] 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-02-04T09:53:23-05:00 INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
2026-02-04T09:53:23-05:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1440
2026-02-04T09:53:24-05:00 INFO [dns] downloading hostnames and IP block lists
2026-02-04T09:53:26-05:00 INFO [dns] DNS server listening on [::]:53
2026-02-04T09:53:27-05:00 INFO [dns] ready
2026-02-04T09:53:28-05:00 INFO [ip getter] Public IP address is redacted
2026-02-04T09:53:29-05:00 INFO [vpn] You are running on the bleeding edge of latest!
2026-02-04T09:53:29-05:00 INFO [port forwarding] starting

Share your configuration

---
services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 9696:9696
      - 6789:6789
      - 8480:8480
      - 8686:8686
      - 8084:8084
      - 5078:5078
      - 1080:3000
    volumes:
      - /Volumes/Plex/gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - FIREWALL_OUTBOUND_SUBNETS=redacted
      - HEALTH_VPN_DURATION_INITIAL=120s
      # Wireguard:
      - WIREGUARD_PRIVATE_KEY=redacted
      - VPN_PORT_FORWARDING=on
      # Automatically update qbittorrent with forwarded port:
      - VPN_PORT_FORWARDING_UP_COMMAND=snipped for length
      - VPN_PORT_FORWARDING_DOWN_COMMAND=snipped for length
      - TZ=America/New_York
      - PUID=501
      - PGID=20
      - SERVER_HOSTNAMES=snipped for length
      # Server list updater
      - UPDATER_PERIOD=24h
    restart: unless-stopped


Here's a compose for a separate container using Gluetun:
---
services:
  nzbget:
    image: nzbgetcom/nzbget:latest
    container_name: nzbget
    network_mode: container:gluetun
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/New_York
    volumes:
      - /Volumes/Plex/NZBGet/config:/config
      - /Volumes/Plex/NZBGet/data:/data
      - /Volumes/Plex/NZBGet:/temp
      - /Volumes/Media/Downloads:/downloads
    restart: unless-stopped

[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

[qdm12]

The problem might be related to #3108 - feel free to hook in the issue and try out the tagged image mentioned? If it works with tag :v3.41.0, then it's likely that problem, especially given your MTU is found as 1440 which is the highest possible which looks a bit suspicious.

IF it doesn't work with v3.41.0 then it's something else, and in that case only answer the following please

1. Does using something else than cloudflare with DoT work?
2. With DoT do you also get warnings/errors in the Gluetun logs? Does it get unhealthy?
3. Try clearing FIREWALL_OUTBOUND_SUBNETS? There may be a conflict in IP address, although unlikely.
4. Does it work with a previous tag of Gluetun, i.e. v3.40/v3.41?
5. Try also running with LOG_LEVEL=debug to see more on DNS errors, since these are now logged in the debug level

[maksii]

Having a similar problem in one of the domains, with the same logs and a similar setup. Switching to :v3.41.0 helped.

[emogu2]

Thanks so much for the response! As per your suggestion, I tried v3.41.0 but the issue persisted. But when I tried 3.40.0 it worked! I was (and am still) able to use the containers using services on the gluetun network mode in 3.40.0. However, I still get hundreds of "Unable to resolve hostname" errors on NZBGet even though the service does get through to pull the download requests. Those errors don't occur when I set UPSTREAM_RESOLVER_TYPE=doh, but the end result of a working container is the same in both cases.

That said, I tried your other suggestions out of curiosity to see if I could resolve the hostname errors even though everything is working with 3.40.0:

1. No, using non-cloudflare resolvers doesn't work actually. When the error first appeared I did set resolvers to cloudflare,quad9,libreDNS, and multiple combinations thereof, which seemed to work at the time, but now does not. I may simply have not given the setup enough time to fail the first time I tried it, as with most of these tests everything seems to work until some time has passed.

2. I did get warnings/errors in logs at first, and that looked like this:
   WARN [dns] getting tls connection for request IN AAAA creating connection: running TLS handshake with 1.0.0.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:40520->1.0.0.1:853: read: connection reset by peer
   (I didn't have this saved when I first made the ticket, but found it digging through browser history.)
   But when I set out to create this ticket I wasn't seeing log errors anymore until I set LOG_LEVEL=debug as per your suggestion. Here is a snippet of the most common error I get in Gluetun logs when I try to download something on NZBGet via Gluetun 3.40.0:

WARN [dns] dialing tls server for request IN A news.eweka.nl.: dial tcp 1.1.1.1:853: i/o timeout
WARN [dns] dialing tls server for request IN AAAA news.eweka.nl.: context deadline exceeded

Below is the repeating error I get on Gluetun latest once the failures begin. It repeats over and over again every few seconds.

2026-02-09T14:50:29-05:00 WARN [dns] getting tls connection for request IN AAAA news.newshosting.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:[redacted port]->1.1.1.1:853: read: connection reset by peer
2026-02-09T14:50:30-05:00 DEBUG [healthcheck] startup check parallel attempt failed: dialing: dial tcp4: lookup github.com: i/o timeout
2026-02-09T14:50:30-05:00 DEBUG [healthcheck] startup check parallel attempt failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout
2026-02-09T14:50:30-05: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 github.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout
2026-02-09T14:50:30-05:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2026-02-09T14:50:30-05:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION
2026-02-09T14:50:30-05:00 INFO [vpn] stopping
2026-02-09T14:50:30-05:00 DEBUG [wireguard] closing controller client...
2026-02-09T14:50:30-05:00 DEBUG [wireguard] removing IPv4 rule...
2026-02-09T14:44:26-05:00 DEBUG [netlink] ip -f inet rule del lookup [redacted port] pref 101
2026-02-09T14:44:26-05:00 DEBUG [wireguard] shutting down link...
2026-02-09T14:44:26-05:00 DEBUG [wireguard] deleting link...
2026-02-09T14:44:26-05:00 INFO [vpn] starting
2026-02-09T14:44:26-05:00 DEBUG [wireguard] Wireguard server public key: redacted
2026-02-09T14:44:26-05:00 DEBUG [wireguard] Wireguard client private key: redacted
2026-02-09T14:44:26-05:00 DEBUG [wireguard] Wireguard pre-shared key: [not set]
2026-02-09T14:44:26-05:00 INFO [firewall] allowing VPN connection...
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables -t filter -L OUTPUT --line-numbers -n -v
2026-02-09T14:44:26-05:00 DEBUG [firewall] found iptables chain rule matching "--delete OUTPUT -d [redacted IP] -o eth0 -p udp -m udp --dport [redacted port] -j ACCEPT" at line number 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables -t filter -D OUTPUT 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables -t filter -L OUTPUT --line-numbers -n -v
2026-02-09T14:44:26-05:00 DEBUG [firewall] found iptables chain rule matching "--delete OUTPUT -o tun0 -j ACCEPT" at line number 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables -t filter -D OUTPUT 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -L OUTPUT --line-numbers -n -v
2026-02-09T14:44:26-05:00 DEBUG [firewall] found iptables chain rule matching "--delete OUTPUT -o tun0 -j ACCEPT" at line number 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -D OUTPUT 4
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables --append OUTPUT -d [redacted IP] -o eth0 -p udp -m udp --dport [redacted port]  -j ACCEPT
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/iptables --append OUTPUT -o tun0 -j ACCEPT
2026-02-09T14:44:26-05:00 DEBUG [firewall] /usr/sbin/ip6tables --append OUTPUT -o tun0 -j ACCEPT
2026-02-09T14:44:26-05:00 INFO [wireguard] Using available kernelspace implementation
2026-02-09T14:44:26-05:00 INFO [wireguard] Connecting to [redacted IP]:[redacted port] 
2026-02-09T14:44:26-05:00 DEBUG [netlink] ip -f inet rule add lookup [redacted port]  pref 101
2026-02-09T14:44:26-05:00 INFO [wireguard] 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-02-09T14:44:26-05:00 INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
2026-02-09T14:44:26-05:00 DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
2026-02-09T14:44:26-05:00 DEBUG [MTU discovery] finding IPv4 next hop MTU
2026-02-09T14:44:26-05:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1440

With resolver_type=doh, I get no errors or failures in the gluetun logs on latest, and the only error of any kind I get is in the nzbget logs. It appears 3 times in a row, on some downloads but not all, and then continues on working fine. No effect on functionality. I suspect it has to do with an error communicating with 1 of my 2 usenet news-servers, because when I disable it this error does not appear.

Could not read from TLS-Socket: Connection closed by remote host

3. I commented out the outbound subnets line and it made no difference in 3.40.0 or latest.

4. & 5. Are discussed above.

I hope that additional info helps.

[qdm12]

Try pulling the latest image and use DoT? pmtud was kind of not complete for a few weeks, it should be working well now. It's likely the cause why DoT was failing. If it still fails try setting WIREGUARD_MTU=1000 just to see if it fixes it?

For v3.40 vs v3.41 I'm not sure, they both were using the same Go dns code; maybe it's the Go upgrade that changed Go's TLS packet sizes, making it difficult to fit with an MTU too high 🤔 just speculation though!

[gauravojha]

Came in here to report the same.

I have always set the MTU to 1350. No issues on 3.40. But moving to 3.41.0+, dot doesn't work. Must set it to doh for it to work. Even setting the MTU to a less value like 1000 doesn't work.

@qdm12 what would be better, setting the resolver to doh, or downgrading to 3.40 till the issue is identified?