Tunnel, Unix sockets and TLS handshakes

Hello community members!

I’ve just installed a Cloudflare Tunnel on my Ubuntu system. On my system (single VPS) I have a Cloudflare Tunnel and an Nginx webserver.

The thing is, if I indicate in the Tunnel conf file, that it needs to send requests to http://localhost:8000 - everything works fine and Nginx receives plain HTTP requests successfully from Cloudflare Tunnel daemon.
I think it’s quiet safe, because the Tunnel itself is secured, and when requests arrive at Tunnel daemon, I want to route them to my Nginx webserver unencrypted (plain HTTP), to negate TLS encryption overheads.

But if I indicate in the Tunnel conf file, that the Tunnel should send requests via unix:/run/dir/socket.sock to the Nginx webserver, the Tunnel tries to establish TLS handshake with my Nginx webserver out of nowhere. And I can’t find a way to strip TLS encryption (make it plain HTTP).

I tried smt like that http://unix:/run/dir/socket.sock - but it doesn’t work.

Could you please help me deal with this trouble, please?

Try something like this noTLSVerify in your config file:
Screen Shot 2021-11-06 at 11.26.54 AM

Wait…are you saying the socket won’t accept a TLS request? I’m not sure why that would be. You’d have to test that out locally, like with a ‘curl’ command.

1 Like

Thank you for your proposal!

The trouble is that the requests via socket are made purely with HTTPS, and not HTTP as I want :frowning: I want Nginx to receive plain HTTP from the Cloudflare Tunnel daemon via a socket.

I tried noTLSVerify, but it doesn’t work. My conf:

protocol: quic
tunnel: sometunnelID
credentials-file: /dir/credentialsfile.json

  - hostname: somename
    service: unix:/run/somedir/socket.sock
      noTLSVerify: true
  # Example of a rule responding to traffic with an HTTP status:
  - service: http_status:404

And error codes from syslog:

ERR  error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: tls: first record does not look like a TLS handshake" cfRay=someid-DME ingressRule=0 originService="unix socket: /run/somedir/socket.sock"
ERR Failed to handle QUIC stream error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: tls: first record does not look like a TLS handshake"

Everything works fine, if I configure Nginx to receive HTTPS from a socket, but I don’t want Nginx to additionally mess with TLS encryption overheads - it’s pointless in my configuration.


I also tried to switch SSL/TLS encryption mode at Cloudflare admin panel to Flexible, but it hasn’t helped.

I finally actually looked at the docs. It says it’s HTTP/S for socket connections. I don’t think you’ll be able to get HTTP working. Why won’t NGINX work with HTTP/S? Or are you just trying to shave off SSL negotiation?

1 Like

Yeap, I’m just trying to shave off the TLS negotiation to increase speed and reduce latency :slight_smile: I’ve also looked at this documentation for a long time and understood the “HTTP/S” as logical AND, like HTTP and HTTPS. I know, that the daemon has functionality to speak plain HTTP (like http://localhost:8000 in the config) with my server. I’m just wondering how can I make it do the same only via a unix socket?

I suggest you run some tests, such as comparing an Ingress rule for HTTP vs one to HTTPS.

  1. Can’t do that now, because can’t run plain HTTP via a socket. I compared HTTPS via a socket vs localhost HTTPS = socket reduces latency by 100 ms
  2. I want to strip TLS handshakes, thus only TCP handshakes would stay. HTTP is a much simpler protocol → it would run faster.
  3. I don’t need HTTPS running between system processes - it’s redundant and consumes CPU power for encryption for nothing.

@chungting looks to be one of the devs on Cloudflare Tunnel and might know why socket won’t work with HTTP.

1 Like

Hi @grey,

It is not possible to control the scheme when using a Unix socket ingress at the moment. The different between an HTTP ingress vs. Unix socket is in cloudflared/origin_proxy.go at 8f3526289a7880d4d9408cf53ab441756e38d174 · cloudflare/cloudflared · GitHub. Unfortunately we don’t have the bandwidth to prioritize it, but contributions are always welcomed!


Thank you for your answer! I’ll just create an Issue at Github so that at least this feature request will stay in the backlog.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.