# Kibana behind Haproxy : A basepath problem? **URL:** \ **Category:** Kibana\ **Created:** [December 19, 2018, 4:55pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564 "2018-12-19T16:55:19Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [December 19, 2018, 4:55pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/1 "2018-12-19T16:55:19Z")
Hello Everybody, First of all I'm pretty new to the Kibana world and Haproxy. Installation : Centos 7 Haproxy 1.5.18 : installed through yum install haproxy. Kibana : 6.5 latest release. It's an 'In the box configuration' with ES, logstash & Redis. Firewalld stopped. My problem : Kibana doesn't seem to respond as expected. Haproxy Configuration : ``` global log 127.0.0.1 local1 debug chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon tune.ssl.default-dh-param 2048 # Répertoire SSL par défaut ca-base /etc/ssl/certs crt-base /etc/ssl/private ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults log global option httplog timeout connect 5000 timeout client 50000 timeout server 50000 frontend http-in mode http bind 0.0.0.0:80 redirect scheme https code 301 if !{ ssl_fc } frontend https-in bind 0.0.0.0:443 ssl crt /etc/ssl/private/vmrelkoytst.pem reqadd X-Forwarded-Proto:\ https acl acl_kibana path_beg /kibana use_backend kibana if acl_kibana backend kibana mode http option forwardfor option httpchk GET / reqrep ^([^\ :]*)\ /kibana/(.*) \1\ /\2 server relk 127.0.0.1:5601 ``` * * * Kibana Configuration : ``` server.host: "127.0.0.1" server.basePath: "/kibana" server.rewriteBasePath: false elasticsearch.url: "http://localhost:9200" elasticsearch.preserveHost: true ``` * * * Haproxy doesn't make a connexion with Kibana was my first impression, based on the lack of traces in the Kibana log. When I go to the URL [http://myserver/kibana](http://myserver/kibana) I'm correctly redirected to [https://myserver/kibana](https://myserver/kibana) but I'm having these logs. haproxy log : ``` Dec 19 16:00:05 localhost haproxy[7025]: 192.168.39.198:52269 [19/Dec/2018:16:00:05.903] https-in~ https-in/ -1/-1/2 0 SC 1/1/0/0/0 0/0 Dec 19 16:00:05 localhost haproxy[7025]: 192.168.39.198:52270 [19/Dec/2018:16:00:05.903] https-in~ https-in/ -1/-1/2 0 -- 0/0/0/0/0 0/0 Dec 19 16:00:05 localhost haproxy[7025]: 192.168.39.198:52273 [19/Dec/2018:16:00:05.907] https-in~ https-in/ -1/-1/1 0 SC 0/0/0/0/0 0/0 ``` Nothing about connexions in the kibana.log or messages. command lsof -i -nP is giving this : ``` node 6752 kibana 11u IPv4 55370 0t0 TCP 127.0.0.1:5601 (LISTEN) node 6752 kibana 13u IPv4 55376 0t0 TCP 127.0.0.1:46448->127.0.0.1:9200 (ESTABLISHED) node 6752 kibana 14u IPv4 55371 0t0 TCP 127.0.0.1:46444->127.0.0.1:9200 (ESTABLISHED) node 6752 kibana 15u IPv4 55372 0t0 TCP 127.0.0.1:46446->127.0.0.1:9200 (ESTABLISHED) rsyslogd 6948 root 3u IPv4 59765 0t0 UDP *:514 rsyslogd 6948 root 4u IPv6 59766 0t0 UDP *:514 haproxy 7024 haproxy 5u IPv4 61408 0t0 UDP *:44174 haproxy 7025 haproxy 4u IPv4 61407 0t0 TCP *:80 (LISTEN) haproxy 7025 haproxy 5u IPv4 61408 0t0 UDP *:44174 haproxy 7025 haproxy 6u IPv4 61409 0t0 TCP *:443 (LISTEN) ``` The webpage is giving the error : myserver didn't send any data ( ERR\_EMPTY\_RESPONSE ) ``` Response to : curl http://x.x.x.x:5601/app/kibana OK Response to : curl http://x.x.x.x:5601/kibana 404 Error Response to : curl http://x.x.x.x:5601/ No response ``` I don't understant why kibana doesn't respond correctly on my 2 last curl's. Can somebody help me ? ---
**Author:** ![rashmi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rashmi/32/16391_2.png) [@rashmi](https://discuss.elastic.co/u/rashmi)\ **Post date:** [December 19, 2018, 5:36pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/2 "2018-12-19T17:36:20Z")
@tylersmalley or @jbudz any pointers here? Cheers Rashmi ---
**Author:** ![tylersmalley](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tylersmalley/32/8833_2.png) [@tylersmalley](https://discuss.elastic.co/u/tylersmalley)\ **Post date:** [December 19, 2018, 7:59pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/3 "2018-12-19T19:59:11Z")
Can you hit Kibana directly, bypassing the proxy? ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [December 20, 2018, 4:39pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/4 "2018-12-20T16:39:48Z")
No, It doesn't I suppose because of the 127.0.0.1 param in the kibana config. Found some information on SELinux blocking ports for HAPROXY, I'm checking this out. I will keep you posted of course 🙂 Of course if you have other ideas 🙂 EDIT : Kibana worked before the installation of the HAproxy, if needed I can post my original kibana config ( Information is on another pc.) ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [December 21, 2018, 3:38pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/5 "2018-12-21T15:38:01Z")
Back to square 1, didn't managed it to work after disabling the Selinux. Any ideas ? ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 1, 2019, 6:26am UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/6 "2019-01-01T06:26:39Z")
> [@Oliv](#): > > option httpchk GET / Try commenting this out of your Haproxy config file. That is not a proper health check url for Kibana, as evident from your Haproxy log saying "NOSRV" with disconnect status code of "SC" meaning no connection could be made to the backed server. If you looked at the Haproxy stats page with your current setup, you'd probably see your backend server is marked as down/red. No server to connect to...no worky. If you're not using xpack security, the health check url would be /api/status with an expected 200 status code returned (Haproxy is powerful enough you can configure the helath checks to read the returned json looking for some text instead of the 200 code if you so pleased). With xpack security you have several options...Kibana.yml and enable anonymous status access or look for another page. I'd choose the later and look for status 200 on the default login page url. ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 2, 2019, 3:10pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/7 "2019-01-02T15:10:41Z")
Thank you for your response Philip, Thank for the information concerning the health check. I Will look into that. But still no progress on why kibana doesn't respond. ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 2, 2019, 4:00pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/8 "2019-01-02T16:00:31Z")
Well, like I said...if HAProxy is detecting no server available because of a bad health check config, it will never make a connection to Kibana. Setup the [HAProxy stats](http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4.2-stats%20admin) backend to confirm: Put the following in your HAProxy config file (change IP/port to your correct settings, change username:password to whatever you'd like). Then connect to the page and check the Kibana backend status. > listen stats > bind 192.168.0.2:8080 > mode http > stats enable > stats uri / > stats refresh 10s > stats show-legends > stats auth statsuser:statspassword > stats admin if TRUE Also...why are you using such an old version of HAProxy? 1.9 stable is out now. I'd use 1.8 or 1.9 instead of 1.5 like you have. ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 2, 2019, 4:51pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/9 "2019-01-02T16:51:51Z")
Made the changes you provided. These are the informations it gave for the Kibana Backend. ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/3/0359d978b9cda2af5ee39ef1a5e58a42a49b6ddd.png) First line in the Image correspond to the server 'relk' Second line the backend. It seems to confirm that he can't make a connection with it. Haproxy logs : > Jan 2 17:37:45 localhost haproxy[7064]: Proxy stat\_localhost started. > Jan 2 17:37:45 localhost haproxy[7064]: Proxy stats started. > Jan 2 17:37:45 localhost haproxy[7064]: Proxy http-in started. > Jan 2 17:37:45 localhost haproxy[7064]: Proxy https-in started. > Jan 2 17:37:45 localhost haproxy[7064]: Proxy kibana started. > Jan 2 17:37:56 localhost haproxy[7065]: 192.168.39.198:49321 [02/Jan/2019:17:37:56.845] stats stats/ 27/0/0/1/28 200 21657 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:37:57 localhost haproxy[7065]: 192.168.39.198:49321 [02/Jan/2019:17:37:56.874] stats stats/ 372/-1/-1/-1/372 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:07 localhost haproxy[7065]: 192.168.39.198:49322 [02/Jan/2019:17:37:56.845] stats stats/ -1/-1/-1/-1/10385 400 187 - - CR-- 0/0/0/0/3 0/0 "" > Jan 2 17:38:07 localhost haproxy[7065]: 192.168.39.198:49337 [02/Jan/2019:17:38:07.232] stats stats/ 42/0/0/0/43 200 21719 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:07 localhost haproxy[7065]: 192.168.39.198:49337 [02/Jan/2019:17:38:07.275] stats stats/ 215/-1/-1/-1/215 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:17 localhost haproxy[7065]: 192.168.39.198:49336 [02/Jan/2019:17:38:07.232] stats stats/ -1/-1/-1/-1/10248 400 187 - - CR-- 0/0/0/0/3 0/0 "" > Jan 2 17:38:17 localhost haproxy[7065]: 192.168.39.198:49349 [02/Jan/2019:17:38:17.482] stats stats/ 49/0/0/0/50 200 21771 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:17 localhost haproxy[7065]: 192.168.39.198:49349 [02/Jan/2019:17:38:17.532] stats stats/ 237/-1/-1/-1/237 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:23 localhost haproxy[7065]: 192.168.39.198:49350 [02/Jan/2019:17:38:17.483] stats stats/ 6244/-1/-1/-1/6244 503 212 - - SC-- 0/0/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:27 localhost haproxy[7065]: 192.168.39.198:49362 [02/Jan/2019:17:38:27.770] stats stats/ 52/0/0/0/52 200 21772 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:28 localhost haproxy[7065]: 192.168.39.198:49362 [02/Jan/2019:17:38:27.822] stats stats/ 204/-1/-1/-1/204 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:35 localhost haproxy[7065]: 192.168.39.198:49363 [02/Jan/2019:17:38:27.771] stats stats/ 7851/0/0/0/7851 200 21778 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats;up HTTP/1.1" > Jan 2 17:38:35 localhost haproxy[7065]: 192.168.39.198:49363 [02/Jan/2019:17:38:35.622] stats stats/ 207/-1/-1/-1/207 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:38 localhost haproxy[7065]: 192.168.39.198:49373 [02/Jan/2019:17:38:35.601] stats stats/ 3335/0/0/0/3335 200 21784 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats;up HTTP/1.1" > Jan 2 17:38:39 localhost haproxy[7065]: 192.168.39.198:49373 [02/Jan/2019:17:38:38.936] stats stats/ 208/-1/-1/-1/208 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:43 localhost haproxy[7065]: 192.168.39.198:49379 [02/Jan/2019:17:38:38.912] stats stats/ 4321/0/0/0/4322 200 21778 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:43 localhost haproxy[7065]: 192.168.39.198:49379 [02/Jan/2019:17:38:43.233] stats stats/ 183/-1/-1/-1/183 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:46 localhost haproxy[7065]: 192.168.39.198:49385 [02/Jan/2019:17:38:43.212] stats stats/ 3223/0/0/0/3223 200 21781 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:46 localhost haproxy[7065]: 192.168.39.198:49385 [02/Jan/2019:17:38:46.436] stats stats/ 221/-1/-1/-1/221 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:38:56 localhost haproxy[7065]: 192.168.39.198:49389 [02/Jan/2019:17:38:46.410] stats stats/ -1/-1/-1/-1/10254 400 187 - - CR-- 0/0/0/0/3 0/0 "" > Jan 2 17:38:56 localhost haproxy[7065]: 192.168.39.198:49403 [02/Jan/2019:17:38:56.667] stats stats/ 39/0/0/0/39 200 21784 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:38:56 localhost haproxy[7065]: 192.168.39.198:49403 [02/Jan/2019:17:38:56.707] stats stats/ 214/-1/-1/-1/214 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:39:06 localhost haproxy[7065]: 192.168.39.198:49404 [02/Jan/2019:17:38:56.668] stats stats/ -1/-1/-1/-1/10232 400 187 - - CR-- 0/0/0/0/3 0/0 "" > Jan 2 17:39:06 localhost haproxy[7065]: 192.168.39.198:49423 [02/Jan/2019:17:39:06.902] stats stats/ 33/0/0/0/34 200 21791 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:39:07 localhost haproxy[7065]: 192.168.39.198:49423 [02/Jan/2019:17:39:06.936] stats stats/ 576/-1/-1/-1/576 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1" > Jan 2 17:39:15 localhost haproxy[7065]: 192.168.39.198:49443 [02/Jan/2019:17:39:15.818] https-in~ https-in/ -1/-1/6 0 SC 2/1/0/0/0 0/0 > Jan 2 17:39:15 localhost haproxy[7065]: 192.168.39.198:49444 [02/Jan/2019:17:39:15.819] https-in~ https-in/ -1/-1/7 0 SC 1/0/0/0/0 0/0 > Jan 2 17:39:17 localhost haproxy[7065]: 192.168.39.198:49424 [02/Jan/2019:17:39:06.902] stats stats/ -1/-1/-1/-1/10615 400 187 - - CR-- 0/0/0/0/3 0/0 "" > Jan 2 17:39:17 localhost haproxy[7065]: 192.168.39.198:49446 [02/Jan/2019:17:39:17.517] stats stats/ 40/0/0/0/40 200 21792 - - LR-- 2/2/0/0/0 0/0 "GET /admin?stats HTTP/1.1" > Jan 2 17:39:18 localhost haproxy[7065]: 192.168.39.198:49449 [02/Jan/2019:17:39:18.123] https-in~ https-in/ -1/-1/4 0 SC 2/0/0/0/0 0/0 > Jan 2 17:39:18 localhost haproxy[7065]: 192.168.39.198:49446 [02/Jan/2019:17:39:17.558] stats stats/ 976/-1/-1/-1/976 503 212 - - SC-- 1/1/0/0/0 0/0 "GET /favicon.ico HTTP/1.1"[/spoiler] I just took the version that was in the yum repository. I'll try to install tomorrow the 1.8 version of Haproxy, I'll use this [Link](https://centos.pkgs.org/7/ius-archive-x86_64/haproxy18u-1.8.4-1.ius.centos7.x86_64.rpm.html) Thanks for your help. ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 2, 2019, 5:29pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/10 "2019-01-02T17:29:21Z")
So because the backend server line is grey, it just means that health checking is not enabled (evident in your HAProxy config file that the is no "check" directive on the server line. So...even though you have a junk health check url, it's not being used by HAProxy because you're not telling it to. To enable health checks, the server line would look like this: If not using an ssl cert on Kibana ``` server relk 127.0.0.1:5601 check ``` If using an ssl cert on Kibana ``` server relk 127.0.0.1:5601 check check-ssl ``` Instead of having HAProxy rewrite the basepath using your request replace directive (reqrep.....), have you tried removing that from the HAProxy config and then changing the Kibana.yml file option instead: server.rewritebasepath: true ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 2, 2019, 5:30pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/11 "2019-01-02T17:30:36Z")
> [@Oliv](#): > > I'll try to install tomorrow the 1.8 version of Haproxy, I'll use this [Link](https://centos.pkgs.org/7/ius-archive-x86_64/haproxy18u-1.8.4-1.ius.centos7.x86_64.rpm.html) That is a very old build of 1.8. 1.8.16 is out. I'd try to find a repo for that version instead. ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 3, 2019, 3:56pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/12 "2019-01-03T15:56:44Z")
Hi Philip, With the config : haproxy.cfg ``` option httpchk GET / ``` #reqrep ^([^\ :]_)\ /kibana/(._) \1\ /\2 server relk 127.0.0.1:5601 check & Kibana.yml : server.rewriteBasePath: true these are the results The Haproxy log : Jan 3 14:22:40 localhost haproxy[11078]: Server kibana/relk is DOWN, reason: Layer7 wrong status, code: 404, info: "Not Found", check duration: 2ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Jan 3 14:22:40 localhost haproxy[11078]: backend kibana has no server available! And of course the backend is down on the stats page. I installed Haproxy 1.8.16 with the help of this site : [http://virgiawanpratama.blogspot.com/2017/10/how-to-install-haproxy-179-with-ssl-on.html](http://virgiawanpratama.blogspot.com/2017/10/how-to-install-haproxy-179-with-ssl-on.html) I just took the install part and didn't do the firewalld part as I disabled it for the moment. I did a test with curl to find out if kibana is answering correctly and these are my findings : curl [http://127.0.0.1:5601/kibana](http://127.0.0.1:5601/kibana) no response curl [http://127.0.0.1:5601/kibana/app/kibana](http://127.0.0.1:5601/kibana/app/kibana) Got the welcome page response from Kibana. curl [http://127.0.0.1:5601/app/kibana](http://127.0.0.1:5601/app/kibana) Got a 'NOT FOUND' response. curl [http://127.0.0.1:5601/kibana/api/status](http://127.0.0.1:5601/kibana/api/status) : lots of answers with 'Sucess' eg {"state":"green","title":"Green","nickname":"Looking good","icon":"success","uiColor":"secondary","since":"2019-01-03T13:15:55.417Z"}, changed this line : ``` option httpchk GET /Kibana/api/status ``` Only thing that changed is the status of the backend, he seeing it as UP :L7OK/200 so he knows that Kibana is UP. with the curl result mentioned I tested the URL's : [https://myserver/kibana](https://myserver/kibana) : ERR\_EMPTY\_RESPONSE [https://myserver/kibana/app/kibana](https://myserver/kibana/app/kibana) : ERR\_CONNECTION\_ABORTED My conclusion to this : Haproxy is forwarding the request 'as is' to Kibana which rejects them because they aren't coming from the localhost ( config file says server.host : 127.0.0.1) so he rejects the request and that's why we get the connexion aborted, right ? Can we say to haproxy to send them as the 'localhost' ? I supposed that the 'basepath' config should allow us to use /kibana instead of /app/kibana, correct ? ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 3, 2019, 5:01pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/13 "2019-01-03T17:01:02Z")
You shouldn't have HAProxy rewrite the request path AND also have kibana.yml set to rewritebasepath: true...it's one or the other. > [@Oliv](#): > > Haproxy is forwarding the request 'as is' to Kibana which rejects them because they aren't coming from the localhost ( config file says server.host : 127.0.0.1) so he rejects the request and that's why we get the connexion aborted, right ? No. If you have your server line in HAProxy config set to 127.0.01:5601, THAT is where the request is forwarded to...127.0.0.1. > [@Oliv](#): > > Can we say to haproxy to send them as the 'localhost' ? Sort of (you can specify a source IP to use), but there should be no need. On the server line, you'd use the "source" directive to tell HAProxy to use a certain IP...in this case, 127.0.0.1. So when a connection is made to a backend server, it comes from 127.0.0.1 instead of the default interface. Again...I don't think you need to do this as I don't believe it's the problem. Again...I think your problem lies with your basepath config and your'e telling both HAProxy AND Kibana to rewrite the base path...only one should be doing that. ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 3, 2019, 5:06pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/14 "2019-01-03T17:06:08Z")
Sorry there has been a mistype in my comment. The ' reqrep ^([^\ :] _)\ /kibana/(._ ) \1\ /\2' was commented. I'll change my post immediatly. sorry for this. ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 3, 2019, 5:32pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/15 "2019-01-03T17:32:03Z")
What I ment with : > Haproxy is forwarding the request 'as is' to Kibana which rejects them because they aren't coming from the localhost ( config file says server.host : 127.0.0.1) so he rejects the request and that's why we get the connexion aborted, right ? Haproxy forwards the request ' [https://myserver/kibana/app/kibana](https://myserver/kibana/app/kibana)' as is to kibana and kibana rejects it because of the line in kibana.yml : server.host: 127.0.0.1 which means he accepts only request from the localhost. Haproxy doesn't change the request ' [https://myserver/kibana/app/kibana](https://myserver/kibana/app/kibana)' to '[https://127.0.0.1/kibana/app/kibana](https://127.0.0.1/kibana/app/kibana)', it's only forwarding it.and that's why the error is 'ERR\_CONNECTION\_ABORTED'. ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 3, 2019, 5:32pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/16 "2019-01-03T17:32:32Z")
Ok, so if the proxy isn't rewriting, then you should have the following in kibana.yml ``` server.basePath: "/kibana" server.rewriteBasePath: true ``` Is that what you have and it doesn't work? You've restarted/reloaded the haproxy service so the changes are accepted? ---
**Author:** ![Oliv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/oliv/32/111867_2.png) [@Oliv](https://discuss.elastic.co/u/Oliv)\ **Post date:** [January 3, 2019, 5:34pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/17 "2019-01-03T17:34:22Z")
Yes that's what I have. and it doesn't work. ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 3, 2019, 5:36pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/18 "2019-01-03T17:36:27Z")
> [@Oliv](#): > > the line in kibana.yml : server.host: 127.0.0.1 which means he accepts only request from the localhost. That just sets the host address to LISTEN for request on...the name is insignificant. HAProxy is configured properly to send the requests to 127.0.0.1. ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 3, 2019, 5:37pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/19 "2019-01-03T17:37:11Z")
what if you set server.rewriteBasePath: false does that make a difference? ---
**Author:** ![bigphil](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@bigphil](https://discuss.elastic.co/u/bigphil)\ **Post date:** [January 3, 2019, 5:51pm UTC](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564/20 "2019-01-03T17:51:02Z")
[Here](https://stackoverflow.com/questions/36266776/kibana-server-basepath-results-in-404) is a good article the better explains how the basepath settings work. I don't know what else to say. ``` server.basePath: "/kibana" server.rewriteBasePath: true ``` This should be correct IF you commented out the basepath rewrite in HAProxy (reqrep). [Next page](https://discuss.elastic.co/t/kibana-behind-haproxy-a-basepath-problem/161564.md?page=2)