Add Nginx Reverse Proxy guide for Pi-hole v6#1379
Conversation
- Add Debian to list (tested on 12 and 13 releases) - Add command to exit the python virtual environment - Sort commands for running the server, exit and entering back in the venv Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
Add the parameter to the command to automatically update the documentation whenever a change is detected in the local files Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
Documentation of the Nginx Proxy configuration process for the new Pi-hole v6 architecture. The guide covers HTTP/HTTPs ports management, WebSocket proxying, SSL/TLS management, and optional advanced authentication layers like Basic Auth and mTLS. Each step has been verified through multiple test runs to ensure a reliable implementation. Special attention was given to security hardening, favoring modern cryptographic standards and high-strength configurations over legacy defaults. Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
✅ Deploy Preview for pihole-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
CI test are failing |
|
mmm strange. Not to meme the usual phrase but "on my machine it works" ahah... I mean, running |
darkexplosiveqwx
left a comment
darkexplosiveqwx
left a comment
There was a problem hiding this comment.
- I don't think the "Additional Pre-Authentication" belongs here. IMO it would be better to link to the nginx documentation for this.
I think the guide should only cover Pi-hole specific configuration needs for setting up nginix and not optional nginx features that dont have to do anything specific with Pi-hole. - How familiar are you with Pi-hole's web setup yourself?
And did you use AI to write this? Some sections that smell like AI: "Using Nginx is not just about redirection or SSL; it unlocks professional-grade features that go beyond the native capabilities of Pi-hole:" Additionally, some workings of Pi-hole seem to have been guessed and can easily be verified as false. - One of those being the use of WebSocket. Pi-hole v6 does not make any use of WebSocket. If you were to look in the Network tab of your browser, you will find regular HTTP requests for the live updates. The embedded webserver also has WebSocket disabled at compile time:
$ pihole-FTL -vv
[...]
****************************** CivetWeb *****************************
Version: 1.17 (modified by Pi-hole) with mbed TLS 4.0.0
Features: Files: Yes, TLS: Yes, CGI: No, IPv6: Yes,
WebSockets: No, Server-side JavaScript: No
Lua: Yes, Cache: Yes, Stats: No, Compression: No
HTTP2: No, Unix domain sockets: No
- You are saying "we will restrict via built-in Access Control List (ACL) its web interface to listen only on the local interface (127.0.0.1)"
Listening on localhost is different than binding to an interface, with your configuration, Pi-hole would still be listening on the wildcard(0.0.0.0) address. Instead of using ACL, you can bind to localhost only. This would be done with:
sudo pihole-FTL --config webserver.port 127.0.0.1:8053"- You mention that one can disable the HTTPS port in Pi-hole if they like, but this will conflict with your idea to use the X.509 certificated generated by Pi-hole. FTL will only refresh the certificate if its own HTTPS port is enabled. I think you should stop using the certificate generated by Pi-hole in nginx.
- The PR description says "Each step has been verified through multiple test runs to ensure a reliable implementation", what tests did you run exactly?
|
@darkexplosiveqwx thank you very much for the deep/complete review! Im getting crazy with CI Test block about format, but I try to reply as better as I can.
Honestly I have find even posts on discourse talking about "basic auth", and even author/contributor (apologize, Im not practice with the team) DL6ER seems generated a dedicated feature for the basic auth](https://discourse.pi-hole.net/t/http-basic-authorization-header-support/65956/5). Talking about settings Nginx, I find out it is usefull to cover all - most discussed/requested - topics. Because it is another way to implement a "auth gateway" and far more secure than discussed "basic auth", I think it is related to the Nginx proxy.
I use pihole by many years, but V5; I have lately updated to V6 and I had to debug all issues, looking around internet so I have find out useful to document them cause some of them was tough to find out the root cause.
Yes I used the support of AI for the english, cause Im not a native english speaker and I ask AI to review the sentences, but they reflects my thoughts. I took over a week to write everything and document and test in a dedicated environment, so at least the review of english it has been quite useful. As for example, Nginx can handle multiple services and it become easy to manage them via a single tool (Nginx) and it has a lot of possible customizations for each specific need.
I would be glad if you may fix those, it would be a really nice contribution.
Oh well, "strange" and good to know! Strange just because something didnt work at the start and googling and searching around I find out that in many scenarios with modern dashboards, websockets are involved and with those line it worked like a charm. So I assumed it was like that; excuse me, Im not a "wireshark master" or skilled enough to dig into that part of compilation, so I didnt play around with Network tab.
Uhm... I have find out "webserver.domain" and "webserver.port" so in my comprehension, 1 is for port and another is dedicate to "domain"; the only way I have see was using an ACL that is usually the proper way to achieve restrictions like that. Further more, I used 8053 for HTTP, but 8054s to keep ssl "active", so I ended up with the command "8053,8054s".
If you have find out some "old" phrase I wrote, please underline it to me; as I said it took me over 1 week, and in the meantime testing and testing, I have review some point, as for example the one about usage of HTTPS of pihole.
At the beginning I had in mind to use a dedicated paragraph about SSL certificate, but later on, digging about the Pi-hole certificate, I discovered it is really well handled, renewed, and it can be used without issues, and without touching anything, so for the end average user it is trasparent. I dont catch the point about your concern. May you kindly formulate it more?
I have brought up multiple times machine from scratch, following the normal installation of pi-hole (the simple bash script with prompt after installation, and from that point on, I have copied pasted each command I have wrote in the guide. At a certain point, where some filename was inconsistent, I have stop read again all the text (even cause, being written by me, I didnt even see error, cause brain doesnt catch them after a certain point). I just concentrated about all commands are correct and the PiHole setup work. Feel free to dont trust and think I wrote it in 5 min with AI 😊 I have spent over 1 week to express of writing, delete, and writing back, to express my gratitude to give back the great -free- work I have received thanks to Pihole during latest years. I understand some people concerned, I dont judge. |
|
I'll try to help you with the CI tests. Start with the list of issues: scroll down to the test results, click on the 3 dots button, then click on "-> View details". 
Read all other error messages and ask for help if you don't understand something. |
|
My first review was a bit harsh, because I really assumed you didn't do your homework properly. (The
While both yubiuser and me are not native speakers of English either, we can help remove some of that obvious "marketing language". For a full review of the quality of English promofaux and danshaper are more qualified.
This should definitively be done. I think the relevant sections can be removed entrirely without much rephrasing.
The ACL is application layer, but the socket binding is at the OS level. I simply prefer socket binding, as it may improve security.
Im referring to:
While using the X.509 certificate generated by FTL may seem simpler, it introduces some problems down the road.
DL6ER is part of the team and the core maintainer of the FTL engine. |
|
@rdwebdesign thank you very much! I ended up installing packages from the CI Test log, the mardown lint-things with npm on a live machine to just run my local own test and fix, but some of them was a bit strange to me. I come from the ages back of "if you can google it, you can google by yourself" so Im used to do not bother people about those thing, trying to find out solution by myself, so thank you very much for the guidance! Really appreciated! @darkexplosiveqwx no problem! Im used to that nowadays. I completely understand you! AI is a good friend if used with "brain"... but vibecoding is destroying the sector... But dont worry, it isnt my case! So no problem at all! I will review your feedback and try to provide a proper answer to each of your feedback! Thank you! |
As per feedback in the relative Pull Request: - Fixed CI Test error (markdownlint and linkinator); - Removed the content related to WebSocket; - Removed the phrase about the reason to adopt Nginx; - Reworked the SSL topic; - Review the ACL approach; - Added Intermediate Mozilla's security standards Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
|
@rdwebdesign I had the time to finish and review the code, but I ended up in a problem with "special link", cause the title was with &; the only solution (to do not adopt HTML) has been to use "and": @darkexplosiveqwx here the feedback:
|
|
You made some good improvements, looking much better now.
For HTTP/3 I'd be open to add a docs page in another PR myself explaining on how to add a HTTPS recored advertising HTTP/3 to Pi-hole. Edit: AFAIK nginx should preserve them and adding them again would be redundant. |
|
Thanks @darkexplosiveqwx for the so fast review! - I'm already working on another PR to add documentations about contributing on Docs. BTW:
|
|
It's been quite a while since I last used nginx (on Debian 12 before settling on Caddy), now using Fedora 44. DetailsMy nginx doesnt have `/etc/nginx/sites-available/` nor `/etc/nginx/sites-enabled/`. On Fedora the default is:
|
... but now Im running a Fedora VM and testing it 😂 ahahah.... in the end it is just a bunch of command line to apply the configs... I will work about it. Btw I have googled, and it is a common/known issue for Fedora people... So I think I may solve it faster... Thanks for the sharing of files and problem. Im going to fix it. Even if at that point, we should test on Arch too...
As I said, for the moment, HTTP3 is (unfortunately) out of my possible scope.
We may add it in the description, cause not all people are able to do such activities. What do you think?
Oh well, I will remove them 😉 |
I think we can just add HEAD to the list of allowed methods. Its considered a safe HTTP method, as it doesn't change server state, functionally it is just GET but without the body. I don't want to make it complicated.
Yes, I agree on not doing HTTP/3 here. |
Solved 😂 I have removed completely those commands ahahah .... I leave those level of action to the user. If they dont know how to enable/disable a site, it is better they dont use a Reverse Proxy but directly Pi-hole.
Personally Im usually against leaving |
As per feedback in the relative Pull Request: - Standardized SSL/TLS terminology; - Removed the ACL and restart Pi-hole commands; - Removed Headers already handled by Pi-hole; - Added HEAD as allowed HTTP Method; - Rework Nginx commands to resolve cross-distro configuration differences.
|
I think I'm satisfied with the overall shape we worked out, I'll comment on the code now for some continued small improvements. |
| - Restricting access via VPN or IP whitelisting; | ||
| - etc | ||
|
|
||
| **Disclaimer:** Utilizing `Nginx` as a reverse proxy does not automatically guarantee safety against all vulnerabilities associated with internet exposure. This guide focuses exclusively on the generic configuration of `Nginx` as a web proxy with some security tips; it does not cover, nor is it intended to cover, the advanced hardening techniques required for public internet exposure. Neither this guide nor the Pi-hole team shall be held responsible for any security breaches, data loss, or damages resulting from your network configuration. |
There was a problem hiding this comment.
This liability disclaimer sounds a bit to strong for me, I'd like to get the opinion of someone else @pi-hole/docs-maintainers.
There was a problem hiding this comment.
I think we should in general not suggest that it is a good idea to expose Pi-hole to the internet. No matter if behind reverse proxy or not.
There was a problem hiding this comment.
Too Strong? .... I placed it especially to cover any possible issue and to underline how exposing the service to internet is a thing that should be done ONLY under the right knowledge... but well, on this point, you guys have green light for me whatever you decide 😊 edit as you wish
There was a problem hiding this comment.
I'm not sure if this phrasing would be good, this is why I checked in
There was a problem hiding this comment.
Too Strong? .... I placed it especially to cover any possible issue and to underline how exposing the service to internet is a thing that should be done ONLY under the right knowledge... but well, on this point, you guys have green light for me whatever you decide 😊 edit as you wish
I was more referring to the "absolutely no liability" part, of which I was unsure about.
The previous one about the dangers is reasonable.
There was a problem hiding this comment.
I was more referring to the "absolutely no liability" part, of which I was unsure about.
The previous one about the dangers is reasonable.
Belong to me, it isnt in any case ("by design") team's accountability for anything done or consequences produced by the software improperly used. This phrase is just merely "repeating"/"underling" something really objectives.
If "my" (AI-revised ahah) english wasnt good, I tried to just discourage people to expose it on internet and (if they do), this guide doesnt cover this scenario - it is up to them; this was my target.
Sorry in case Im misunderstanding you.
There was a problem hiding this comment.
I was comparing it to the warning at https://docs.pi-hole.net/ftldns/interfaces/. Neither exposing port 53 nor 80/443/whatever HTTP(S) is recommended. In my eyes "Neither this guide nor the Pi-hole team shall be held responsible for any security breaches, data loss, or damages resulting from your network configuration." sounds a bit overly defensive, but I am not quite sure on how to proceed. That's why I wanted to get another opinion here.
|
|
||
| 2. **Create the proxy file configuration** | ||
|
|
||
| Place the following file in your `Nginx` configuration path (e.g., `/etc/nginx/conf.d/` or `/etc/nginx/sites-available/` depending on your distribution configuration). |
There was a problem hiding this comment.
I think it'd be useful to tell the user to look for potential port conflicts in server blocks already existing in /etc/nginx/conf, /etc/nginx/conf.d/ and /etc/nginx/sites-available/. Both with Pi-hole and other running services.
There was a problem hiding this comment.
For this topic, I have tried to forecast the possibility and adopted the port 8080 in the config, to prevent possible conflicts for the port 80.
To be honest, I think that this should go a bit under each person custom scenarios. Especially for that I wrote in the Network Mapping & Port Alignment section which port the guide would use, and place attention to it, change according to personal setup.
At the start I wrote the guide as copy/paste, but thanks to your feedback, I rework it as "guidance"; as we said before in the previous interactions, if a person doesn't know what Nginx is or how to configure it, it is way better to use standard Pi-hole feature. This is a "guidance" for people that have knowledge of Nginx and are looking for a "pre-made" base for the Reverse Proxy.
Pi-hole v5 Nginx reverse proxy was a bit more complex due to fastcgi and php... but know it is way easier; I have find out many post, but most of the time, same questions: redirect api? redirect only admin? and so on. So I think we may do not focus extremely too much, because if they skip (important) section of the guide, we can't really repeat 10 times all the sections again... this is my personal point of view.
In case of a fresh install, it is up to the user to configure it wisely. Otherwise it is just used for.... ? In the "marketing phrase" we have removed I tried to underlined how Nginx is just not to be used as "Im cool guy, I have a reverse proxy", cause it adds nothing more than what Pi-hole (v6 especially) already provides. The team did an amazing job improving the internal http web server. Im to give support to test "new technologies", but not so much to "copy/paste" and forget... I wrote sections about possible issues in case of others pre-existing directives, using also "default Nginx value", just because lower value (in custom environment) may break and requires troubleshooting (as I had to do - in a customized nginx environment). So Im not really sure about this point 🤔 (just because I spammed already of warning everywhere in each dedicated sections 😂 it is becoming a warning spam, more than guide for how much I tried to underline to pay attention ahahah)
There was a problem hiding this comment.
Thinking more about "To avoid conflicts with Nginx or other services running on your system, we need to move Pi-hole v6 away from the standard HTTP port (80).", I guess its fine like this.
There was a problem hiding this comment.
Maybe a native speaker @PromoFaux can give an opinion?
|
|
||
| 1. **Create the redirect file configuration** | ||
|
|
||
| Place the following file in your Nginx configuration path (e.g., `/etc/nginx/conf.d/` or `/etc/nginx/sites-available/` depending on your distribution configuration). |
There was a problem hiding this comment.
maybe https://github.com/pi-hole/docs/pull/1379/changes#r3248200476 can go here
There was a problem hiding this comment.
Yeah, I copy/pasted to be consistent in the wording, but is the same thought of before 🤔
Explicit how long 63072000s actually are Co-authored-by: darkexplosiveqwx <101737077+darkexplosiveqwx@users.noreply.github.com> Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
It has been agreed to not affect other subdomains the user might have. Co-authored-by: darkexplosiveqwx <101737077+darkexplosiveqwx@users.noreply.github.com> Co-authored-by: DoctorD90 <DoctorD90@users.noreply.github.com> Signed-off-by: DoctorD90 <DoctorD90@users.noreply.github.com>
darkexplosiveqwx
left a comment
darkexplosiveqwx
left a comment
There was a problem hiding this comment.
Those are spelling/grammar/wording fixes.
Please wait until confirmation from @PromoFaux before applying.
|
|
||
| ### Update Pi-hole's Configs | ||
|
|
||
| You must instruct Pi-hole to stop listening on port 80, 443 or any other ports and switch to our (arbitrary choosen) port **8053**. Additionally, for sake of security, we will restrict its web interface to listen only on the local interface (`127.0.0.1`), ensuring it is only accessible via the `Nginx` proxy. |
There was a problem hiding this comment.
| You must instruct Pi-hole to stop listening on port 80, 443 or any other ports and switch to our (arbitrary choosen) port **8053**. Additionally, for sake of security, we will restrict its web interface to listen only on the local interface (`127.0.0.1`), ensuring it is only accessible via the `Nginx` proxy. | |
| You must instruct Pi-hole to stop listening on port 80, 443 or any other ports and switch to our (arbitrarily chosen) port **8053**. Additionally, for sake of security, we will restrict its web interface to listen only on the local interface (`127.0.0.1`), ensuring it is only accessible via the `Nginx` proxy. |
| ``` | ||
|
|
||
| 3. **Generate the Client Certificate** | ||
| We generate the private key for the user and a Certificate Signing Request (CSR). In real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #3), and in Private PKI environments, we autonomusly sign it with our Private CA. |
There was a problem hiding this comment.
| We generate the private key for the user and a Certificate Signing Request (CSR). In real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #3), and in Private PKI environments, we autonomusly sign it with our Private CA. | |
| We generate the private key for the user and a Certificate Signing Request (CSR). In the real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #3), and in Private PKI environments, we autonomously sign it with our Private CA. |
|
|
||
| 1. **Generate the required Pi-hole SSL/TLS files** | ||
|
|
||
| We generate the private key and a Certificate Signing Request (CSR). In real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #4) we directly self-sign them, or in a Private PKI environments, we autonomusly sign it with the Private CA. |
There was a problem hiding this comment.
| We generate the private key and a Certificate Signing Request (CSR). In real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #4) we directly self-sign them, or in a Private PKI environments, we autonomusly sign it with the Private CA. | |
| We generate the private key and a Certificate Signing Request (CSR). In the real world, we should send the generated CSR to the CA for the signing, getting back the Certificate; in this guide (at command #4) we directly self-sign them, or in a Private PKI environments, we autonomously sign it with the Private CA. |
|
|
||
| ##### Security Headers | ||
|
|
||
| These header can add a layer of protection by instructing the user's browser how to handle the site's content securely: |
There was a problem hiding this comment.
| These header can add a layer of protection by instructing the user's browser how to handle the site's content securely: | |
| These headers can add a layer of protection by instructing the user's browser how to handle the site's content securely: |
| ``` | ||
|
|
||
| !!! danger "Change the PKCS#12 password" | ||
| In this guide, to speed up the command execution, the **weak** password `abcdef123456` has been used; we reccomend to choose a strong password and do not pass it via command line to keep it as secret as possible. |
There was a problem hiding this comment.
| In this guide, to speed up the command execution, the **weak** password `abcdef123456` has been used; we reccomend to choose a strong password and do not pass it via command line to keep it as secret as possible. | |
| In this guide, to speed up the command execution, the **weak** password `abcdef123456` has been used; we recommend to choose a strong password and do not pass it via command line to keep it as secret as possible. |
|
|
||
| !!! tip "TLS/SSL Installation" | ||
| - **Trust:** You may also need/want to import the `CertificateAuthority.pem` as a Trusted Root CA if it is a private one. Detailed instructions can be found in the [Pi-hole Official Documentation](/api/tls/#adding-the-ca-to-your-browser); | ||
| - **Browser:** Import the `client.p12` file into your browser's certificate manager (Settings > Security > Manage Certificates > Your Certificates); it is similar to precedent point, so you can read the [Pi-hole Official Documentation](/api/tls/#adding-the-ca-to-your-browser); |
There was a problem hiding this comment.
| - **Browser:** Import the `client.p12` file into your browser's certificate manager (Settings > Security > Manage Certificates > Your Certificates); it is similar to precedent point, so you can read the [Pi-hole Official Documentation](/api/tls/#adding-the-ca-to-your-browser); | |
| - **Browser:** Import the `client.p12` file into your browser's certificate manager (Settings > Security > Manage Certificates > Your Certificates); it is similar to the previous point, so you can read the [Pi-hole Official Documentation](/api/tls/#adding-the-ca-to-your-browser); |
|
I know I was only asked for my opinion as a native English speaker, and I appreciate that a lot of work has gone into creating and reviewing this PR however.... Honestly, this submission has "LLM-generated" written all over it, and I think we need to be honest about that before we consider merging it. I appreciate the acknowledgement that AI was used to assist with translation, but as a native speaker, I can tell the LLM has done considerably more than proofread the English, indeed it reads like it was generated, then lightly edited... not written and then polished. The vast majority of this document is a general A guide of this length and scope creates a maintenance burden, will go out of date, and frankly covers things that are already better documented elsewhere on the internet. At the very most, I would expect a guide for this to be much shorter, focussed on what is unique to using the Pi-hole web interface behind But even then, that's pushing it. The guide has a big warning at the top of the doc is effectively saying "DON'T DO THIS", and then spends several thousand words explaining exactly how to do so in elaborate detail. |
About the AI and quality of the guide, I was also skeptical at first, maybe I got too involved now and tried to make it work? I think I get your point, the DNS-related guides like Unbound add a good improvement on-top of Pi-hole's core functionality, DNS, and are more relevant. For that the guide would be fairly simple and very modular: disable FTL's HTTPS, bind to Maybe some tips on how to setup the advanced Edit: Did't want to get too negative again, I'd consider this guide not that bad as a standalone, but I do think that we need to give our final goal with it another thought. Edit2: Regarding |
Indeed - the spirit of the guide is not bad overall (although I don't have the bandwidth to technically verify the content), this is just probably not the right home for it |
Thanks @PromoFaux for your honest feedback. To be honest the only part that I "dont agree" is this one, cause I mainly write it in spaghetti-english with some part fastly written in my native language; instead of translating, I have prompted to follow the context provided and translate and fix, and, for sure, I have read again and again to be sure it was "as I would have written". I know many italian writers/blogger that after the AI era has been "accused" (not this situation, dont worry, I got your point) to use AI just cause they (human writers) used specific characters, or "sofism" that are largely abused but AI... but well, it is their own way of writing - and AI is trained also on those way of writing (Who came first? The egg or the chicken?). It is always so nice in 2026, release a text and end to discuss about the AI adoption 😅 ... What I may say is that I have reviewed it for over 1 week, and it is a bit frustrating as it is ending 😅
About that, the guide underlines to do not think "hey, this states it is secure! let's adopt it to expose over internet"... that was my intent and object. Sad it wasnt clear enough.
Yeah, I completely agree with you. I may have spend 10 mins (even without AI) to just drop the minimal configuration and stop, but I was moved by "hey! I use Pi-hole by years, let's try to give back my 5cent at the best I can", so I tried to cover all the topic that I have met on discourse/github/blogs/reddit/etc (problems, redirection, doubts, question about auth, misconfigurations) to provide a solid point of start to all the questions I have faced/find out...In that way I hoped to "solve" many discussions with just link to the official docs. Yes, I agree, cause it is true, I have spend a large amount of time/text about security (cause I consider it really important and Im the type of person that dont like to say "that's the fish, eat it", but I prefer to spend time to explain why this config, and if you dont know it, how to further customize and what to avoid with pihole otherwise ... blabla). It wasnt intended to be just "mTLS, CA, general nginx"; I have spend a lot of text also about configurations that may raise conflicts with Pi-hole (thanks again to @darkexplosiveqwx about websockets for example), and how to solve specific issue connected to Pi-hole. So Im a bit frustrated that those points/parts werent so "clear". That said, if you think that for "Nginx" would be way better the minimal config, and link to the upstream documentation... I dont see problems if this is the direction the team wants 😊 ... even because it is just a "removal of many - many - many block of text with just hyperlinks to some of the tab I have still opened... So if you think this would be better let me know, it is easy to apply :) |
Oh Ive read it just now. Or if you think, we may just deny the PR, no problem at all! Im moved by just the spirit of contributing to a nice projects I ve followed and used since its very own starts and I really like 😊 |
5 participants
What does this PR aim to accomplish?:
Documentation of the Nginx Proxy configuration process for the new Pi-hole v6 architecture. Plus additional small updates to README.md (I've left the respective commits in place to facilitate a quick review).
How does this PR accomplish the above?:
The guide covers HTTP/HTTPs ports management, WebSocket proxying, SSL/TLS management, and optional advanced authentication layers like Basic Auth and mTLS. Each step has been verified through multiple test runs to ensure a reliable implementation. Special attention was given to security hardening, favoring modern cryptographic standards and high-strength configurations over legacy defaults.
By submitting this pull request, I confirm the following:
git rebase)