NginxProxyManager / NginxProxyManager/nginx-proxy-manager
How to deal with bind issues with default/standard ports - New Ports?
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 34.2k
- Forks
- 3.9k
- Avg merge
- 21h 12m
- Merged PRs (30d)
- 20
Description
Is your feature request related to a problem? Please describe.
With so many ports and different set ups in use out there - and by looking at the number of related support issues raised - people are often faced with bind issues whenever I’m setting up containers that n want to use more of the default network setting.
Is there a way for NPM to better handle that..
If I simply try the quick start guide on my QNAP NAS, it instantly has an issue with port 443 (see below). - For a quick start guide if would be great if there was a very low likelihood of an error being encountered..
Failed to create application "npm". Error message: operateApp action …. Error response from daemon: driver failed programming external connectivity on endpoint npm-app-1 (18dae2dcc7eee4f9348dcc89824df962d8d62d60f1148ec79795521854a587fc): listen tcp4 0.0.0.0:443: bind: address already in use
Describe the solution you'd like
In situation where someone is only trying to access other docker containers, can NPM make use of its own ports and remove their emphasis on the defaults ? I appreciate it might require a new port exposed but it would be one dedicated and monitored by NPM?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the quick-start guide and the Docker port mappings used by NPM, using the reported QNAP bind failure on port 443 as the concrete case. Define what alternative-port behavior should support for containers accessed through NPM, and consider the issue complete only when that behavior and its documentation are agreed and verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100