$ curl http://git.target-domain:8080
<!doctype html>
<!-- Pi-hole: A black hole for Internet advertisements
* (c) 2017 Pi-hole, LLC (https://pi-hole.net)
Your output does not demonstrate that Pi-hole would be blocking git.target-domain.
Rather, it would seem that the webserver is not recognizing the URL it is asked to access and redirects to its 404 handler. If Pi-hole's lighttpd is your webserver, that would be Pi-hole's blocking page.
However, I'd expect Pi-hole's webserver to run on your 192.168.3.21 only.
Is your 192.168.3.1 redirecting port 8080 to your Pi-hole host at 192.168.3.21:80?
Or are those IPs perhaps attached to the same host?
EDIT:
Your debug log shows that you are running a dockered Pi-hole, but your Pi-hole container is not configured for your host's private range IP yet.
You should set the respective FTLCONF_REPLY_ADDR4 recommended variable.
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
ports:
- "53:53/tcp"
- "53:53/udp"
#- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
- "80:80/tcp"
#network_mode: "host"
environment:
#TZ: 'America/Chicago'
WEBPASSWORD: 'xxxxxx'
FTLCONF_REPLY_ADDR4: 192.168.3.21
# Volumes store your data between container upgrades
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq.d:/etc/dnsmasq.d'
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN # Recommended but not required (DHCP needs NET_ADMIN)
restart: unless-stopped
Yes, but that's how Pi-hole would have served the block page for a browser trying to access resources from a blocked domain that would instead have been asking Pi-hole's lighttpd to serve that URL, back in the days when HTTPS was not yet the predominant protocol.
The corresponding outdated IP blocking modes may be retired with one of Pi-hole's next releases.
FTLCONF_REPLY_ADDR4 was just some additional finding from your debug log.
The top domain will always be handled that way with PI-hole's webserver, but you should be able to access additional content from more specific URLs from its dedicated subfolder.
I'm reasonably confident that the following curl will return a 200:
I wonder why http://pi.hole redirects but http://git.target-domain doesn't.. "The top domain will always be handled that way with PI-hole's webserver" - anyhow all good now! Thanks so much!!!
