nginx: access log control while maintaining internal redirection to WordPress

Jan-Philip Gehrcke asked:

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.

The 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?

Thanks!

My answer:


You should use a named location for requests destined for WordPress. An example of this:

location ~ .php$ {
    try_files $uri =404;

    fastcgi_ ### fastcgi params and other config for PHP go here
}

location @wordpress {
    try_files $uri /index.php;

    fastcgi_ ### fastcgi params and other config for WP go here
}

location / {
    try_files $uri $uri/ @wordpress;
}

location /health_status {
    access_log off;
    try_files $uri $uri/ @wordpress;
}

This example is incomplete and may be insecure; it only demonstrates how your issue may be resolved. Be sure to secure your web server properly.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.