Why do some sites take forever to load when using Pi-hole? (for versions < v4.0)

Update: 2018-08-06

As of v4.0, this should no longer be a problem unless you choose to deviate from the new default blocking mode and return to the IP-based mode. And the iptables rules mentioned in this article should not be needed.


As of v3.1 the first reason should not be an issue anymore

That being said, there are generally two reasons this happens:

  1. your ISP changes your IPv6 address (Global Unicast Address), causing Pi-hole to become misconfigured and timing out when trying to load a page.

  2. a domain is requested over port 443 (HTTPS/SSL) and times out since Pi-hole doesn't currently respond to HTTPS requests

Resolving these issues

1. Use ULA or edit setupVars.conf

As of v3.1 this (IPv6) should not be an issue.

You can look for a setting in your router to enable ULA (Unique Local Address). This is the best solution.

If your router does not have this setting, you can edit setupVars.conf with the correct IP address and update the ad block lists. Below is a script that should do this for you:

IPV6_ADDRESS=$(ip -6 a | grep 'fc\|fd' | awk -F " " '{gsub("/[0-9]*",""); print $2}')
echo ${IPV6_ADDRESS}
sed -i.setupVars.bak "/IPV6_ADDRESS/d;" "/etc/pihole/setupVars.conf"
echo "IPV6_ADDRESS=${IPV6_ADDRESS}" >> "/etc/pihole/setupVars.conf"
pihole -g

2. Setup HTTPS firewall rules

There is a good reason we don't currently support HTTPS:

HTTPS requires a certificate that matches the domain name in order to be valid. It's difficult to enable that for the Pi-hole pages. It would be considered a form of a Man-In-The-Middle attack as we would be impersonating the encrypted communications between the browser client and the end server, which should be encrypted from client to server.

Technical users may be able to set this up with a self-signed certificate themselves, but it's not something we want to do on a clean installation

Users have also had success blocking TCP/UDP port 443 so it denies the request instead of waiting to timeout. Similarly, QUIC uses UDP (as described here) so that is blocked as well.

iptables -A INPUT -p tcp --destination-port 443 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --destination-port 80 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p udp --destination-port 443 -j REJECT --reject-with icmp-port-unreachable

ip6tables -A INPUT -p tcp --destination-port 443 -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -p udp --destination-port 80 -j REJECT --reject-with icmp6-port-unreachable
ip6tables -A INPUT -p udp --destination-port 443 -j REJECT --reject-with icmp6-port-unreachable

Some users have reported that these rules do not work on Windows machines, but these very similar commands below will:

iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset 
ip6tables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset 

The tcp-reset option will tell REJECT to send a TCP RST packet in reply to the sending host. TCP RST packets are used to close open TCP connections gracefully.

To save your firewall rules to persist across reboots, run

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Test HTTPS Blocking Performance

You may want to check if HTTPS is timing out or not after making the firewall changes. A good test can be found here.


Jacob, for any reason, how can we reset this blocking?

It seems, this is only for the current session.
After a PI reboot I do not find any setup with iptables -L

Thank you!

Hi there. Put it in /etc/rc.local.

1 Like

Please help me understand why DNS would be requesting over HTTPS? In what scenarios does DNS skip TCP 53 and request over 443?


The DNS doesn't request over HTTPS. The process is that a client tries to visit an HTTPS site, the Pi-hole sees that the domain is on a block list and responds with the IP address of the Pi-hole. The client then sends it's requests the the lighttpd server and in the case of HTTP, it will be given the blockpage. In the case of HTTPS, since we do not have the certificates of the site you are trying to visit, you just get nothing in return. This can cause delays with the client timing out waiting for the HTTPS response. In order to avoid the timeout you can use the firewall capabilities of IPTables to reject the connection and the client wont wait for a response as it is told that the site doesn't exist and is not available.

1 Like

I wish I had enough time right now to try and makes sense of what has been posted about this.

All I know is that when I attempt to edit a Google Blogger page it takes forever to load.

The query log shows:

I'm wondering if there's any way to wedge Gossamer Threads or a similar page speed test into the mix for testing?

As someone with not a lot of experience regarding SSL and HTTPS, how does adding that routing rule not stop you from visiting any HTTPS site (which is bad)? To my untrained eyes, that's what it looks like. Thanks in advance for someone with more knowledge to teach me.

It only makes the connection for a blocked HTTPS site not time out. The connection is still blocked by Pi-hole. And since only blocked HTTPS connections connect to the Pi-hole, it doesn't affect unblocked HTTPS connections.

As linux N00b
When I tried this on my Raspberry install i'm getting the following error
-bash: /etc/pihole/rules.v4: Permission denied
-bash: /etc/pihole/rules.v6: Permission denied

I did some googling and found the following option working.
sudo bash -c "iptables-save > /etc/pihole/rules.v4"
sudo bash -c "iptables-save > /etc/pihole/rules.v6"

1 Like

You should just be able to append sudo the to front of the original commands.

forgot to paste that part but i used sudo in front of it and that didn't work on my Pi,
Don't know why.

3 posts were split to a new topic: Unable to add HTTP iptables rules

A post was merged into an existing topic: Unable to add HTTP iptables rules

when testing the 2 links

The http link says "var x = "Pi-hole: A black hole for Internet advertisements.""
The https link fails to load the page "this site cant be reached" got no block page.

is this the expected results?


So i would apply the iptable rules on both rapi that are used for pihole?

Those are the expected results. See that the link goes to a javascript file, so we return some valid but worthless javascript. Apply the iptables rules on your Pi-hole's ports.

Since I'm seeing the expected results then I should not need to add those commands? I have also disabled ipv6 on my router.

I've had an odd issue, from time to time a few pages stall for a minute then goes to the chrome dns error page for a quick 3 seconds and then page loads.

At first I thought it was my wifi as no wired issues have had this issue, but now I'm thinking it maybe more of an android issue with pihole and ipv6. I've seen request in pihole even though I have ipv6 disabled.

If https sites do not stall every time, then you are ok.

You can't quite disable IPv6 on a network because it's designed to not need a central server like a router (at least for link-local addresses). Also, DNS requests can be made over IPv4 or IPv6 for either an IPv4 or IPv6 answer, the protocol of the request doesn't matter.

Hey all,

I was struggling with intermittent slow-loading for a while too and finally found my solution.
Some sites (ex: www.googletagservices.com) are starting to use the QUIC protocol, which functions over UDP.
Blocking 80/443 UDP takes care of that, and TCP is best served with a tcp-reset.

iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --dport 80 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p udp --dport 443 -j REJECT --reject-with icmp-port-unreachable

If you're using IPv6, match your ip6tables.

Hope this helps someone out there!


I'm trying to understand where to apply these firewall rules. What is the source and the destination of the traffic being rejected?

Just run the commands on the Pi-hole. They apply to the Pi-hole's firewall.