How to follow request path within the config?

[B.R.]

I would use a return 200 directive to print variables in the location
context to make sure I make nginx search for existing files.

location / {
     return 200 "cache_path$uri\n$uri\n$uri/";
}

If anything printed is not a valid file then you know why you end up with
the fallback value.
---
*B. R.*

On Sat, Nov 8, 2014 at 3:17 AM, cachito <nginx-forum at nginx.us> wrote:

> Hello, I'm hitting my head against a wall since a couple days ago. Last
> paragraph has the big question, the rest is context.
>
> I run a fairly big Wordpress blog, with a somewhat convoluted configuration
> rewriting legacy URLs that follow me since 2002. I use extensive caching
> via
> plugins that pregenerate HTML on disk and I rewrite requests to serve HTML
> instead of talking to PHP. Everything worked well until a domain change.
>
> Yesterday after I replaced the domain in the various configuration files,
> nginx started sending every request to the PHP processor. The location / is
> pretty standard:
> location / {
> try_files cache_path$uri $uri $uri/ /index.php;
> }
>
> Everything in the paths exists and has the correct permissions, but nginx
> keeps sending everything through /index.php and killing my server via a
> 180-200 load average.
>
> I tried everything googleable, but I can't detect WHY nginx goes that
> route.
> The debug log shows a lot of not matching rules/regexes but there's nothing
> I can do to follow the decision tree that nginx follows to end in PHP. Is
> there anything I can do to at least simulate the directive processing?
>
> Thanks in advance.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,254690,254690#msg-254690
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20141108/1627097b/attachment.html>