-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Added ability to override proxy listening ports. #1234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
With this change you can have nginx-proxy listen on a different port from the default for HTTP and HTTPS. E.g., LISTEN_PORT=8080 sets the HTTP port listen port to 8080 instead of 80. Likewise LISTEN_PORT_SSL=8443 would use 8443 for HTTPS. This makes HTTP->HTTPS redirection work properly when forwarding a port from a non-priviledged VM (no ports < 1000) to nginx-proxy. README.md is updated with the new variables available for config.
Changed to match the latest in master.
|
This would be a great addition, would probably make sense to squash these commits? Anyways, I am just a passerby that would love this patch. I hope this can get merged soon. |
|
Ohh man, I wish this feature was already built in when I launched my first proxy. I hope your request get's merged soon. |
staukini
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this request locally with it's new function to override the listening ports and it's working well.
From the code-side: still clean and simple code --> nothing to worry about.
So: From my side of view it's ready to merge.
|
i have made an updated docker image with this patch, and set the docker reverse proxy . The docker installed in nas in a private lan. The proxy listing ports are 8080( http) and 8443( https) , I can access the website using an public domain name through dmz of the router which has a public IP address. All works fine. |
|
This PR is wrong. The container(s) in all docker environments should always listen on their default ports(80:443 in this case). But then, the external mapping, would be updated. Like so: docker run .... -p 8080:80 8443:443 ... |
|
@eigood, you may have missed this part of my comment in the PR or perhaps I didn't emphasize it enough:
If you're using SSL nginx-proxy handles http->https redirects for you with rules it creates in the nginx config. If you just use docker port mappings, the configuration will still refer to ports 80 and 443. So, the redirect will end up going to 443 even if you hit the http page on 8080 (using the docker port mapping). This solves that issue by changing the container to use the specified ports rather than just using port mappings. That was the whole purpose of this PR. An alternative solution would be to have the generated config use different port mappings, but that seemed more complicated to me. I edited the PR description to try to more clearly specify the intent. The edits I made in the readme say this which I was hoping clarified the intent in there:
Cheers, |
|
This PR has been adapted in #1662, closing |
With this change you can have nginx-proxy listen on a different port
from the default for HTTP and HTTPS. E.g., LISTEN_PORT=8080 sets the
HTTP port listen port to 8080 instead of 80. Likewise
LISTEN_PORT_SSL=8443 would use 8443 for HTTPS. This makes HTTP->HTTPS
redirection work properly when forwarding a port from a non-priviledged
VM (no ports < 1000) to nginx-proxy.
README.md is updated with the new variables available for config.
NOTE: To clarify, the entire reason for this feature is to allow proper automatic http->https redirection when nginx-proxy can't be bound to the standard 80 / 443 ports for http / https. Simply using docker port mapping (e.g., -p 8080:80 -p 8443:443) will properly map traffic onto the non-standard ports. But, the http->https redirection will use the standard ports. E.g., hitting http://someurl:8080 will end up redirecting to https://someurl with port redirection whereas it will hit https://someurl:8443 with this change (assuming you use 8080 and 8443).