# Need help on why https doesn't work

**URL:** <https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165>\
**Category:** Help!\
**Created:** [August 8, 2019, 3:44pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165 "2019-08-08T15:44:55Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![dz.wu](https://avatars.discourse-cdn.com/v4/letter/d/77aa72/32.png) [@dz.wu](https://discourse.haproxy.org/u/dz.wu)\
**Post date:** [August 8, 2019, 3:44pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/1 "2019-08-08T15:44:55Z")

</div>

Hi I don’t know why https doesn’t work. Http works perfectly.  
Here is my haproxy.cfg. And my haproxy is version “HA-Proxy version 1.6.3 2015/12/25”  
xxx.xxx.xxx is my target backend server. I don’t know what’s wrong with my haproxy.cfg. And i const

```auto
global
log 127.0.0.1:514 local0
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon

defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

resolvers dns
nameserver hk 210.177.255.186:53
hold valid 1s

frontend http_api
bind *:80
mode http
acl network_allowed src 10.28.0.0/14 10.32.0.0/14 10.12.0.0/14 10.60.0.0/14
acl google hdr_beg(host) -i www.google.com
http-request deny if !network_allowed
option forwardfor
use_backend google_backend if google

frontend https_api
bind *:443
mode tcp
acl network_allowed src 10.28.0.0/14 10.32.0.0/14 10.12.0.0/14 10.60.0.0/14
acl misumi hdr_beg(host) -i xxx.xxx.xxx
http-request deny if !network_allowed
option forwardfor
use_backend misumi_backend if misumi

backend google_backend
mode http
balance roundrobin
server google www.google.com:80 check inter 1000 resolvers dns
#server nginx 10.128.0.121:80

backend misumi_backend
mode tcp
balance roundrobin
server misumi xxx.xxx.xxx:443 check inter 1000 resolvers dns

```

---

<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:** [August 8, 2019, 4:23pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/2 "2019-08-08T16:23:27Z")

</div>

```
frontend https_api
 bind *:443
 mode tcp
 acl network_allowed src 10.28.0.0/14 10.32.0.0/14 10.12.0.0/14 10.60.0.0/14
 acl misumi hdr_beg(host) -i xxx.xxx.xxx
 http-request deny if !network_allowed
 option forwardfor
 use_backend misumi_backend if misumi

```

The configuration is wrong. You are trying to access the host header in the HTTP request (`acl misumi`), which is not available because a) you are in TCP mode and b) the SSL traffic is encrypted, so you’d never be able to access that host header.

Suggestions:

- use `default_backend misumi_backend` without an ACL
- decrypt SSL by installing the certificate on haproxy
- access SNI instead, see below

SNI config:

```
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl misumi req_ssl_sni -i www.example.org
```

---

<div class="post-metadata">

**Author:** ![dz.wu](https://avatars.discourse-cdn.com/v4/letter/d/77aa72/32.png) [@dz.wu](https://discourse.haproxy.org/u/dz.wu)\
**Post date:** [August 9, 2019, 1:14am UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/3 "2019-08-09T01:14:27Z")

</div>

using 443 port is not a must. I can use port 8080. So i want to have request (https) -\> haproxy -\> backend server. I only need haproxy to send request to backend with https. It’s not a must to use https to call haproxy, so i don’t think i need to install ssl certificate and use ssl to decrypt request.  
And to be more precise, I’m using the curl command to test and it returns me with below error.  
curl https:// --proxy http://:8080

error  
curl: (56) Received HTTP code 400 from proxy after CONNECT

i followed your suggestions and below is my configuration.

global  
log 127.0.0.1:514 local0  
chroot /var/lib/haproxy  
stats socket /run/haproxy/admin.sock mode 660 level admin  
stats timeout 30s  
user haproxy  
group haproxy  
daemon

defaults  
log global  
mode http  
option httplog  
option dontlognull  
timeout connect 5000  
timeout client 50000  
timeout server 50000  
errorfile 400 /etc/haproxy/errors/400.http  
errorfile 403 /etc/haproxy/errors/403.http  
errorfile 408 /etc/haproxy/errors/408.http  
errorfile 500 /etc/haproxy/errors/500.http  
errorfile 502 /etc/haproxy/errors/502.http  
errorfile 503 /etc/haproxy/errors/503.http  
errorfile 504 /etc/haproxy/errors/504.http

resolvers dns  
nameserver hk 210.177.255.186:53  
hold valid 1s

frontend http\_api  
bind \*:80  
mode http  
acl network\_allowed src 10.28.0.0/14 10.32.0.0/14 10.12.0.0/14 10.60.0.0/14  
acl google hdr\_beg(host) -i [www.google.com](http://www.google.com)  
http-request deny if !network\_allowed  
option forwardfor  
use\_backend google\_backend if google

frontend misumi\_https  
bind \*:8080  
mode tcp  
acl network\_allowed src 10.28.0.0/14 10.32.0.0/14 10.12.0.0/14 10.60.0.0/14  
http-request deny if !network\_allowed  
tcp-request inspect-delay 5s  
tcp-request content accept if { req\_ssl\_hello\_type 1 }  
option forwardfor  
default\_backend misumi\_backend

backend google\_backend  
mode http  
balance roundrobin  
server google [www.google.com:80](http://www.google.com:80) check inter 1000 resolvers dns  
#server nginx 10.128.0.121:80

backend misumi\_backend  
mode tcp  
balance roundrobin  
acl misumi req\_ssl\_sni -i xxx.xxx.xxx  
server misumi [dsd.misumi.sh.cn:443](http://dsd.misumi.sh.cn:443) check inter 1000 resolvers dns

listen stats  
bind :8989  
mode http  
log global  
stats refresh 30s  
stats enable  
stats uri /stats  
stats realm HAProxy\ Statistics  
stats auth abc:abc

---

<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:** [August 9, 2019, 3:18pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/4 "2019-08-09T15:18:57Z")

</div>

> [@dz.wu](#):
>
> using 443 port is not a must. I can use port 8080.

Which exact port you use does not matter.

> [@dz.wu](#):
>
> So i want to have request (https) → haproxy → backend server. I only need haproxy to send request to backend with https

Right, then use `default_backend` as suggested, not an ACL with a condition based on a HTTP header.

> [@dz.wu](#):
>
> And to be more precise, I’m using the curl command to test and it returns me with below error.  
> curl https:// --proxy http://:8080

This is wrong. Haproxy is not a forward proxy, it’s a reverse proxy. The call needs to be (if on port 443):

`curl https://<haproxyIP/`

---

<div class="post-metadata">

**Author:** ![dz.wu](https://avatars.discourse-cdn.com/v4/letter/d/77aa72/32.png) [@dz.wu](https://discourse.haproxy.org/u/dz.wu)\
**Post date:** [August 9, 2019, 10:57pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/5 "2019-08-09T22:57:44Z")

</div>

hmm i think you misunderstand this

> This is wrong. Haproxy is not a forward proxy, it’s a reverse proxy. The call needs to be (if on port 443):  
> curl https://\<haproxyIP\>/

my command is

> curl https:// \<backend server\> --proxy http://\<haproxy ip\>

. In this scenario i still need to use https for my haproxy ? i thought it’s not a must.

---

<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:** [August 9, 2019, 11:13pm UTC](https://discourse.haproxy.org/t/need-help-on-why-https-doesnt-work/4165/6 "2019-08-09T23:13:50Z")

</div>

No, reread what I just said.

You don’t use the `--proxy` argument with curl.