> On Aug 23, 2016, at Aug 23, 5:43 PM, Jakov Sosic <jso...@gmail.com> wrote:
>
> Hi guys,
>
>
> Later I log it in Apache in custom log format:
>
> LogFormat "%a %l %u [%{%d/%b/%Y:%T}t,%{msec_frac}t %{%z}t] \"%r\" %>s %b
> \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Unique-ID}i\"" combined_uniqueid
>
>
> But, lately I've notice - very rarely but still happened, a request which
> logged two unique ids.
>
> After verfying ips and ports, I conclude that first request has:
>
> SRC: 192.168.50.200 [client_ip]
> DST: 192.168.50.99 [haproxy_ip]
>
> second one though, has:
>
> SRC: 192.168.50.99 [haproxy_ip]
> DST: 192.168.50.99 [haproxy_ip]
>
>
> An example:
>
> [Fri Aug 19 12:20:13.468461 2016] [-:error] [pid 9390] [client
> 192.168.1.99:53393] [request_id:
> C0A801C8:DE3E_C0A80163:0050_573D9359_39BE5:6408,
> C0A80163:CBB9_C0A80163:0050_573D935C_39BE8:6408] .....
>
>
> Any ideas what could have happened over here?
>
Assuming you don’t loop connections through haproxy itself, (backend -> other
haproxy frontend) which is sometimes done for TLS termination and logging
reasons, then I can think of two other options.
Perhaps an eavesdropper / developer setup another proxy to snoop / debug
traffic on your load balancer?
Someone is sending requests with the (X-Unique-Id) header already set. If you
don’t explicitly remove any incoming values, the unique-id-header will add a
new one.
-Bryan
