Disable Port removing on rewrite

Francis Daly francis at daoine.org
Fri Sep 16 17:34:14 UTC 2016


On Fri, Sep 16, 2016 at 02:39:04PM +0000, Schütrumpf, Niklas wrote:

Hi there,

> One NGINX Server listens on port 80, and our router routes port 8081 from outside to port 80 locally.
> On any rewrite NGINX strips the port from the URL. This is the server because I get a connection to the server and then I got rewritten.
> Is there any config entry to disable the port remove on rewrite? I already tried “port_in_redirect off”, without success.

I think that stock nginx does not have a way for this to happen
automatically.

I see three possibilities, with different downsides.

* You could run nginx on port 8081. Then normal things would Just Work;
but your internal requests would need to be sent to port 8081 instead
of the default.

* Since you already rewrite all requests that do not end in /; if you can
confirm that your clients send the name:port in the Host header that
they send, then you could change the rewrite destination to explicitly
include that:

  rewrite ^(.*[^/])$ http://$http_host$1/ permanent;

This would break any clients that do not send the Host: header that you
expect -- possibly that matters; possibly it doesn't. It is not clear
to me how your current config can work -- with the rewrite, no request
will match your ".php$" location. If that is to change, and you have an
enumerable list of "directories" where you want the add-a-slash redirect,
you could create a bunch of explicit "location =" blocks that do "return
301" with $http_host.

* I think that this one does not apply here, but: if there was exactly
one name:port combination that you wanted included in all nginx-generated
redirections, then you could configure nginx like:

  port_in_redirect off;
  server_name_in_redirect on;
  server_name my.domain.tld:8081;

In your case, this does not fit the requirements; if you were to do this,
you would be better off having nginx on port 8081 directly, I think.

* Because that third option does not apply, the other third option is
to write the code, or encourage someone else to write the code, that
will allow nginx to do what you want.

That is probably not a quick process.


All the best,

	f
-- 
Francis Daly        francis at daoine.org



More information about the nginx mailing list