Transporting a feature request from GitHub to make it votable here.
Was having this issue, and it was of course resolved by removing the non-folders in /var/www/html/.
This should be checked during installs and upgrades and the user warned or something.
The direction of your idea is correct. However, I disagree in principle that pihole uses the default ports for http 80 (or https 443) because they are - without any exception ports used for webserver services.
lighttpd used for pihole is really special.
Instead of your suggestion, I would go forward to made a counter argument and say that lighttpd should have a default port - for example - 8082 for http and 8083 for https! Thereafter no checks for an existing web server is required and all the installations will function out of the box.
A clever option 
would be to use one of the http proxy port used by Cloudflare, for example 2053 for lighttpd associated to pihole as dedicated deamon service. So, if one uses the free Cloudflare DNS services, one could instantly use the proxy port 2053 of pihole without any problems.
A list of these proxy ports are made available here:
Here, I have choosen a proxy port a request made with https protocol. Because pihole has to do with port 53, I choose 2053. But no other specific reasons other than this. Thereafter all the other http and proxy services shall remain untouched! Then, no additional checks are required, as you suggested.
For any reason if the port 80 or 443 is exposed from inside of home network through DMZ 
, then the lighttpd ports will not remain vulnerable as they are not default ports. One would have to go through a port scan first to gather intelligence before an attack.
So, in the contrary to your suggestion 
, I propose that the pihole default port 80 should be removed to a different non-conflicting port with an advise to the user to use that default port only.
In this case, all other webserver ports and functions remains untouched 
, regardless of if they do exist at the time of installation or even if they are installed at a later date.
Thanks for the feedback. All of our feature requests are votable, and we try to implement the ones with the most votes.
Thanks for your response. I have seen so many such feature request here with ZERO or one vote and felt that some of them are inevitable feature.
Ha, only now I understand why these ones never made through the Developers motivation, which is based on number of votes. I now take promise to make one installer on this feature request above and publish the code on Github, if the number of votes are insufficient.
We also gladly accept pull requests against our repo if there is something you'd like to see! That's the beauty of FOSS 
The downside to this, is that we rely on port 80 in order to serve the block page back to the client.
e.g https://advertisingdomain.com/badadvert.jpg will resolve to http://[address of pihole device]/badadvert.jpg. Being that badadvert.jpg should not exist on the pi-hole device, lighttpd will then return a 404 page, which is the block page (/var/www/html/pihole/index.php)
Thanks for your response. I do believe that the above can work on the contrary.
Help me please to understand if the following SHALL NOT WORK
For requests made via HTTP:
http://advertisingdomain.com/badadvert.jpg
and thats what you mean right, cannot resolve to,
http://[address of pihole device]:2086/badadvert.jpg
For requests made via HTTPS:
https://advertisingdomain.com/badadvert.jpg
and thats what you mean right, cannot resolve to,
https://[address of pihole device]:2087/badadvert.jpg
Its just the question of configuration, right?
PS: I have used the Cloudflare default proxy ports mentioned above.
We are a very small team and our user base continues to grow, increasing the ratio of developers to user's feature requests. [quote="SunderRaj, post:4, topic:3145"]
I now take promise to make one installer on this feature request above and publish the code on Github, if the number of votes are insufficient.
[/quote]
To second @PromoFaux, pull requests are the best way to get something implemented because we can review the code and merge it. Pi-hole is open source and meant to be improved upon, which is also how it has grown beyond its humble roots.
I feel like pihole could easily make use of vlan (two ip addresses for one interface)
I have pihole fully running on 192.168.1.99
and nginx on 192.168.1.100
Hey, you could also have one thousand pi-Hole running on the same instance or device on different ports and anathor one thousand nginx instances on different ports.
Thats the charm of linux!
Now to use internationally accepted ports for all standard services is like creating a problem and sitting down to solve it. Because the problem is - BY USING STANDARD PORT 80 - created, the poster requested to have a detection of existing webservers during the installation.
Thus, you see, the request relates to detection of a problem because it may exists due to its use of a standard port.
Pi-Hole shines.
But Pi-Hole remained as a shining diamond in a cave.
Unfortunately, the way how it has been developed is quite interesting: It should be used in home network.
I strongly believe that the developers have now a compelling requirement to bring this shining diamond out of the cave and hang it in the datacenters of this dirty world. They urgently need to develop it in this direction with all kind of logic, which is now missing. This cannot really happen until a brainwash is through.
To use https or check of existing occupied ports is nothing but a result of an architecture that has grown up based on a burning need of home users. But this has to go beyond that now...
The thing is, the client is going to request port 80 (or port 443 if https). Every time.
The heart of Pi-hole is dnsmasq, the only thing it is going to respond to the client with is the IP address. So if a client requests http://doubleclick.net, dnsmasq will return the IP address of the Pi-hole machine. If the client requests a non-ad domain, then dnsmasq will return the real IP address.
Once the client has this IP address, it will then make a standard HTTP request to that IP address. Without making configuration changes to the client to change this behaviour (which really is far from ideal), there is no way to redirect the request to another port.
Pi-hole is designed to run on a home network, preferably on a dedicated device hanging off the router, be that a Raspberry Pi, another SBC, a VM, or even a full blown server. I would not like to imagine the cost of using a raspberry pi as a proxy server for an entire network's worth of traffic. It just wouldn't be up to it.
If I'm missing something obvious here, please explain it to me. But watch the tone.
That is completely irrelevant. The concept of pi-Hole is - and cannot be - based on which port the inbound connection to the interface is made but based on the local search of FQDN in the ASCII file. If not found, it is forwarded.
Thereafter, the duty of lighttpd comes into force. With it, you could do what you want.
In both these cases, the trigger is only the IP. Thereafter, and I hope I understand the concept correctly, lighttpd is triggered in an event when a diversion is required.
At the time of this diversion, your argument of "the client is going to request port 80/443" is already lost!
At the point of this diversion, you can do what you want with lighttpd and play with all kinds of games. You can put into config of lighttpd any other port to use it for error generation or a redirection.
Thus, this is the workflow:
workstation.html:80 ---> FQDN-blacklist.txt ---> lighttpd.conf ---> error.html:2086
workstation.html:443 ---> FQDN-blacklist.txt ---> lighttpd.conf ---> error.html:2087
Do you agree with the above workflow?
Yes. But thats only a reason why the service lighttpd is triggered. After the service process is invoked, you work with lighttpd, right?
You see a bit restrictive of its use from the point of view of Raspberry Pi. To run that lovely little toy, the developer team have designed extraordinary php scripts. Very good. But these php scripts could have a fantastic application also in a different settings, which may not be a Raspberry Pi.
Thus, I am advocating its use beyond the original intention and suggest to extend it. No more and no less.
The difference between us is that I see its use far more beyond and thats irrespective of Raspberry Pi whereas you see it predominantly from that perspective, while acknowledging ithe fact of its use in other cases. Am I right here?
I would suggest at this point that you fork our project and develop it as your own. It's licensed under the EUPL and you would need to fully understand the weight that carries. Good Luck to you and please understand that any software developments or change will need to be supplied to us as the parent project to be in full compliance with our license.
Thanks for your feedback. I understand things here all the more. Just to let you know: There is no reason to go for a fork of any kind. There exists a marvelous software here, which is at the moment not very helpful to me, but has similar conception mentioned:
I would ask that you not come in to our house and advertise other projects and products. That's really disrespectful to us as a team and to our users.
No, I do not. It is dnsmasq that queries the blacklist and makes the decision as to which IP is returned (either from the upstream, or the IP of the pi) , not lighttpd. No matter how you try and spin it, the client is always going to request [IP address provided by dnsmasq]/somecontent.
Something needs to be listening on port 80 or 443. In this case, lighttpd. I'm not sure it's even possible to set the 404 redirect to a different port, let alone understand why you would. If a request comes in for content that is not there, then it must return a 404.
What I think you are suggesting is that we should infact redesign Pi-hole as a proxy service, rather than just a DNS service. Am I correct in that assumption?
Dear Mr. Schaper,
In the last 20 years of my activity on the internet, you are the first person to declare to me that mentioning an open source non-commercial project is showing disrespect to anathor open source non-commercial project.
There is nothing in my messages above that shows any kind of disrespect to any one of the developers of this project pi-Hole. On the contrary. It is very common in the internet community, at least from my past experience, to mention an open source non-commercial project that already exists.
I had - of course - no reason to mention this project here at all. I did that only as an answer to your suggestion to me "Make a fork on the concept you suggest".
The fact that I got interested to use pi-Hole already shows my respect and the interest in the work done by the developers of pi-Hole, right? What does my supportive approach to pi-Hole development tell you, did I disrespect or respect the work done by the team? In fact you developers could also have a look into that project and find some inspiration to develop some thing interesting and deviating from it, or even something similar as a variation. Hence, I see it as a constructive mention.
The right thing is that you, the team, this community is proud of the work done on pi-Hole. The same applies to all the open source non-commercial projects. Pi-Hole is also mentioned in so many forums of other such projects and none would find it wrong.
Indeed, you wrongly interpreted my intention to mention the open source non-commercial project above.
Hello PromoFaux,
No, I actually did not really mean Pi-hole as a proxy service. Excuse me for this misunderstanding, if I used wrong arguments.
If I understand the concept of pi-Hole scripts correct, it is a kind of routing method of data streams at DNS level that either allows or blocks a connection.
If an event of blocking is triggered, then it invokes lighttpd service.
The initial communication began with 53 port. However, pi-Hole causes a block on a http port on the workstation, which could be any port really, while acting as an intermediatory agent.
Thus, instead of the data streams coming from the website that is blocked, pi-Hole does this wonderful job to generate a small webpage from its local installation /var/www/html/index.html.
After you explained me, I will now investigate if one could tweak lighttpd.conf and have a webpage generated on any port and not stick to port 80 or 443. After all, these ports are configured somewhere for the service to act on it accordingly.
With your arguments, however, you are successful to make me "unsure" in this regards, especially on my thoughts on data streams at the ports. I did use it before 5-7 years. So I really know very little the lighttpd services now. Let me make some testing and play with configuration to make my suggestion to me clear, of course in the light of what you explained very good.
If I can find something interesting, on what I meant or thought, I will let you know.
This would be really appreciated. I'm looking forward to learn a possible way of settings things up w/o hard binding to these standard ports. Let me, however, shortly explain why I don't think that this is possible. Please forgive me for being very detailed here and explicitly mentioning things that are obvious, but I think it helps the flow of the argumentation to write sown everything at least once in a very detailed fashion.
Let's assume I request a blocked page called www.bad.com and the IP address of the Pi-hole is 10.0.0.1:
gethostbyname()./etc/hosts) and will eventually query the Pi-hole DNS server10.0.0.1) since the address is blocked by one of the blocking listshttp://10.0.0.1 (resp. https://10.0.0.1 if you explicitly asked for https://www.bad.com)10.0.0.1Hence, I see no way of having the blocking page be shown if there is nothing that is listening on port 80 (resp. 443), as - using the DNS protocol alone - we can only return an IP address but n port information (even if we could do it, the OS wouldn't support returning it to the browser as the standard and hence the operating system implementations do not include this possibility).
Hello PromoFaux and DL6ER,
Until I have a final solution, I am "not going" to disagree to both of you. Because both of you opposed to my opinion, I am now at the set back until I can prove the opposite. Now, I am only going to share my opinion. When I have a final working solution, I will proceed to make a pull request.
So, please allow me to express my opinion to show where and why I disagree to both of you.
In the above steps mentioned by DL6ER from 1 - 6, that part I agree.
Between the step 6 - 7, DL6ER has gulped something very important here:
The control of data streams on the server.
This can only be true, if and only if the following conditions are true:
A. If a default port 80 is defined in the lighttpd.conf.
B. Port 80 is not defined in the lighttpd.conf. (You can happily remove it!)
Then, lighttpd will default to port 80. Why? Because it is hard-coded in the binaries.
It is your decision to define the port for lighttpd services. If you want to have lighttpd daemon to generate a page on port - for e.g. 2096 - here, then configure it. With this, you override the internal default port 80.
I can produce a block page for a blocked domain - manually - on any port you tell me.
However, what I do not know is to connect the data streams between dnsmasq and lighttpd. This, I could only if I study the pi-Hole php scripts. Then I may know how these data streams are captured and how they could be compelled to generate on any port.
Once that is done, then one could really have a dedicated daemon lighttpd for pi-Hole. THATS GOING TO BE EXCELLENT, RIGHT? Thereafter, no checks for any web servers are required, which the poster of this thread wanted. He posted to address the problem because it is caused. I give a solution not to eradicate the problem but to eradicate the root cause of this problem fundamentally.