In some cases, Authoritative Name Servers give IPs that can’t be used to access AMP cache.
$ dig ampproject.org NS
…
;; ANSWER SECTION:
ampproject.org. 43200 IN NS ns3.google.com.
ampproject.org. 43200 IN NS ns1.google.com.
ampproject.org. 43200 IN NS ns4.google.com.
ampproject.org. 43200 IN NS ns2.google.com.
…
$ dig @ns3.google.com +tcp +subnet=240e:c2:1800::/48 cdn.ampproject.org
…
; ANSWER SECTION:
cdn-china.ampproject.org. 300 IN A 203.208.40.34
cdn.ampproject.org. 300 IN CNAME cdn-china.ampproject.org.
…
$ curl -I https://cdn.ampproject.org/c/s/snowflake-broker.torproject.net/index.html \
-H 'Host: snowflake--broker-torproject-net.cdn.ampproject.org' \
--connect-to '::203.208.40.34:'
HTTP/2 404
date: …
content-type: text/html; charset=UTF-8
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
So perhaps, snowflake-broker.torproject.net was recently added to a China-specific blocklist at cdn-china.ampproject.org. I tried to check if cdn-china.ampproject.org works for any pages, but it was inconclusive. I also got a 404 for a www.cbc.ca page. But that might be censored anyway.
According to a thread on V2EX, sometime before 2017-01-22 UTC+8 cdn.ampproject.org became inaccessible in China, and these special servers could not be used to access any AMP Cache at the beginning.
( archive )
@cypherpunks, are you saying that if you use one of the functional IPs, then Snowflake ampcache rendezvous works for you? Or are you saying that, even if the IP is otherwise functional for AMP Cache purposes, it doesn’t work for Snowflake ampcache rendezvous? Do the curl commands with --resolve behave differently for you??
I guess that two or more users commented on this issue via Anon-Ticket . 