我已经设置了一个 HTTP(S) 负载平衡器并激活了 Cloud CDN。它位于仅包含 1 个实例的实例组前面，该实例位于澳大利亚东南部。
连接到 CDN IP 确实会将用户路由到最近的 POP。然而，我面临的挑战是，当缓存未命中发生时，从 CDN 返回 VM 的路径似乎有相当长的延迟，然后会传递给用户，这在某种程度上违背了目的。
来自 VM 的 ping 输出：
tristan@tabletop-web:~$ ping 35.227.XX.XX
PING 35.227.XX.XX (35.227.XX.XX) 56(84) bytes of data.
64 bytes from 35.227.XX.XX: icmp_seq=1 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=2 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=3 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=4 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=5 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=6 ttl=48 time=128 ms
64 bytes from 35.227.XX.XX: icmp_seq=7 ttl=48 time=128 ms
^C
--- 35.227.XX.XX ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6006ms
rtt min/avg/max/mdev = 128.099/128.237/128.506/0.231 ms
我原以为 VM 和 CDN 之间的延迟会小于 1 毫秒，就像从同一物理位置的另一个 VM（不同的提供商）连接时一样：
tristan@syd:~$ ping 35.227.XX.XX
PING 35.227.XX.XX(35.227.XX.XX) 56(84) bytes of data.
64 bytes from 35.227.XX.XX: icmp_seq=1 ttl=56 time=1.06 ms
64 bytes from 35.227.XX.XX: icmp_seq=2 ttl=56 time=1.06 ms
64 bytes from 35.227.XX.XX: icmp_seq=3 ttl=56 time=1.04 ms
64 bytes from 35.227.XX.XX: icmp_seq=4 ttl=56 time=1.04 ms
64 bytes from 35.227.XX.XX: icmp_seq=5 ttl=56 time=1.03 ms
64 bytes from 35.227.XX.XX: icmp_seq=6 ttl=56 time=1.08 ms
64 bytes from 35.227.XX.XX: icmp_seq=7 ttl=56 time=1.11 ms
64 bytes from 35.227.XX.XX: icmp_seq=8 ttl=56 time=1.05 ms
--- 35.227.XX.XX ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7006ms
rtt min/avg/max/mdev = 1.038/1.063/1.113/0.036 ms
tristan@syd:~$
有没有人经历过这种情况并知道解决方案？
干杯