1

After installation of varnish & hitch on ubuntu 20.04 server, getting following error:

curl: (52) Empty reply from server

Tutorial I am following:

[https://docs.varnish-software.com/tutorials/hitch-letsencrypt/][1]

In my case, I have two servers s1 & s2 both have ubuntu 20.04 server installed. local static ip of s1:

192.168.1.105

local static ip of s2:

192.168.1.106

On s1 virtualmin pannel is installed & every thing working fine. So i decided to make a saparate cache server & installed varnish & hitch as:

sudo apt install varnish -y 

sudo apt install hitch -y

changes in default.vcl file:

    backend default {
    .host = "192.168.1.105";
    .port = "80";

   }

hitch.conf:

# Run 'man hitch.conf' for a description of all options.
    frontend = {
        host = "*"
        port = "443"
    }
    backend = "[127.0.0.1]:8443"    # 6086 is the default Varnish PROXY port.
#workers = 4                     # number of CPU cores

#daemon = on

# We strongly recommend you create a separate non-privileged hitch
# user and group
#user = "hitch"
#group = "hitch"

# Enable to let clients negotiate HTTP/2 with ALPN. (default off)
# alpn-protos = "h2, http/1.1"

# run Varnish as backend over PROXY; varnishd -a :80 -a localhost:6086,PROXY ..
#write-proxy-v2 = on             # Write PROXY header

#pem files

    pem-file = "/etc/letsencrypt/live/example.com/hitch-bundle.pem"

unit file:

    [Unit]
Description=Varnish HTTP accelerator
Documentation=https://www.varnish-cache.org/docs/6.1/ man:varnishd

    [Service]
    Type=simple
    LimitNOFILE=131072
    LimitMEMLOCK=infinity
    ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -a localhost:8443,proxy -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3G
    ExecReload=/usr/share/varnish/varnishreload
    ProtectSystem=full
    ProtectHome=true
    PrivateTmp=true
    PrivateDevices=true

    [Install]
    WantedBy=multi-user.target

Note: I have no idea about networking, so main router connected with second router and both s1 & s2 directly connected with second router. Also dmz host ip changed from s1 ip to s2 ip.

Result:

curl -i https://example.com
curl: (52) Empty reply from server.

upon This command varnishlog -g request -q "ReqUrl eq ’/’" VSM: Could not get hold of varnishd, is it running?

Please guide thanks.

Amir
  • 91
  • 3
  • 11

1 Answers1

2

Fix empty reply by enabling PROXY protocol

Uncomment the following line in your hitch.conf:

#write-proxy-v2 = on

This will enable the use of the PROXY protocol to communicate with Varnish. This protocol passes more information about the original client (the one that connected with Hitch) to Varnish via TLV attributes.

You are connecting to port 8443 from Hitch, which is Varnish's PROXY protocol port as described by the following varnishd runtime parameters:

-a localhost:8443,proxy

Right now Varnish is expecting PROXY information to be present in the TCP packets, but couldn't find that information. Hence the empty reply.

Make Varnish protocol aware

If your application forces HTTPS redirection, it is important to make Varnish aware of the protocol that is used. It'll either be HTTP or HTTPS.

If you use Hitch over the PROXY protocol, we can use vmod_proxy to identify these connections and create proper cache variations.

Here's the VCL code for that:

vcl 4.1;

import proxy;

sub vcl_recv {
    if (proxy.is_ssl()) {
        set req.http.X-Forwarded-Proto = "https";
    } else {
        set req.http.X-Forwarded-Proto = "http";
    }
}

sub vcl_backend_response {
    if(beresp.http.Vary) {
        if(beresp.http.Vary !~ "X-Forwarded-Proto") {
            set beresp.http.Vary = set beresp.http.Vary + ", X-Forwarded-Proto";
        }
    } else {
        set beresp.http.Vary = "X-Forwarded-Proto";
    }
}

This code will store an HTTP version and an HTTPS version of each response.

Bonus: enable HTTP/2

While you're at it, you might as well enable HTTP/2 by uncommenting the following line in your hitch.conf file:

# alpn-protos = "h2, http/1.1"

To ensure HTTP/2 is enabled in Varnish, please add the following runtime parameter to varnishd in your systemd configuration:

-p feature=+http2

Restart both Hitch & Varnish and Hitch will be able to terminate TLS for HTTP/2 requests.

Thijs Feryn
  • 3,982
  • 1
  • 5
  • 10
  • Thanks for answering, I again clean install ubuntu & latest varnish & hitch with your suggestion and now error is: – Amir Jan 12 '22 at 09:31
  • curl -i example.com HTTP/1.1 302 Found Date: Tue, 11 Jan 2022 18:32:12 GMT Server: Apache Location: example.com Content-Length: 214 Content-Type: text/html; charset=iso-8859-1 X-Varnish: 98348 Age: 0 Via: 1.1 varnish (Varnish/7.0) Connection: keep-alive 302 Found

    Found

    The document has moved here.

    – Amir Jan 12 '22 at 09:33
  • I haven't installed any cluster software. Can varnish directly communicate web server? – Amir Jan 12 '22 at 10:57
  • @Amir That's not really an error, it's a redirection request using a `302` status and a `Location` header. You can actually follow redirections in `curl` by adding the `-L` flag. – Thijs Feryn Jan 12 '22 at 12:13
  • same with -L flag. On browser, ERR_TOO_MANY_REDIRECTS – Amir Jan 12 '22 at 13:54
  • Should I need any cluster package like kubernetes for communication between two servers? – Amir Jan 12 '22 at 13:59
  • Let's focus on `ERR_TOO_MANY_REDIRECTS` first. It could be related to a lack of protocol awareness and forced HTTPS redirection. I added some VCL code in my answer to fix this. But of course there's no guarantee that it will fix your issue. – Thijs Feryn Jan 12 '22 at 14:08
  • If the VCL code doesn't fix your issue, you can run the following command to debug: `varnishlog -g request -q "ReqUrl eq '/'"`. Try making sure the cache is empty before testing it. This command assumes the error is also happening on the homepage. Be sure to add the output of this command to your original question. It will help me understand what's going on behind the scenes. – Thijs Feryn Jan 12 '22 at 14:09
  • vcl suggestions didn't helped me – Amir Jan 12 '22 at 15:11
  • Please proceed with the `varnishlog -g request -q "ReqUrl eq '/'"` command and add the output to your question. Maybe also have a look at webserver or application configurations that might be responsible for the `302 Found` redirect. – Thijs Feryn Jan 12 '22 at 15:29
  • command varnishlog -g request -q "ReqUrl eq '/'" resulted as: VSM: Could not get hold of varnishd, is it running? – Amir Jan 13 '22 at 02:45
  • I've checked status of both varnish & hitch both are active also on web server s1 in public_html simple html file & no .htaccess file. – Amir Jan 13 '22 at 02:50
  • @Amir add `sudo` to the command. Not getting a hold of the `varnishd` means you don't have enough permissions right now. – Thijs Feryn Jan 13 '22 at 07:40
  • @Amir If there's no .htaccess and the application is plain HTML, you should try to find out what causes the 302 redirect in Apache. Have a look at your Apache configuration, maybe there's something in there. – Thijs Feryn Jan 13 '22 at 07:47
  • With sudo no response. if request directly go to web server every thing working fine but when request go to varnish server, 302 response. – Amir Jan 13 '22 at 13:50
  • @Amir Varnish doesn't perform 302 redirects on its own. Either your Varnish VCL configuration does the 302 explicitly or your backend application doesn't like what it sees when Varnish is connected and does the redirection. Please add your VCL configuration to our original question and look for indications in your application or webserver configuration that would point to that redirection. – Thijs Feryn Jan 13 '22 at 14:31
  • I haven't changed anything in vcl file, same as it comes with installation. Only backend ip & port 80 which I already mentioned in my question. – Amir Jan 14 '22 at 04:02
  • @Amir Then you'll have to look into your application or webserver logic and figure out why it causes the 302. If you have no specific VCL that causes this, we can consider this issue answered. The main objective was achieved: make sure Hitch connects to Varnish. – Thijs Feryn Jan 14 '22 at 07:58
  • thanks a lot finally I found the solution of 302. actually virtualmin default behavior is to redirect every http request to https request. by deleting this rule, site is working now. – Amir Jan 17 '22 at 12:36
  • one problem still facing please guide. without varnish site load time is 2s but with varnish through server 2 load time is 8s. Any idea? & I'm accepting your answer as it helped me lot. – Amir Jan 17 '22 at 12:40
  • 1
    @Amir Please open a separate question on StockOverflow about the loading time and post the output from `varnishlog -g request -q "ReqUrl eq '/'"`. This will give me a head start at debugging potential latency. Please use the Varnish tag so I get a notification or send me the link to the question. – Thijs Feryn Jan 17 '22 at 13:37