# Service Unavailable Intermittently (HTTP Proxy)

**URL:** <https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555>\
**Category:** Help!\
**Created:** [June 1, 2018, 1:44pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555 "2018-06-01T13:44:01Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [June 1, 2018, 1:44pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/1 "2018-06-01T13:44:01Z")

</div>

Hi,

I’ve configured HA Proxy as the load balancer for a couple of Symantec proxies on the back end. Generally everything is working correctly, but I’m intermittently seeing issues with some websites. One being Twitter and the other one What’s App.

Looking at Twitter, when not working, the following URL does not load, [https://twitter.com/push\_service\_worker.js](https://twitter.com/push_service_worker.js), but displays a 503 error. Whether the site loads or not, I’m seeing exactly the same request headers, see attached.

![error](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/1X/419c5132296a26a8e461c3573a9fe1a30533efd2.PNG)

If I point the browser to any of the proxy servers on the back-end directly, this error does not occur. I’ve verified this with multiple browsers.

Just wondering what else I can do to trace what is happening here? A basic tcpdump on the haproxy server, shows the request does reach the load balancer.

Thanks for any help.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [June 1, 2018, 2:05pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/2 "2018-06-01T14:05:21Z")

</div>

Check haproxy logs and get take a look at the request that fails.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [June 1, 2018, 2:25pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/3 "2018-06-01T14:25:54Z")

</div>

Thanks. I did a full tcpdump capture and found the request dropped as the user was not authenticated. So it looks like NTLM stops working.

My config is as below. Should I be using ‘option http-keep-alive’, rather than ‘option http-tunnel’ with NTLM? Do these options need to be set on the front-end **and** back-end?

> frontend Proxy\_Front  
> mode http  
> bind 192.168.1.10:3128 transparent  
> option httplog  
> option http-tunnel  
> default\_backend Proxy\_Back
> 
> backend Proxy\_Back  
> balance source  
> hash-type consistent  
> server proxy1 proxy1:3128 check maxconn 3000  
> server proxy2 proxy2:3128 check maxconn 3000

Thanks again.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [June 1, 2018, 5:02pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/4 "2018-06-01T17:02:27Z")

</div>

Both should work. But actually if you are just load-balancing between to outgoing proxy-servers you may as well TCP-load-balance (mode tcp). You can’t really use any HTTP features anyway so you may as well just load-balance actual TCP connections.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [June 4, 2018, 8:44am UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/5 "2018-06-04T08:44:29Z")

</div>

With TCP mode, I would get random login prompts, whereas with HTTP mode this doesn’t happen.

Do ‘http-tunnel’ and ‘http-keep-alive’ need to be set on both the frontend and backend?

Documentation is a bit confusing, as some places suggest ‘tunnel’ mode is required for NTLM, while others say to use ‘keep alive’.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [June 4, 2018, 10:24am UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/6 "2018-06-04T10:24:59Z")

</div>

It’s either http-tunnel or http-keep-alive. By configuring both one will overwrite the other.

Actually, all 3 modes (tcp mode, http mode with http-tunnel and http mode with http-keep-alive) should work with NTLM. However, because NTLM is such an fragile, non-standard and crappy protocol, the actual behavior may depend on additional factors like client and backend server behavior.

Can you post the output of `haproxy -vv` just to check if you are running into any known bugs on the haproxy side?

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [June 7, 2018, 1:14pm UTC](https://discourse.haproxy.org/t/service-unavailable-intermittently-http-proxy/2555/7 "2018-06-07T13:14:56Z")

</div>

> [@lukastribus](#):
>
> either http-tunnel or http-keep-alive. By configuring both one will overwrite the other.
> 
> Actually, all 3 modes (tcp mode, http mode with http-tunnel and http mode with http-keep-alive) should work with NTLM. However, because NTLM is such an fragile, non-standard and crappy protocol, the actual behavior may depend on additional factors like client and backend server behavior.
> 
> Can you post the output of `haproxy -vv` just to check if you are running into any known bugs on the haproxy side?

Sorry for the delay, output of the command below.

I’m wondering if this issue could be related to the proxy servers on the back end, not seeing the client IPs, it’s only seeing the proxy server’s IP.

> HA-Proxy version 1.8.8 2018/04/19  
> Copyright 2000-2018 Willy Tarreau [willy@haproxy.org](mailto:willy@haproxy.org)
> 
> Build options :  
> TARGET = linux2628  
> CPU = generic  
> CC = gcc  
> CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-unused-label  
> OPTIONS = USE\_ZLIB=1 USE\_OPENSSL=1 USE\_PCRE=1
> 
> Default settings :  
> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> 
> Built with OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> Running on OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> OpenSSL library supports TLS extensions : yes  
> OpenSSL library supports SNI : yes  
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2  
> Built with transparent proxy support using: IP\_TRANSPARENT IPV6\_TRANSPARENT IP\_FREEBIND  
> Encrypted password support via crypt(3): yes  
> Built with multi-threading support.  
> Built with PCRE version : 8.32 2012-11-30  
> Running on PCRE version : 8.32 2012-11-30  
> PCRE library supports JIT : no (USE\_PCRE\_JIT not set)  
> Built with zlib version : 1.2.7  
> Running on zlib version : 1.2.7  
> Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)  
> Built with network namespace support.
> 
> Available polling systems :  
> epoll : pref=300, test result OK  
> poll : pref=200, test result OK  
> select : pref=150, test result OK  
> Total: 3 (3 usable), will use epoll.
> 
> Available filters :  
> [SPOE] spoe  
> [COMP] compression  
> [TRACE] trace