That is indeed quite confusing.
➜ ~ curl https://test.stellarguard.me/.well-known/stellar.toml -v
* Trying 188.8.131.52...
* TCP_NODELAY set
* Connected to test.stellarguard.me (184.108.40.206) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=sni217501.cloudflaressl.com
* start date: Sep 23 00:00:00 2018 GMT
* expire date: Apr 1 23:59:59 2019 GMT
* subjectAltName: host "test.stellarguard.me" matched cert's "*.stellarguard.me"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f9fa3807000)
> GET /.well-known/stellar.toml HTTP/2
> Host: test.stellarguard.me
> User-Agent: curl/7.54.0
> Accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Mon, 15 Oct 2018 06:56:07 GMT
< content-type: text/plain; charset=utf-8
< set-cookie: __cfduid=dbcc28a8c2b1014d7b7bef9e30f4d05d01539586567; expires=Tue, 15-Oct-19 06:56:07 GMT; path=/; domain=.stellarguard.me; HttpOnly; Secure
< vary: Accept-Encoding
< x-powered-by: Express
< access-control-allow-origin: *
< content-disposition: inline
< last-modified: Thu, 04 Oct 2018 03:09:20 GMT
< etag: W/"3f-1663d0d1700"
< via: 1.1 google
< cache-control: public, max-age=86400
< age: 1646
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-content-type-options: nosniff
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 46a0624f58a83319-HKG
* Connection #0 to host test.stellarguard.me left intact
Obviously I am hitting a different PoP compared to you, but I actually think the issue here is that your origin responds to Cloudflare with the old value. The Google App Engine machine that is close to the Cloudflare PoP you are hitting might still have the page in cache.
I am not familiar with Googles platform, perhaps there is an option to invalidate cache at their side as well?
Cloudflare doesn’t add any CF-Cache-Status header to the response, so Cloudflare isn’t caching the request.