Varnish, SSL and HTTP headers - No X-Cache after reload with SSL?

Question

I noticed a strange behaviour of my Varnish/Apache setup which makes me wonder wether the pages are at any time properly cached or not.

I am running Apache on Port 8080 and Varnish on port 80 on the same machine. Also I'm using Apache for SSL termination with Varnish like described in this article

I am testing to open a webpage in four different ways and I would expect the HTTP X-Cache headers to appear in all four instances to prove that varnish is properly running:

1. Call a fresh page using http (Port 80) or force a fresh copy by using a force reload to get a Status 200 OK
2. Call the same page again in Port 80 (http) with a simple reload to get HTTP Status 304 Not modified
3. Call the page using https (Port 443) and force Status 200 ok with a force reload
4. Reload the page using https and get a Status 304.

I'm using Chrome DevTools to check the headers. Here are the results:

Option 1: Force fresh page, http

HTTP/1.1 200 OK
Date: Fri, 15 Mar 2019 22:00:10 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.5.38
X-Content-Type-Options: nosniff
X-Powered-By: PHP/5.5.38
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=21600
X-Content-Type-Options: nosniff
Content-Language: de
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
Last-Modified: Fri, 15 Mar 2019 22:00:10 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Varnish: 323946989 325583205
Age: 2444
Via: 1.1 varnish-v4
X-Cache: HIT
X-Cache-Hits: 235
Content-Length: 39753
Connection: keep-alive
Accept-Ranges: bytes

Option 2: Reload page, http

HTTP/1.1 304 Not Modified
Date: Fri, 15 Mar 2019 22:00:10 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.5.38
X-Content-Type-Options: nosniff
X-Powered-By: PHP/5.5.38
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=21600
X-Content-Type-Options: nosniff
Content-Language: de
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
Etag: "1552687210-1"
Last-Modified: Fri, 15 Mar 2019 22:00:10 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Varnish: 195923610 325583205
Age: 2616
Via: 1.1 varnish-v4
X-Cache: HIT
X-Cache-Hits: 250
Connection: keep-alive

Option 1: Force fresh page, https

HTTP/1.1 200 OK
Date: Fri, 15 Mar 2019 22:00:10 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.5.38
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=21600
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Powered-By: PHP/5.5.38
X-Drupal-Cache: MISS
X-Content-Type-Options: nosniff
Content-Language: de
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
Etag: "1552687210-1"
Last-Modified: Fri, 15 Mar 2019 22:00:10 GMT
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Varnish: 482447464 325583205
Age: 1410
Via: 1.1 varnish-v4
X-Cache: HIT
X-Cache-Hits: 146
Content-Length: 39753
Accept-Ranges: bytes

Option 4: Page reload, https

HTTP/1.1 304 Not Modified
Date: Fri, 15 Mar 2019 22:00:10 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.5.38
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "1552687210-1"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=21600
Vary: Accept-Encoding

Why is the header in the last request completely different? And how can I check wether the page is really delivered by Varnish?

Answer 1

The header is different because it's a 304 http response, it means the file is not transferred again and delivered from your browser cache directly, so you don't have Varnish headers in it. I don't know however why the first reload without SSL has Varnish headers.

Another thing, you should use Hitch as a ssl proxy, it's a lot better than Apache for this and it's using the PROXY protocols which have several advantages.