Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
Be able to run pi-hole behind reverse proxy as a subdomain, and not main host domain.
Actual Behaviour:
Documentation makes this seem "impossible"
I am attempting to run a pi-hole docker container on my home server. I already have a CaddyV2 reverse proxy in place for portainer and home assistant (and soon to be other stuff such as plex).
"""
Port 80 is highly recommended because if you have another site/service using port 80 by default then the ads may not transform into blank ads correctly. To make sure docker-pi-hole plays nicely with an existing webserver you run you'll probably need a reverse proxy webserver config if you don't have one already. Pi-hole must be the default web app on the proxy e.g. if you go to your host by IP instead of domain then Pi-hole is served out instead of any other sites hosted by the proxy. This is the 'default_server' in nginx or 'default' virtual host in Apache and is taken advantage of so any undefined ad domain can be directed to your webserver and get a 'blocked' response instead of ads.
"""
This seems needlessly restrictive and no explanation is offered as to why this must be the case. I want an application dashboard (such as Homer or Heimdall) located at mydomain.com, i don't want to have to. have mydomian.com be used as a pi-hole login.
Can someone explain if there is any work around for this?
Pi-hole needs port 80 for two purposes:
To serve its web UI, and to serve its optional HTTP block page.
The latter is only relevant if you'd deviate from Pi-hole's default NULL blocking mode and switch to one of its legacy IP blocking modes.
As a web browser would try to connect to <pihole-ip>:80, accessing the block page would fail if you moved Pi-hole to a different port. As this happens on the client side, Pi-hole can't do anything about this. Of course, HTTPS/port 443 never works in that scenario.
And with increasing proliferation of HTTPS, Pi-hole has switched its default blocking mode to NULL blocking, and I'd generally recommend to stick with it.
For access to Pi-hole's UI, you can use Docker's port forwarding as usual, matching an external port to Pi-hole's internal port 80, and you could also set Docker Pi-hole's WEB_PORTenvironment variable to change its internal port.
Thanks for the info, I have Pi-Hole running and working in docker, i just changed the external port in the docker-compose. But i'm still confused by the section I quoted. It made it seem like I need pi-hole to be the default application running on port 80/443 of my IP. If you're saying this is no longer case then the docker-hub instructions ought to be updated.
I can access the admin page just fine.... I have docker-compose external port 8080 mapped to pihole container port 80. If i got to IP_ADDRESS:8080/admin i get to the pi hole admin page just fine.
If you consider it "not a problem" that the docker documentation still insists that users must use the pi-hole as their default domain service.... This is bothersome at best and deception at worst; but either way it's misleading and confusing to a user.
If there is currently no reason why i must have pi-hole served as the default route for mydomain.com then maintainers ought to remove that from the docker instructions.
Maybe so, but you gotta admit that "oh we wont update the docs until more people complain" is kind of a poor response to a user concern for a very real issue.
Thanks for all the work on an amazing (and free!) product, wish the docs were as good as the actual product, but hey, i got it figured out i guess...
Or better, move it into a subsection that details that you need to have pi-hole as your default server IP application only on the legacy blocking modes.
You selectively copied something and made it entirely out of context. Congrats! Did you miss the bulleted section?
Port 80 is highly recommended because if you have another site/service using port 80 by default then the ads may not transform into blank ads correctly. To make sure docker-pi-hole plays nicely with an existing webserver you run you'll probably need a reverse proxy webserver config if you don't have one already. Pi-hole must be the default web app on the proxy e.g. if you go to your host by IP instead of domain then Pi-hole is served out instead of any other sites hosted by the proxy. This is the 'default_server' in nginx or ' default ' virtual host in Apache and is taken advantage of so any undefined ad domain can be directed to your webserver and get a 'blocked' response instead of ads.
You can still map other ports to Pi-hole port 80 using docker's port forwarding like this -p 8080:80 , but again the ads won't render properly. Changing the inner port 80 shouldn't be required unless you run docker host networking mode.
I must not be comprehending it; but that it isn't clear to me that
but again the ads won't render properly
does not seem to indicate why
Pi-hole must be the default web app on the proxy
Considering earlier replies were indicating that
The latter is only relevant if you'd deviate from Pi-hole's default NULL blocking mode and switch to one of its legacy IP blocking modes
I'm not trying to be rude here, but you're coming off as hostile. I'm genuinely trying to understand this stuff. I'm not a web guy, I do firmware in C for a living (and not for devices that deal with web stuff).
Point taken, I apologize. I didn't mean to accuse you all of deception. I meant that it was misleading (to varying degrees for people with different understanding). When i found out that it worked (seemingly fine) without it being the default app, it felt weird reading it MUST be the default app.
Maybe explaining in that first bullet point why ads "won't render properly" in this scenario as I'm not understanding the difference.