这个问题乍一看似乎更适合用 stackoverflow 来解决，但我怀疑存在一个我无法诊断的底层服务器问题。我只是不确定哪里出了问题。我们的站点托管在 Amazon EC2 实例上，我们使用 Route 53 名称服务器。我们站点上的 Facebook 登录已经正常工作了一段时间，但突然停止工作了。我们收到的错误是“不允许给定的 URL”。在 Facebook 上的应用程序设置中，所有域 URL 都输入正确，传递给 Facebook 的登录 URL 看起来是正确的。查看 stackoverflow 时，我看到一些帖子建议在域名中添加或删除“www”，但都不起作用。
我昨天确实更改了我们服务器的 SSH 密钥，但 SSH 工作正常，我看不出这有什么关系。我只是因为时间关系才提起这件事。
我认为这是服务器问题，因为几周前我们遇到了另一个问题，我们的内部 ajax 请求突然被视为跨域请求。我通过将 ajax URL 更改为相对 URL 解决了这个问题。由于这两个问题似乎都源于我们的域名无法识别，所以我认为它们可能相关，而且有更大的问题正在发生。我们网站上有一个 cookie，允许用户保持登录状态长达一个月，因此登录问题在 ajax 问题发生后大约一个月开始出现是有道理的。
输入 URL 时，网站没有任何问题，因此 DNS 没有明显问题。我们的域名已在 godaddy 注册，我已仔细检查了那里的名称服务器，它们与我们在 Route 53 中的名称服务器相匹配。
在 ajax 问题开始出现之前不久，我尝试将我们在 godaddy 注册的另一个域名设置为指向与第一个域名相同的名称服务器。这没有奏效，当 ajax 问题开始出现时，我将该域名的 godaddy 设置改回了默认设置。自从我改回它们已经过去了几个星期，但我想知道是否还有其他事情可能需要做来传播重置，如果它甚至相关的话。
我意识到这有点开放式，但我希望有人认识到这些症状有一个共同的原因，而此时我不确定下一步该检查什么。
服务器上确实有一个 .htaccess 文件，但我认为这不是问题所在。以下是我目前在其中的内容。
RewriteEngine on
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]
# Block Bad Bots & Scrapers
SetEnvIfNoCase User-Agent "Aboundex" bad_bot
SetEnvIfNoCase User-Agent "80legs" bad_bot
SetEnvIfNoCase User-Agent "360Spider" bad_bot
...
<Limit GET POST HEAD>
Order Allow,Deny
Allow from all
# Cyveillance
deny from 38.100.19.8/29
deny from 38.100.21.0/24
deny from 38.100.41.64/26
deny from 38.105.71.0/25
deny from 38.105.83.0/27
deny from 38.112.21.140/30
deny from 38.118.42.32/29
deny from 65.213.208.128/27
deny from 65.222.176.96/27
deny from 65.222.185.72/29
Deny from env=bad_bot
</Limit>
答案1
通过在应用程序设置的“高级”选项卡中删除白名单 IP，问题得以解决。我把服务器的 IP 地址放在那里，以为这就是目的，但删除它会导致 URL 被允许。我猜那个字段一定是为了在测试期间限制只有某些用户 IP 才能访问应用程序。