# Feature I'd like to see

**URL:** <https://www.ruby-forum.com/t/feature-id-like-to-see/189620>\
**Category:** NGINX\
**Created:** [June 4, 2010, 1:26am UTC](https://www.ruby-forum.com/t/feature-id-like-to-see/189620 "2010-06-04T01:26:54Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![xgdlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/838e76/32.png) [@xgdlm](https://www.ruby-forum.com/u/xgdlm)\
**Post date:** [June 4, 2010, 1:26am UTC](https://www.ruby-forum.com/t/feature-id-like-to-see/189620/1 "2010-06-04T01:26:54Z")

</div>

Hello

A feature I’d like to see is the ability to use the “include” directive  
in an upstream block

something like

upstream proxy3011 {  
include “proxy.conf”;  
}

using a proxy.conf like

server 192.168.0.1 max\_fails=5 fail\_timeout=10s;  
server 192.168.0.2 max\_fails=5 fail\_timeout=10s;  
server 192.168.0.3 max\_fails=5 fail\_timeout=10s;  
server 127.0.0.1 backup;

why ?

At the moment I have a bunch of upstream block using all the same  
configuration  
so adding or removing a server from the list is quite painfull.

Why do I use a bunch of upstream block using the same configuration, for  
one reason:  
Using a single upstream block is quite dangerous in my case. If one  
application fails then one or more server are set inoperative  
for all the application using this upstream. Using one upstream for each  
application solves this issue

What do you think ?

Regards,

xav

---

<div class="post-metadata">

**Author:** ![xgdlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/838e76/32.png) [@xgdlm](https://www.ruby-forum.com/u/xgdlm)\
**Post date:** [June 4, 2010, 4:31pm UTC](https://www.ruby-forum.com/t/feature-id-like-to-see/189620/2 "2010-06-04T16:31:52Z")

</div>

On Thu, Jun 3, 2010 at 4:25 PM, xgdlm [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> using a proxy.conf like  
> so adding or removing a server from the list is quite painfull.
> 
> Why do I use a bunch of upstream block using the same configuration, for one reason:  
> Using a single upstream block is quite dangerous in my case. If one application fails then one or more server are set inoperative  
> for all the application using this upstream. Using one upstream for each application solves this issue
> 
> What do you think ?

The same “problem” that you are describing can be solved with say  
[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com · GitHub](http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream) while  
keeping one upstream block.

> Regards,
> 
> xav
> 
> * * *
> 
> nginx mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [mailman.nginx.org archive](http://nginx.org/mailman/listinfo/nginx)

–  
python/django hacker & sys admin  
[http://almirkaric.com](http://almirkaric.com) & [http://twitter.com/redduck666](http://twitter.com/redduck666)

---

<div class="post-metadata">

**Author:** ![xgdlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/838e76/32.png) [@xgdlm](https://www.ruby-forum.com/u/xgdlm)\
**Post date:** [June 4, 2010, 5:23pm UTC](https://www.ruby-forum.com/t/feature-id-like-to-see/189620/3 "2010-06-04T17:23:58Z")

</div>

Hello

Le 4 juin 2010 à 16:30, Almir K. a écrit :

> The same “problem” that you are describing can be solved with say  
> [GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com · GitHub](http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream) while  
> keeping one upstream block.

In my case if I setup a single upstream like this for instance :

upstream guinicorn {  
server 192.168.0.171 max\_fails=1 fail\_timeout=10s;  
server 192.168.0.172 max\_fails=1 fail\_timeout=10s;  
server 192.168.0.173 max\_fails=1 fail\_timeout=10s;  
server 192.168.0.174 max\_fails=1 fail\_timeout=10s;  
server 192.168.0.175 max\_fails=1 fail\_timeout=10s;  
server 127.0.0.1 backup;  
}

and then I use it for multiple app

* * *

server {  
location / {  
proxy\_pass [http://gunicorn:3000](http://gunicorn:3000);  
proxy\_next\_upstream error timeout invalid\_header http\_500 http\_502  
http\_504;  
}  
}

server {  
location / {  
proxy\_pass [http://gunicorn:3001](http://gunicorn:3001);  
proxy\_next\_upstream error timeout invalid\_header http\_500 http\_502  
http\_504;  
}  
}

## server { location / { proxy\_pass [http://gunicorn:3002](http://gunicorn:3002); proxy\_next\_upstream error timeout invalid\_header http\_500 http\_502 http\_504; } }

if one of this app fails badly in five request all the upstream servers  
are set inoperative.  
The behavior I noticed (few years ago, may be this has changed) is that  
all the app  
using this upstream will be using the backup server. So if one app  
fails, the other fails to.

May be this behavior has changed, but now I create an upstream for each  
app and I never had the problem again.

xav