URL-Rewriting not working

Francis Daly francis at daoine.org
Sun Apr 9 12:28:54 UTC 2017


On Sun, Apr 09, 2017 at 05:27:31PM +0530, Ajay Garg wrote:

Hi there,

> Unfortunately, our backen-service(s) (on port 2000 in the example) is
> ssh-reverse-tunnel, having two layers of machines behind them. The
> terminating-node for sure cannot be changed.

"In general", reverse-proxying to a different part of the url hierarchy
needs back-end support. In the specific case of your system, maybe it
does not need anything special. Only you can tell.

> Looking at your explanations, I guess then we will have to open a port for
> every service.
> So, for example, port 2001 for proxying to service running on ssh-tunnel at
> 2000,

You could.

Or, you could have nginx listening on public:2000 and proxy_pass'ing
to local:2000, so you don't have to remember the public/private port
mappings.

Or you could have nginx listening on one port, and have multiple server{}
blocks, so that userA connects to A.example.com which proxy_pass'es
to local:2000; and userB connects to B.example.com which proxy_pass'es
to local:2002.

Or, you could (potentially) have nginx listening on one port, with one
server{} block, where anyone who authenticates as userA is proxy_pass'ed
to local:2000 and anyone who authenticates as userB is proxy_pass'ed
to local:2002.

In each of those cases, the reverse-proxying is not to a different part
of the url hierarchy, so the original concern does not apply.

Each case has its own costs and benefits, regarding future maintenance
within nginx and external to nginx. All can work. Only you can decide
which suits you best.

> That brings me to my last question as per
> http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html. If there
> isn't an issue with opening multiple nginx-listening-ports to the public,
> then I guess we are done.

Until you exhaust resources on your system, nginx does not care how many
listening ports it opens.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org


More information about the nginx mailing list