我们在 europe-west6（苏黎世）部署了一个 Google Cloud Function，它可以对 API 进行 HTTP 调用。在我们的服务器日志中，这些 HTTP 调用源自 IP 地址 35.203.247.36，该地址显示美国为来源。我期待来自瑞士的源 IP 地址。这会导致地理封锁配置出现一些问题。
我发现这个相关线程https://issuetracker.google.com/issues/72263361#comment91，它指出这应该按预期工作，但链接的 IP 范围似乎与我们的观察不同：
{
"ipv4Prefix": "34.65.0.0/16",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "34.104.110.0/23",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "34.124.46.0/23",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.216.128.0/17",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.220.44.0/24",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.235.216.0/21",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.242.44.0/24",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv6Prefix": "2600:1900:4160::/44",
"service": "Google Cloud",
"scope": "europe-west6"
}
为什么我们的 API 调用不是源自这些 IP 范围之一？
因此扩展一些评论：
当您查看到该 IP 的实际流量路由时（例如使用https://he.net的镜子），会显示通过瑞士互联网交换的路由，表明该 IP 地址确实位于瑞士。
观察到的 IP 地址
35.203.247.36属于 Google 分配给 Google Cloud 客户使用的大范围 35.192.0.0 - 35.207.255.255 (35.192.0.0/12) 的一部分。Google 在http://www.gstatic.com/ipranges/cloud_geofeed （JSON 版本）上自行发布了一个地理定位 feed ，但该 feed 不包括他们创建的每个子网，并且不35.203.247.36存在包含更具体区域或位置的子网条目。如果没有更具体的记录，您的 GeoLocation 数据库可能会使用美国加利福尼亚州山景城，因为这是whois 数据中记录的地址。
IP 地址代表网络位置，而不是经度/纬度或街道地址。
虽然通常是一个可用的近似值，但分配给 IP 地址的位置的实际可靠性和准确性在几乎城市街区准确和完全虚构之间存在差异。
考虑一下路由协议允许所有者/运营商几乎立即调整其内部子网划分并更改互联网上可以使用特定 IP 地址（范围/子网）的位置。今天使用特定 IP 地址（范围）的地方不一定是明天使用它的地方。还有任播，其中单个 IP 地址由多个位置的服务器共享。
尽管 IP 地理定位提供商声称其准确性/完整性，但许多此类数据库将用于公司 IP 地址范围中的 IP 地址的街道地址通常会 默认为Whois记录中找到的街道地址。该地址通常是公司总部，而不是数据中心街道地址，也不是（内部子网划分后）实际分配和使用部分 IP 地址空间的（国际）分支机构位置。
甚至提供商也会为您提供准确度指示（例如，Maxmind
1000 km如何显示35.203.247.36 的准确半径与20 km45.79.90.233 的准确半径，以及我家庭 IP 地址的准确位置仅 5 公里），该不确定性或一旦他们的 IP 位置数据被扁平化到基于位置的阻止和允许列表中，（缺乏）准确性的微妙之处就会被完全消除。一般来说，如果可以的话，请在允许列表中使用已知且可信客户端的 IP 地址，而不是根据 IP 地理位置数据授予访问权限。
可以将静态 IP与您的 Google 云功能关联起来，以方便实现：