Allow internal redirect to URI x, but deny external request for x?

Francis Daly francis at
Sat Aug 31 20:50:45 UTC 2019

On Sat, Aug 31, 2019 at 09:10:09AM -0500, J. Lewis Muir wrote:
> On 08/31, Francis Daly wrote:

Hi there,

> >  * starts with /my-app/current/ -> reject
> >  * starts with /my-app/releases/ -> reject

Actually -- those two "rejects" should not be needed.

The app probably should not be installed in the general nginx document
root directory. The "alias" mentioning the "app/current" directory means
that that is the only part that nginx will try to serve files from. The
"root" mentioning the "app/current" directory means that that is the only
part that nginx will look in (try_files) and mention to the fastcgi server

So the "app/releases" directory will not be web-accessible; and the
"app/current" directory will only be accessible by the explicit url that
you define.

So the full config should be of the form

  location ^~ /app-url/ {
    alias /active-app-dir/;
    location ~ \.php(/|$) {
      root /active-app-dir;
      fastcgi_split_path_info ^/app-url(/.*?php)($|/.*);
      try_files $fastcgi_script_name =404;
      include fastcgi.conf;
      fastcgi_pass unix:php.sock;

Adjust regexes based on what you want.

"app-url" can be "my-app". "/active-app-dir" can be "/opt/app/releases/3"
or "/opt/my-app/current" or anything else.

> I changed the root directive to come before the fastcgi_split_path_info,
> but that was just aesthetic; it worked fine the other way
> too.

Yes. For many directives in nginx, the order in the config file does
not matter.

("rewrite" module directives use the order. And regex locations use
their order. I think that most others do not. Your fastcgi server might
care about the order that the fastcgi_param directives had, but nginx
does not.)

>  Previously, I had the fastcgi_split_path_info call in
> php-fpm-realpath.conf along with the following file-exists check after

Using "realpath" should not affect nginx at all. nginx invites the
fastcgi server to use pathname2 instead of pathname1; so the fastcgi
server is the only thing that should care.

> For my current app, it doesn't use those URIs, so it's not a problem,
> but as a general scheme, it's not perfect.  I think one solution would
> be to move the app root directory to a different name so that it can't
> conflict.  For example, have it live at
>   /srv/www/my-app-deployment

As above -- that shouldn't matter. If the app is not deployed in the web
server document root, only the specific alias/root directory is accessible,
and the entire url-space below that is available.

(And you can have one url prefix /my-app/, and a separate url prefix
/my-app-prev/, which uses the next most recent version. Restrict access
to that location{} to your source IP address, and you can do regression
testing between the two.)

> or something like that.  Then I could just return a 404 for any request
> on that, e.g.:
>   location ^~ /my-app-deployment/ {
>     return 404;
>   }

If you don't want nginx to serve content from the my-app-deployment
directory, it is probably easier for it to be somewhere other than

It is hard to misconfigure nginx in that case.


Francis Daly        francis at

More information about the nginx mailing list