您好，
我最近已将我的 Discourse 实例从 Discourse/2.9.0.beta3 升级到最新的 Discourse/2.9.0.beta14 版本。
Discourse 网络钩子事件现在已停止工作。
这是配置：
payload URL：http://server-name:port/rest：这是我们定义的内部 rest API 服务。
当我尝试保存此值时，会收到以下错误：
“发生错误：Payload URL 无法使用，因为它解析为被阻止或内部 IP 地址”
在 Discourse/2.9.0.beta3 Discourse 版本中，payload URL：http://server-name:port/rest 的相同值曾经可以正常工作。
这是最新版本的 Discourse 中有更新，还是这是一个 bug？
请告知。提前致谢。
这听起来不对。如果 Discourse 是自托管的，webhooks 的 payload URL 确实可能是内部资源。不确定为什么您想阻止配置用于处理 webhook 的内部解析的 URL 或地址。似乎有一个更改是为了防止用户个人资料中出现无效/错误的网站 URL。该更改是否已渗入 webhook payload URL 的验证中？
因为这也可能是一个安全问题，Discourse 管理员可以使用 webhook 来发现或攻击不属于他们的网络上的内部资源？
是的，已将此移至 Feature，可用于钓取有关内部网络的信息。有一些旋钮可以调整特定实例的行为。
我们的自托管实例也受到了影响。我们希望只在内部 Docker 网络上托管接收 webhook 的服务；无需从外部访问。
是否有办法允许内部 webhook？
如果我理解正确的话，内部 webhook 是不允许的，这样一来，没有服务器管理员权限的 Discourse 管理员就无法窥探网络内部。但这在我们的自托管实例上不成问题；我们的 Discourse 管理员无论如何都会了解我们的内部结构。
我建议在 app.yml 配置中添加一个设置来允许内部 webhook，或者提供一个内部域/IP 白名单。这样，服务器管理员（而不是 Discourse 管理员）就可以控制谁可以使用内部网络的 webhook。
我发现了一个设置，允许解除对特定内部主机的阻止，并且该设置被SSRF保护机制所尊重，而SSRF保护机制正是导致WebHooks被阻止的原因：
使用 allowed_internal_hosts 设置来指定允许在您的Webhook中使用的内部主机名。