# Access log control while maintaining internal redirection to WordPress

**URL:** <https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170>\
**Category:** NGINX\
**Created:** [September 24, 2012, 11:12pm UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170 "2012-09-24T23:12:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [September 24, 2012, 11:12pm UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/1 "2012-09-24T23:12:12Z")

</div>

Hello!

I created a WordPress page with permalink  
[http://domain.tld/health\_status](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](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!

Jan-Philip

---

<div class="post-metadata">

**Author:** ![Jan-Philip\_Gehrcke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/54ee81/32.png) [@Jan-Philip\_Gehrcke](https://www.ruby-forum.com/u/Jan-Philip_Gehrcke)\
**Post date:** [September 24, 2012, 11:21pm UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/2 "2012-09-24T23:21:33Z")

</div>

Hello!

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

> ```
> try_files $uri $uri/ /index.php?q=$args;
> 
> ```
> 
> beginning portion of the query - the most specific match will be  
> 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_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    ...
}

```

Similar aproach applies to other backend protocols as well.

Maxim D.

---

<div class="post-metadata">

**Author:** ![Jan-Philip\_Gehrcke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/54ee81/32.png) [@Jan-Philip\_Gehrcke](https://www.ruby-forum.com/u/Jan-Philip_Gehrcke)\
**Post date:** [September 25, 2012, 10:14am UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/3 "2012-09-25T10:14:44Z")

</div>

Thanks, Maxim! This was helpful.

However, I’d like to discuss the concept a bit further. We’re talking  
about changing only one property for a single location while keeping the  
rest of the configuration constant – a pretty common task I guess –  
shouldn’t there be a more elegant solution?

Cheers,

Jan-Philip

---

<div class="post-metadata">

**Author:** ![Jan-Philip\_Gehrcke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/54ee81/32.png) [@Jan-Philip\_Gehrcke](https://www.ruby-forum.com/u/Jan-Philip_Gehrcke)\
**Post date:** [September 25, 2012, 9:12pm UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/4 "2012-09-25T21:12:49Z")

</div>

Thanks for your opinion, Igor. Would it also be safe to use `include`  
statements for blocks that occur multiple times?

Jan-Philip

---

<div class="post-metadata">

**Author:** ![Jan-Philip\_Gehrcke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/54ee81/32.png) [@Jan-Philip\_Gehrcke](https://www.ruby-forum.com/u/Jan-Philip_Gehrcke)\
**Post date:** [September 25, 2012, 10:38am UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/5 "2012-09-25T10:38:42Z")

</div>

On Tue, Sep 25, 2012 at 10:14:07AM +0200, Jan-Philip Gehrcke wrote:

> Thanks, Maxim! This was helpful.
> 
> However, I’d like to discuss the concept a bit further. We’re talking  
> about changing only one property for a single location while keeping the  
> rest of the configuration constant – a pretty common task I guess –  
> shouldn’t there be a more elegant solution?

My exprience of administrating sites with a lot of locations says  
that it is much better to concentrate complete configuration inside  
location instead of spreading it across whole file.

When you need to add new functionality in the spreaded configuration  
you have to check it whole to see possible conflicts. There are no  
such issues when you add new functionality in configuration with  
completely separated locations given only location prefixes and  
without regexes.

The common objection is that you have to dupclicate many common  
parameters in all these locations. But when you need to change some  
common parameter in many locations, say upstream address, then  
find-and-replace in your favourite editor is your friend. It takes  
far less time to see if a place should be changed or not.

–  
Igor S.

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.

---

<div class="post-metadata">

**Author:** ![Jan-Philip\_Gehrcke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/54ee81/32.png) [@Jan-Philip\_Gehrcke](https://www.ruby-forum.com/u/Jan-Philip_Gehrcke)\
**Post date:** [September 25, 2012, 9:17pm UTC](https://www.ruby-forum.com/t/access-log-control-while-maintaining-internal-redirection-to-wordpress/223170/6 "2012-09-25T21:17:30Z")

</div>

On Sep 25, 2012, at 23:12 , Jan-Philip Gehrcke wrote:

> Thanks for your opinion, Igor. Would it also be safe to use `include` statements  
> for blocks that occur multiple times?

Yes, it’ safe. Although I prefer not to use “include” for this purpose,  
since it complicates the find-and-replace strategy.

–  
Igor S.

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.