Windows 10: Chrome 55 and IE 11. Edge does not seem to exhibit this behavior.
I can try other devices when I get home tonight if that will help troubleshoot the issue.
Thanks. It is interesting to see that it does not happen on all browsers, so it seems to be a client side problem. We will nevertheless try to figure out how to solve it.
I'm seeing the same behavior on Mobile Safari and Mobile Chrome on iOS 10.
Run pihole -d for a debug token. Do you have any other web service running on port 80? The site loaded quickly for me.
Pihole is the only thing running on this Pi, so I assume nothing else is on 80.
Did you browse into the forums or just go to the main page? The problem doesn't occur until you get into the forum pages.
Debug token: 7amrq79hui
Yes, I tried (and tried again now) this randomly chosen page http://www.avsforum.com/forum/301-avs-foruma-articles/ and it loads within less than a second.
From your debug log I see that you are still running an older version (but the update should not change anything for you).
Have you been visiting this page (or another one that causes problems) while you recorded the debug log (it should have asked you to do that)?
Yep, I visited (http://www.avsforum.com/forum/166-lcd-flat-panel-displays/) while recording the debug. The page hung waiting for a response from ad.crwdcntrl.net during the entire recording session.
For what it's worth, I don't see the the issue when I go to the specific page you linked.
I just updated a couple of days ago, I didn't realize there was another - I'll update again.
I tried your link as well - everything fine here. However, we have seen that ads might be served depending on your Geolocation (which is West-Germany at my end) so that might explain the deviation.
Check this log for anything suspicious, like the reply taking too long: sudo tail -F /var/log/lighttpd/access.log
I also have no issues with this site.
Hi everyone.
I have exactly the same issue as 'sock'
I'm using a dockerized pihole and some pages are stuck because of pending javascript requests.
for example:
- https://tags.tiqcdn.com/utag/schibsted/leboncoin-responsive/prod/utag.js keeps pending until unreachable
- https://tags.tiqcdn.com keeps pending until unreachable
- http://tags.tiqcdn.com is instantly piholed
The website : https://www.leboncoin.fr/
ping tags.tiqcdn.com sends the pihole ip address.
Hypothesis: the issue seems to concern HTTPS (javascript) requests
Any ideas? 
Do you get an error if you go directly to a blocked URL that times out?
Hi Mcat12,
Yes I get an error, saying the website is unreachable because it took too much time to respond.
But the message only occurs on HTTPS, on HTTP, the website is instantly piholed and the pihole page is displayed
When I look at pihole debug, nothing seems to happen when i browse https://tags.tiqcdn.com, however things happen when i go to http://tags.tiqcdn.com
The issue really seems to be limited to ad domains hosted over HTTPS :s
Unfortunately we cannot serve HTTPS out of the box since we can not provide valid certificates for ads domains. You can look around on Discourse for solutions, but it is not supported officially.
1 Like
I'm sorry I don't understand what is the issue with HTTPS 
Pihole is a DNS server, not a proxy server? Or is it because it mixes a DNS + webserver?
If that's the issue, instead of displaying an 'index' file, can't I just redirect connections to 127.0.0.1 as would do hosts file?
Furthermore: why am I, with "sock", the only one concerned by this issue?? Every page that loads some (blacklisted) ads over HTTPS should be concerned!
If every ad server switches to HTTPS, pihole will become completely inoperative and timeout every page?? :s
EDIT 1:
Can I use this kind of solution to bypass HTTPS certificate issues with self signed certificates?
https://www.cyberciti.biz/tips/howto-lighttpd-create-self-signed-ssl-certificates.html
I only use pihole in my house, and if I have to add the certificate on every of my devices for it to work (without hours of work), I will. Slowing down a lot of websites is hardly a viable option.
EDIT 2: A SOLUTION
I fixed the issue using a self-signed certificate, now the https ads are instantly blocked. To achieve this, I followed this guides (french links but the commands are self explained)
- Generate a private ssl certificate
lighttpd [Wiki ubuntu-fr] - Add the certificate to my computer
https://blogs.technet.microsoft.com/sbs/2008/05/08/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista/
Thank you DL6ER-Test and Mcat12 for your help, I hope my links will help other users if they encounter the same issues.
1 Like
We still block HTTPS ads, just for some reason your install is timing out on HTTPS ads. The reason that HTTPS ads return that error instead of displaying the block page is that since we redirect the request for example.com from the original server to Pi-hole, the browser does not receive the correct security certificate and correctly assumes that there's some misdirection going on. This is a security feature, but either way the ad is still blocked. You probably could get around it with a self-signed wildcard certificate, but that opens up loads of security concerns and is not recommended.
1 Like
I concur.
Most (if not close to all) users do not see issues with HTTPS requests as they don't see ads but immediately get a connection refused error:
I think I might have spotted the issue:
I run the pihole in a docker container, with specific ports forwarded. Before installing a self signed certificate, I only forwarded port 80 and port 53.
docker run -p 53:53/tcp -p 53:53/udp -p 80:80
When I installed the certificate, I also added port 443. Maybe its that part that fixed the issue! As the port was closed, the connection always timed out!
I suppose the port was not closed since if a port is closed (not listening) there is no connections and TCP is supposed to reply with a RST package, i.e. "Connection refused" error. Instead, your port was filtered, i.e. your browser never got a reply from anyone if there is someone listening or not on this port.
Filtered connections do not reply at all and silently drop any incoming packet. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software.
Just found this topic through google. To solve the https timeout issue you should not block https requests in your pi firewall, but reject them. Like so:
sudo ufw allow http
sudo ufw reject https