从 EC2 访问时 Google Books API 出现 503 错误
在我的 Amazon EC2 实例上：
~$ curl -XGET https://www.googleapis.com/books/v1/volumes?q=Mark+Twain
{
"error": {
"errors": [
{
"domain": "global",
"reason": "unknownLocation",
"message": "Cannot determine user location."
}
],
"code": 503,
"message": "Cannot determine user location."
}
}
来自我的笔记本电脑的相同请求会产生正确的响应 - JSON 格式的书籍数据。
我做错了什么？是亚马逊的网络配置吗？是谷歌吗？是我吗？了解其他可用区中的 EC2 用户是否会看到此请求的相同错误会有所帮助。
On my Amazon EC2 instance:
~$ curl -XGET https://www.googleapis.com/books/v1/volumes?q=Mark+Twain
{
"error": {
"errors": [
{
"domain": "global",
"reason": "unknownLocation",
"message": "Cannot determine user location."
}
],
"code": 503,
"message": "Cannot determine user location."
}
}
The same request from my laptop yields the proper response -- book data in JSON format.
What am I doing wrong? Is it Amazon's network configuration? Is it Google? Is it me? It would help just to know if EC2 users in other availability zones see the same error for this request.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道这是一个非常古老的问题，但它仍然值得一个答案...
Google 返回上面提到的错误：
当它无法确定您的 IP 所在位置时。它的许多书籍的许可协议都需要了解您所在的位置。
当 IP 因开放代理而位于内部黑名单中时。 EC2 已知用于托管代理，也许您的 IP 的前任所有者已被 Google 标记。
当存在 X-forwarded-for 标头（这将由各种代理附加）时，将使用该 IP。如果这是一个内部 IP（如 10.0.0.1），Google 会抱怨。对于普通 EC2 实例来说，这不应该是问题，因为您有一个用于外部流量的外部 IP 地址，但如果您使用 VPC 或 VPN 执行某些操作，则可能会发生疯狂的情况。
我今天无法为 us-east 重现此错误，但仅在随机可用区中测试了一个实例。
I know this is a very old question, but it still deserves an answer...
Google returns the error named above:
When it cannot determine where your IP is located. Its licensing agreements for many of its books require knowledge of where you are.
When the IP is in an internal blacklist for being an open proxy. EC2 has been known to be used to host proxies, perhaps the previous owner of your IP got tagged by Google.
When an X-forwarded-for header is present (this would be appended by various proxies), that IP is used instead. If that is an internal ip (like 10.0.0.1), Google complains. This should not be an issue for a vanilla EC2 instance, as you have an external IP address for external traffic, but if you are doing something with a VPC or VPN, madness might occur.
I could not reproduce this error for us-east today, but only tested one instance in a random availability zone.