Okay, I finally figured out, fkl7834456 was right, it's censorship.
It's just an incredible coincidence this happened when I was messing with Win11 and OpenWRT firmware.
I tested with software called "YogaDNS" because there was a button to load all popular DNS servers and without VPN almost all DNS over HTTPS is red "bad".
As soon as I took a green DNS instance from the YogaDNS to the HTTPS-DNS-Proxy everything was working fine, even with that health error in OpenWRT logs.
Sorry to bother you people, and thank you so much!
stangri - Your software is great, but seems I have to find a way to configure and use DNSCrypt because my ISP is
Oh, wow, so your ISP is blocking popular DoH resolvers by IP-address?
PS. If anyone wants to contribute the JS code, I can totally implement an RPCD call to check if the pre-packaged resolvers in the luci package are reachable.
I am currently facing this same issue of DoH crashing randomly on Linksys E8450 on 24.10. Both luci-DoH and regular DoH package are updated to the latest.
I faced the same issue in the last 23.05 stable series OpenWrt as well.
For me to fix, I'll have go into luci-DoH and click restart to get the internet connection back.
Please let me know if there is an interim fix for this because it's quite annoying to lose internet randomly.
Hi @stangri , I see you are the maintainer of the project. The package still does crash on my E8450 24.10 and I can see it on the syslog. Can you please exactly tell me what information you would need to debug/fix this?
Meanwhile, this project is written in rust and supports DoQ and others, but the dev told me they don't know how to port it to ipk package for OpenWrt. Please take a look!
There was a bug in the luci app where the bootstrap_dns servers from the providers' json files. Sadly I can't find neither the issue created for it nor the forum post, so whoever discovered it and alerted me to this issue, please make yourself known.
The fix I implemented might have side-effects, but I'm very short on time, so I haven't tested all the possible use cases.
I'd appreciate as many people as possible testing luci-app-https-dns-proxy 2025.05.11-r2 from my repo (you do NOT need to update the principal package, but it got a version bump to stay in sync), doing as much thru WebUI as you can.
Upon reading through this thread I was curious as to why I never experienced any noticeable issues with https-dns-proxy. I am currently running version 2025.05.11-r1 on 24.10.2. I checked my log and found that though I have the same service-stopping message (7 seconds after startup), that it is remedied when part of my startup script runs.
I have ethtool set to modify multiple parameters on both the LAN and WAN interfaces; during which they disable / re-enable. At the 14 second mark after startup https-dns-proxy starts again when the interfaces are back up and there are no further related errors or issues.
In this particular case, I was on the version for which the bug was initially reported. It is because
that I use ethtool in the startup script to disable Energy Efficient Ethernet (among other parameters) on both adapters (which re-initiallizes them) that I never experienced the issue. When WAN comes back up after ethtool finishes, it triggers https-dns-proxy to restart on it's own; effectively working around the issue.
Even if I did upgrade to the version that was just released though, it would not be a relevant test since my startup configuration already works around the issue.
