# Duplicate the client's requests to another server

**URL:** <https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102>\
**Category:** NGINX\
**Created:** [December 22, 2011, 5:27am UTC](https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102 "2011-12-22T05:27:52Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [December 22, 2011, 5:27am UTC](https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102/1 "2011-12-22T05:27:52Z")

</div>

Hello,

When nginx pass the client’s request to an original server, I want it  
always duplicate the request to another webserver.

For example, the request is following: client -\> nginx -\>  
original-server  
What I want is:

client -\> nginx -\> original-server  
|-\> another webserver

The request should always be duplicated, rather than the round robin.

How can I do that?

Thanks.

---

<div class="post-metadata">

**Author:** ![jeffpritchard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@jeffpritchard](https://www.ruby-forum.com/u/jeffpritchard)\
**Post date:** [December 22, 2011, 7:52am UTC](https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102/2 "2011-12-22T07:52:40Z")

</div>

Jeff,

I can’t think of a (simple) way of doing this through NGINX.

It seems to me that the simplest might be to handle this on iptables  
(are  
you using Linux?) directly by setting up something similar to what’s  
covered here:

[http://www.bjou.de/blog/2008/05/howto-copyteeclone-network-traffic-using-iptables/](http://www.bjou.de/blog/2008/05/howto-copyteeclone-network-traffic-using-iptables/)

so your destination would be some sort of an alias that actually  
represents  
2 destinations.

Would you be able to provide more context about your environment and why  
you are thinking of implementing that?

–  
Unai R.  
CTO & Cofounder  
LeanWired LLP  
Singapore 168977  
[www.leanservers.com](http://www.leanservers.com)  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![jeffpritchard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@jeffpritchard](https://www.ruby-forum.com/u/jeffpritchard)\
**Post date:** [December 22, 2011, 9:04am UTC](https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102/3 "2011-12-22T09:04:21Z")

</div>

On Thu, Dec 22, 2011 at 2:52 PM, Unai R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Would you be able to provide more context about your environment and why you  
> are thinking of implementing that?

Thanks.  
I just need the incoming data to the second server for testing and  
analyzing, since the original-server is in production environment.

All the servers are Ubuntu Linux 9.10 OS.

---

<div class="post-metadata">

**Author:** ![jeffpritchard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@jeffpritchard](https://www.ruby-forum.com/u/jeffpritchard)\
**Post date:** [December 22, 2011, 9:56am UTC](https://www.ruby-forum.com/t/duplicate-the-clients-requests-to-another-server/215102/4 "2011-12-22T09:56:15Z")

</div>

Jeff,

Thanks.

> I just need the incoming data to the second server for testing and  
> analyzing, since the original-server is in production environment.
> 
> All the servers are Ubuntu Linux 9.10 OS.
> 
> * * *
> 
> nginx mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [mailman.nginx.org archive](http://mailman.nginx.org/mailman/listinfo/nginx)

I have never seen/encountered this scenario you are describing. Although  
it  
looks interesting, I’m not sure I understand its benefits. What are your  
trying to achieve? I mean, if you hit an error on production, you will  
have  
to troubleshoot it anyway, right? I guess you can always analyze using  
the  
logs on production.
