这个问题是由于 SEO 问题而出现的，但经过进一步研究后，Google 似乎认为 IP/托管位置现在充其量只是一个微弱的排名信号。所以现在我只是好奇，因为我只熟悉基本层面的网络。
我在 europe-west-1 地区托管了多个站点。每个站点都位于分配有外部静态 IP 的计算引擎实例上。我可以对域/IP 进行 ping 操作，然后让我在英国的同事 ping 相同，并且根据响应时间，很明显 IP 最终会在欧洲解决（可能应该在爱尔兰都柏林）。但是相同域/IP 的 DNS 查找列出了加利福尼亚州山景城的 IP？它总是这样出现：xxx.xxx.xxx.xxx.bc.googleusercontent.com。这谷歌是不是像一个 ISP 一样行事，然后到欧洲的路由在幕后？为什么没有一个 IP 在托管实例的数据中心中显示为解析？
【问题讨论】：
标签： dns google-cloud-platform google-compute-engine
听起来您将三个概念混为一谈：
这三个都是独立的。所有 GCE 实例 IP 地址都有一个映射到 xxx.xxx.xxx.xxx.bc.googleusercontent.com 的 reverse DNS entry。此域在 Google 的控制下，因此已注册到山景城的总部。
SWIP record / WHOIS 条目分别表示 IP 地址的管理所有权。它的子网。因此，它也在山景城的总部注册。
这两者都没有反映任何关于将数据包应答到 IP 地址的机器的物理位置，也没有反映关于如何将数据包路由到目的地的决定。
Google 有一个global network。发送到 GCE 实例的数据包将穿越到距离客户端相对较近的 Google 网络。由于 Google 维护了大量的peerings with ISPs worldwide，大多数情况下，您的数据包最终会直接从您的 ISP 到达 Google 的网络。
如果您对实例运行跟踪路由，您可能会在其反向 DNS 名称中看到带有机场代码的跃点，尤其是在遍历对等点时。 Google 内部的跃点通常不会进一步暗示地理位置。
最后，当讨论 IP 地址的“接近度”或位置时，大多数时候相关指标是延迟或到主机的网络距离，而不是地理距离。 （虽然地理距离设置了延迟的下限，因为数据包的速度不能超过光速）
【讨论】：