AdGuardHome
AdGuardHome copied to clipboard
AdguardTeam
Numerous TLS handshake error from IP:PORT: EOF server=https
Prerequisites
-
[x] I have checked the Wiki and Discussions and found no answer
-
[x] I have searched other issues and found no duplicates
-
[x] I want to report a bug and not ask a question or ask for help
-
[x] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)
Platform (OS and CPU architecture)
Custom (please mention in the description)
Installation
GitHub releases or script from README
Setup
On one machine
AdGuard Home version
v0.107.56
Action
The logs are being filled with hundreds of messages like this from various Apple devices. The devices include iPads, iPhones, Home Pods, and an Apple Watch. I haven't seen this from a Mac.
2025/02/18 17:03:19.364086 [error] http: TLS handshake error from 192.168.200.238:61841: EOF server=https
2025/02/18 17:03:20.014069 [error] http: TLS handshake error from 192.168.200.102:51139: EOF server=https
2025/02/18 17:03:23.389614 [error] http: TLS handshake error from 192.168.200.238:61847: EOF server=https
2025/02/18 17:03:26.330261 [error] http: TLS handshake error from 192.168.1.51:59449: EOF server=https
2025/02/18 17:03:27.529887 [error] http: TLS handshake error from 192.168.200.238:61849: EOF server=https
2025/02/18 17:03:27.554607 [error] http: TLS handshake error from 192.168.200.238:61851: EOF server=https
2025/02/18 17:03:27.578776 [error] http: TLS handshake error from 192.168.200.238:61852: EOF server=https
2025/02/18 17:03:29.654833 [error] http: TLS handshake error from 192.168.200.238:61854: EOF server=https
2025/02/18 17:03:31.677121 [error] http: TLS handshake error from 192.168.200.238:61858: EOF server=https
2025/02/18 17:03:34.657039 [error] http: TLS handshake error from 192.168.200.102:51141: EOF server=https
2025/02/18 17:03:34.695451 [error] http: TLS handshake error from 192.168.200.102:51142: EOF server=https
2025/02/18 17:03:35.682476 [error] http: TLS handshake error from 192.168.200.238:61860: EOF server=https
2025/02/18 17:03:35.709608 [error] http: TLS handshake error from 192.168.200.238:61861: EOF server=https
2025/02/18 17:03:35.734814 [error] http: TLS handshake error from 192.168.200.238:61863: EOF server=https
2025/02/18 17:03:35.760041 [error] http: TLS handshake error from 192.168.200.238:61864: EOF server=https
2025/02/18 17:03:36.836720 [error] http: TLS handshake error from 192.168.200.102:51146: EOF server=https
2025/02/18 17:03:37.766082 [error] http: TLS handshake error from 192.168.200.238:61866: EOF server=https
2025/02/18 17:03:37.793488 [error] http: TLS handshake error from 192.168.200.238:61868: EOF server=https
2025/02/18 17:03:38.633199 [error] http: TLS handshake error from 192.168.200.102:51147: EOF server=https
2025/02/18 17:03:49.246453 [error] http: TLS handshake error from 192.168.200.102:51150: EOF server=https
To give an idea of how frequently this is happening:
root@coruscant:/opt/AdGuardHome# cat /var/log/AdGuardHome.err | grep "2025/02/18 17:02" | wc -l
151
root@coruscant:/opt/AdGuardHome# cat /var/log/AdGuardHome.err | grep "2025/02/18 17:01" | wc -l
89
root@coruscant:/opt/AdGuardHome# cat /var/log/AdGuardHome.err | grep "2025/02/18 17:0" | wc -l
489
Expected result
I'd like to either not have these errors or better understand the source of the errors.
Actual result
Lots and lots of error messages.
Additional information and/or screenshots
This is possibly related to https://github.com/AdguardTeam/AdGuardHome/issues/7585, but I wanted to separate the EOF messages from the unknown certificate messages.
I came down this rabbit hole due to occasional issues where our iPhones and iPads would show "no internet connection" when they wake up or just randomly while using the phone. I do think that might ALSO be a separate issue, and may write up something if this works: https://www.reddit.com/r/Ubiquiti/comments/1gb9vkx/psa_massive_dns_timeout_errors_with_adguard_home/
Does your adguard home have a valid SSL certificate? What SSL settings do you have please.
Does your adguard home have a valid SSL certificate? What SSL settings do you have please.
I've got two servers setup (in my head I need a backup so my wife doesn't get mad if one dies), both with valid certificates.
The address does only resolve on my local network, since I don't want to expose my DNS to the world.
Encryption Settings:
Certificate Validity:
I'll add that I am seeing the same, mainly from Apple Devices.
2025/02/27 12:46:50.308888 [error] http: TLS handshake error from 192.168.76.120:56096: EOF server=https 2025/02/27 12:46:50.325597 [error] http: TLS handshake error from 192.168.76.120:56097: EOF server=https 2025/02/27 12:46:50.340118 [error] http: TLS handshake error from 192.168.76.120:56098: EOF server=https 2025/02/27 12:46:50.354165 [error] http: TLS handshake error from 192.168.76.120:56099: EOF server=https 2025/02/27 12:46:52.416534 [error] http: TLS handshake error from 192.168.76.120:56102: EOF server=https
I'm running the latest ADGuard docker with a valid ECC certificate.
Running v0.108.0-b.63
Googled and found this as well. I'm seeing the same thing.. almost like the client is doing a port scan or something. I did a tcpdump and did detect is was from my wife's iPad and my Apple TV.. or like the Apple TV trying to connect to the iPad?
Looks like multicast? Here's the readable headers.
EDIT: removed tcpdump output.. Realized I hadn't captured the proper port.
Nothing usable from tcpdump.. But it is making a HTTP connection to port 443 on the adguardhome server. Guess it's trying to do dns over https?
I am curious, are you two seeing random disconnects on Apple devices? My phone will sometimes take a few seconds to pull content when it wakes up, then randomly when I am using it I get the message "no internet connection". I am trying to narrow down if these logs are related.
I always have the “ My phone will sometimes take a few seconds to pull content when it wakes up” issue on my Apple devices. At first wake up, a few seconds before it starts browsing. I don’t ever have the “no internet connection” issue.
I always have the “ My phone will sometimes take a few seconds to pull content when it wakes up” issue on my Apple devices. At first wake up, a few seconds before it starts browsing. I don’t ever have the “no internet connection” issue.
Hmm, good to know. Does that happen when you're not using AdGuard locally?
I always have the “ My phone will sometimes take a few seconds to pull content when it wakes up” issue on my Apple devices. At first wake up, a few seconds before it starts browsing. I don’t ever have the “no internet connection” issue.
Hmm, good to know. Does that happen when you're not using AdGuard locally?
I wouldn't know as my AdGuard is always on. I actually always had put this down to my Unifi setup, but perhaps it could be AdGuard....I would need to test various other configs to prove this though. I know 100% at home though, all apple devices get this inital delay.
I wouldn't know as my AdGuard is always on. I actually always had put this down to my Unifi setup, but perhaps it could be AdGuard....I would need to test various other configs to prove this though. I know 100% at home though, all apple devices get this inital delay.
I’ve been testing a bit since I reported it to UniFi as a bug. It’s possible it’s a combination of UniFi and Adguard since it isn’t widespread, but manually setting DNS on my iPhone to the Adguard hosted (not my home) server fixes this.
I noticed this issue was reported that has similar behavior to what we are seeing: https://github.com/AdguardTeam/AdGuardHome/issues/7564
What I’m unsure of is if the TLS messages are related to our issue.
I wouldn't know as my AdGuard is always on. I actually always had put this down to my Unifi setup, but perhaps it could be AdGuard....I would need to test various other configs to prove this though. I know 100% at home though, all apple devices get this inital delay.
I’ve been testing a bit since I reported it to UniFi as a bug. It’s possible it’s a combination of UniFi and Adguard since it isn’t widespread, but manually setting DNS on my iPhone to the Adguard hosted (not my home) server fixes this.
I noticed this issue was reported that has similar behavior to what we are seeing: #7564
What I’m unsure of is if the TLS messages are related to our issue.
I always assumed it was Unifis WPA3 taking its time to handshake.
I always assumed it was Unifis WPA3 taking its time to handshake.
I ran into it with WiFi 6 disabled, so I was running WPA2.
I am testing out force disabling Apple Private Relay via a DNS rewrite. I'm also going to ping some of my friends that are on Unifi but running a pihole to see if they have a similar experience. The plot is definitely thickening.
Again, I am unsure if these log messages are related in any way.
Does someone from the AdGuard team know what is occurring here? Maybe that can give us a thread.
Same problem, seeing same "error" message in my logs. Anybody found a solution?
Honestly, I'm thinking it's a problem with Apple devices, not Adguard.. Looks like they probe the DNS server to see what it provides, which includes a HTTP connection to an HTTPS port (no idea why). Happens every time they do a lookup.
Google'd the log error and found my way here. Any solution to this? I’m not sure it’s related but in the last week, since Friday/Saturday, I have been getting random and untimely disconnects on my mesh network (all nodes keep dropping their upstream connection). I am able to reach my WebUI for the main router through TS/VPN externally. But once I’m connected to the LAN/WiFi all Apple devices and other OSes (Android & Windows) that have a DoH or are VPN’d (through the router) to a different country are completely unusable.
Edit: added the other OSes
Same issue here - AdGuardHome running DoH in Docker Container with Unifi Dream Machine Pro network - Apple devices are generating [error] http: TLS handshake error from xx.xx.xx.xxx:50745: EOF server=https
Just to add a bit of variety, getting the same errors with apple devices - but I'm using a TP-Link omada router/network setup.
Having a similar issue. Apple Devices only. Adguard Home running on RPi, Network is Ubiquiti.
Also having this issue. Issue happens on any device. LG and Vizio TVs, Apple gear, others. Brand/type irrelevant. Happen to also be using Unifi gear for WiFi,Routing etc. ¯_(ツ)_/¯
same here, only see those messages generated from my iphone. I have a valid let's encrypt certificate but running https on 3001. Wondering why my iphone connects to 3001?
Honestly, I'm thinking it's a problem with Apple devices, not Adguard.. Looks like they probe the DNS server to see what it provides, which includes a HTTP connection to an HTTPS port (no idea why). Happens every time they do a lookup.
in my case, I see client hello after 3-way handshake. So the iphone is trying to setup tls1.3 connection. Also the error message indicates a problem with handshake instead of application.
It is clearly an Apple issue, but this is flooding my logs, with tons of entries, can't we just have an option to suppress this specific error log? that wouldn't fix the problem but as there is nothing we can do about lets at least make this less impactant
one more important finding... I'm running adguardhome on openwrt and I did an upgrade from openwrt 22.x to 24.10.1 this weekend. I did checked my syslog server and these error logs only appeared after the upgrade. OpenWRT switched the default TLS lib from wolfssl to mbedtls. I'm currently not sure what TLS lib the adguardhome binary from openwrt repo is using, but I assume there is a dependency to the TLS lib of this error.
It is clearly an Apple issue, but this is flooding my logs, with tons of entries, can't we just have an option to suppress this specific error log?
Agree, this is becoming a logs flooding issue! We need some serious solution for this!
I had similar issue and finally solved!
Check your DoH TLS cert: it MUST include the designating resolver IP in the certificate’s subjectAltName IPAddress entry for Verified Discovery to succeed. If it does not, iOS will reject the discovered DoH. You can also watch your DoH server logs to see if iOS starts and then aborts the TLS handshake.
Note about Let’s Encrypt: historically LE did not issue IP-address certs; LE began supporting IP certs in 2025 as a short-lived option — that may or may not help depending on your deployment and timing. If your cert is a plain hostname cert without the resolver IP in SAN, Verified Discovery will fail
The issue with that, is LE will not allow a private IP in a certs SAN.
It's ok if you use AdGuard on the internet, but for simple home users, you cant.
I've deep dived (sp?) this and the issue is down to having an SSL certificate enabled for the Web GUI, but this also enables DoH. You cannot split the two.
iOS uses DDR (Discovery of Designated Resolvers), so if you have an SSL certificate, this is what is happening. iOS is going to https://192.168.x.x/dns-query, and failing because the IP is not in the cert.
My only option here is to disable HTTPS entirely and run AdGuard on HTTP (As this is only on my LAN)
Not only will this stop the noise, but I'm hoping this gets rid of the iOS small delay at wakeup when starting to browse.
I dont use DoH on the LAN anway, only for upstream from AdGuard.
I got it working with an internal CA on my self-hosted home environment. Just make sure to add your CA to every iOS device and double-check that the CA has the full-trust toggle enabled in Settings → About → Certificate Trust Settings.
Small tip: if you want to issue a certificate with a long lifespan (e.g., 40 years), ensure the leaf certificate’s start date is set to 2019. Apple only allows longer lifespans for old certificates before 2020 - support.apple.com
Apple’s 398‑day limit applies only to TLS leaf certs issued by the preinstalled system roots on or after 2020‑09‑01; certificates issued before that cutoff (or by roots you add/administer) aren’t blocked by that rule.
You can use this simple openssl.cfg:
[ req ]
distinguished_name = dn
req_extensions = v3_req
x509_extensions = v3_req
prompt = no
[ dn ]
CN = adguard
[ v3_req ]
subjectAltName = IP:192.168.1.53, DNS:adguard
basicConstraints = critical,CA:FALSE
subjectKeyIdentifier = hash
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
[ ca ]
default_ca = CA_default
[ CA_default ]
database = tmp/db/index.txt
serial = tmp/db/serial.txt
default_md = sha256
copy_extensions = copy
unique_subject = no
private_key = ca.key
certificate = ca.pem
policy = policy_match
default_startdate = 20190101100000Z
default_enddate = 20490101100000Z
new_certs_dir = tmp
[ policy_match ]
commonName = supplied
And issue adguard certificate with command:
openssl req -config openssl.cfg -newkey rsa:2048 -nodes -keyout adguard.key -out tmp/certRequest.csr -batch
openssl ca -config openssl.cfg -out adguard.pem -in tmp/certRequest.csr -rand_serial -notext -batch
I can see why that would work, but it's a hassle for me. You have to remember to add the CA to every iOS device, including visitors (which isn't realistic), so I'll opt for no SSL :)
I agree with @ProximusAl; this is not a realistic solution. I have multiple users with various iOS devices, and implementing this would be cumbersome. For now, opting for no SSL seems to be the only viable solution!
I can confirm that switching to HTTP only does indeed remove the noise as it no longer advertises DDR. I'll have to wait until I'm home to confirm the iOS initial lag has gone too....
I can live with this....but there are a number of feature requests on here to split out the Web GUI and DoH TLS settings.......
Not sure I totally agree with this assessment. I'm using let's encrypt (no ip in the SAN) and stuff works.
I still get handshake errors, but stuff still seems to work. There must be more to it. Turning on "verbose" doesn't seem to offer any helpful debugging messages either. Kind of at a dead end at the moment.
Edit: I did notice a rather noticeable decrease in handshake errors when I turned off “automatically redirect to https” option on the Encryption Settings screen.