Redirection problem again in new rules.

Francis Daly francis at
Mon Apr 18 23:23:31 UTC 2016

On Mon, Apr 18, 2016 at 06:37:59PM +0500, Muhammad Yousuf Khan wrote:

Hi there,

> Thanks alot Francis Daly :). the try_file option worked for me and location
> tip also worked but try_file seems more better approach.

I'm glad you got it working for you.

> Btw, can you please explain this paragraph. actually i am really sorry for
> this newbie type question. actually i have been working as ssytem admin for
> last 5 years. now my Firewall concepts of rules are collapsing with nginx
> rules.

No worries - nginx config follows its own rules, which are generally consistent but not necessarily the same as any other program.

> >location /x { rewrite ^ /x.html redirect; }
> >fails because "location /x" will match /x.html, so the second request
> >will match the same location as the first one and the same redirect will
> >happen again; and one way to avoid the loop is to make the "location"
> >only match exactly "/x".
> >Based on that, can you guess what the "~" in
> can you please explain how the second request creates the loop. if i use
> break instead of redirect?

I don't understand the question.

What break, and what loop?

I thought you had said that when you used "break" instead of "redirect"
in the above "location /x", you got a 404. And that is what I would
expect if the file $document_root/x.html does not exist. 404 is not a loop.

Can you start with one specific configuration, and use the documentation
(probably at, since that seems to be the
troublesome one) to work out what will happen?

Note: when a request arrives, the server-level "rewrite"-module directives
(basically: if and rewrite) are used; if that does not complete the
request, then the location is chosen, and the "rewrite"-modules directives
in that location are used.

If a "rewrite" leads to an external redirect, that completes the
request; and the browser may then come back with a whole new request
that is handled afresh.

If the "rewrite" leads to an internal rewrite (to a new url), then the 
"subrequest" of the new url is handled according to the docs -- possibly
with a whole new selection of the location to use, depending on the
arguments given to the rewrite.

So: show your (simplified, but complete) config; show your http request;
show your http response; and if appropriate, describe the response that
you wanted to get instead.

"break" does exactly what it says in the documentation. If that is
unclear, let's fix the documentation.

Francis Daly        francis at

More information about the nginx mailing list