”
The site seems to be working fine in general, and I am unable to produce any errors myself.
Any help on this would be much appreciated!
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [October 15, 2018, 9:13pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/2 "2018-10-15T21:13:48Z")
Although I did not take the time to decode the hex, the fact the we see your hostname in there as well as “http/1.1” makes me think this could be TLS (SNI and ALPN).
Sounds like an issue on their side, unless you have a particular configuration, where port 443 can hit a http parser without decrypting TLS first.
Can you share your config?
---
### Author:  [@waynewex](https://discourse.haproxy.org/u/waynewex)
#### Post date: [October 15, 2018, 9:20pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/3 "2018-10-15T21:20:49Z")
Of course!
```
global
log 127.0.0.1 local0 notice
stats socket /var/run/haproxy.stat
maxconn 70000
tune.maxrewrite 16384
tune.bufsize 32768
tune.ssl.cachesize 10000000
user haproxy
group haproxy
nbproc 4
cpu-map 1 0
cpu-map 2 1
cpu-map 3 2
cpu-map 4 3
defaults
log global
mode http
maxconn 70000
option httplog
option dontlognull
option forwardfor
retries 5
option redispatch
timeout connect 25000
timeout client 25000
timeout server 25000
listen mysite
option httplog
option dontlog-normal
option dontlognull
option accept-invalid-http-request
log /dev/log local0
bind 0.0.0.0:80
bind :::80 v6only
bind *:443 ssl crt /etc/ssl/mysite.com/mysite.com.pem
mode http
maxconn 70000
balance static-rr
option http-keep-alive
option forwardfor
http-request set-header X-Forwarded-Proto HTTPS_ON if { ssl_fc }
cookie SRVNAME insert
timeout connect 10s
timeout client 60s
timeout server 60s
reqidel ^X-Forwarded-For:.*
redirect scheme https code 301 if !{ ssl_fc }
acl fb-img-acl hdr_dom(host) -i fb.mysite.com
use_backend varnish-backend if fb-img-acl
acl thumb-img-acl hdr_dom(host) -i thumbs.mysite.com
use_backend varnish-backend if thumb-img-acl
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
use_backend letsencrypt-backend if letsencrypt-acl
server mysite01 10.136.109.25:80 cookie MS01 check
server mysite02 10.136.126.250:80 cookie MS02 check
server mysite04 10.136.127.19:80 cookie MS04 check
server mysite05 10.136.127.60:80 cookie MS05 check
server mysite06 10.136.63.133:80 cookie MS06 check
backend letsencrypt-backend
server letsencrypt 127.0.0.1:8888
backend varnish-backend
server varnish 127.0.0.1:6081
```
---
### Author:  [@waynewex](https://discourse.haproxy.org/u/waynewex)
#### Post date: [October 15, 2018, 9:30pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/4 "2018-10-15T21:30:22Z")
Also note that the Varnish backend was only added recently and that this issue was occurring before that.
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [October 15, 2018, 9:37pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/5 "2018-10-15T21:37:03Z")
Config does not do anything exotic (like TLS in a tcp mode frontend, with some SNI dance and other complicated stuff).
Yes, the hex code is indeed from a TLS client\_hello. This means that facebook is accessing port 80 via HTTPS.
Could it be that someone just posted (or continues to post) a wrong URL in facebook, where a HTTPS url points to port 80:
```
https://fb.mysite.com:80/blabla
```
Do you see valid requests from those facebook crawlers also or just these wrong request?
I’d suggest you make test, because after all, the users in facebook are triggering those crawlers:
- try posting a normal working http link from your site, while checking the haproxy logs.
- try posting a normal working https link from your site, while checking the haproxy logs
- try posting a https link that erroneously points to port 80 (like in the example above)
A private message should suffice to trigger this, you don’t have to post something publicly.
You could also capture port 80 traffic from those facebook ip ranges or all port 80 traffic (after all, you redirect everything to HTTPS, so it’s probably not a high volume).
I’m pretty sure there is no issue with haproxy.
---
### Author:  [@waynewex](https://discourse.haproxy.org/u/waynewex)
#### Post date: [October 15, 2018, 10:09pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/6 "2018-10-15T22:09:41Z")
Hi Lukas,
Thank you for your help!
> [@lukastribus](#):
>
> Do you see valid requests from those facebook crawlers also or just these wrong requests.
Yes, most of the requests seem to be valid. I have seen users sharing content from the site just fine and I was personally able to share links as well. My Varnish cache is also showing a healthy number of cache hits.
> Could it be that someone just posted (or continues to post) a wrong URL in facebook, where a HTTPS url points to port 80.
I doubt that, especially considering the number of BADREQ that I am getting. I did only switch to HTTPS in June of this year and the site had been operating for a year and a half before that. i.e. All of the original shares before June 2018 would have been to the HTTP site.
The [fb.mysite.com](http://fb.mysite.com) subdomain is specifically for images that have been specified in the og:image tag, which is:
> The URL of the image that appears when someone shares the content to Facebook.
I used the Facebook Sharing debugger to test a non-HTTPS link and it responded saying that it had followed the 301 redirect to the HTTPS site. The scraped image also appeared just fine.
Perhaps this is an issue with the crawler accessing previously shared non-HTTPS content?
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [October 15, 2018, 10:19pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/7 "2018-10-15T22:19:52Z")
Maybe, but it must be a bug on their side. I don’t see why the old content would not follow the redirect or follow it, but maintaining the port to 80.
Either way, there doesn’t seem to be a lot you can do at this point.
---
### Author:  [@waynewex](https://discourse.haproxy.org/u/waynewex)
#### Post date: [October 15, 2018, 10:22pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/8 "2018-10-15T22:22:18Z")
Thank you for your help! I will log it as a bug in their developer support section.
---
### Author:  [@waynewex](https://discourse.haproxy.org/u/waynewex)
#### Post date: [October 28, 2018, 12:07pm UTC](https://discourse.haproxy.org/t/invalid-requests/3098/9 "2018-10-28T12:07:04Z")
> [@lukastribus](#):
>
> You could also capture port 80 traffic from those facebook ip ranges or all port 80 traffic (after all, you redirect everything to HTTPS, so it’s probably not a high volume).
Hi Lukas,
I was returning to this topic and I noticed your statement above. Is there a way for me to FORCE these port 80 requests to port 443 if it’s a particular host? i.e. [fb.mysite.com](http://fb.mysite.com)?
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [October 30, 2018, 11:35am UTC](https://discourse.haproxy.org/t/invalid-requests/3098/10 "2018-10-30T11:35:24Z")
Yes, but it requires an additional frontend/backend layer to distinguish between HTTP and HTTPS. Take a look at this thread:
> [@TLS Termination Proxy with both TLS and plain TCP on the same port](https://discourse.haproxy.org/t/tls-termination-proxy-with-both-tls-and-plain-tcp-on-the-same-port/2885/):
>
> We’re considering using HAProxy as a TLS termination proxy, running in front of our TCP server where our clients connect with their front-end apps. I’m wondering if HAProxy is capabale of making distinction between SSL connection and plain connection on the same port in the frontend section (like binding for example on port 80 both the plain and the ssl sockets), and regardless if it’s an encrypted or non-encrypted connection, it will be proxied on to the backend server: if it’s a plain connect…