Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question

1 Answer 1

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.

share|improve this answer
    
I did not try it yet (will soon). Thanks for your answer so far. Two questions arise: 1) I don't quite get why this should work. Does the internal redirect to a named location keep the access_log setting "active" while an internal redirect to a real location does not? Can you point me to the corresponding documentation? 2) Does your approach in any way affect performance negatively (just out of curiosity)? –  Jan-Philip Gehrcke Sep 21 '12 at 16:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.