access log control while maintaining internal redirection to WordPress

Maxim Dounin mdounin at
Mon Sep 24 21:20:59 UTC 2012


On Mon, Sep 24, 2012 at 11:11:21PM +0200, Jan-Philip Gehrcke wrote:

> Hello!
> I created a WordPress page with permalink
> http://domain.tld/health_status for WordPress health monitoring.
> It's accessed frequently, so I don't want these requests to appear
> in my access log.
> My basic "rewrite rule" for all WordPress pages is:
> location / {
>     try_files $uri $uri/ /index.php?q=$args;
> }
> Now, on the same level, I tried
> location /health_status {
>     access_log off;
>     #try_files $uri $uri/ /index.php?q=$args;
>     }
> From the nginx location documentation: "Literal strings match the
> beginning portion of the query - the most specific match will be
> used"
> /health_status is more specific than /, so this block takes action
> when I request http://domain.tld/health_status.
> With the `try_files` line commented out (as above), the request does
> not show up in the access log, hurray, but obviously I just get a
> 404 error, because nginx does not redirect this request to
> WordPress.
> With the `try_files` line being active, an internal redirect to
> WordPress' index.php takes place and the /health_status WordPress
> page is shown in the browser. However, after the internal redirect
> the location /health_status block is not in action anymore and the
> request ends up in the access log.
> How to solve this problem cleanly? Do I now have to add another
> block matching the actual /index.php?q=healthstatuswhatever request
> that takes place after the internal redirect?

Correct solution would be actually configure all you want to 
happen in location /health_status.  I.e. disable access log in it, 
_and_ properly handle request there as well.

If you are using fastcgi, something like this should work:

    location = /health_status {
        access_log off;
        fastcgi_param SCRIPT_FILENAME $document_root/index.php;

Similar aproach applies to other backend protocols as well.

Maxim Dounin

More information about the nginx mailing list