在我们 Discourse 网站上进行搜索时，如果我对 /search?q=my search 发起普通的 GET 请求，一切正常。但如果使用搜索框并通过 XHR GET 请求提交搜索，则会返回 406 状态码。
经过进一步的 Postman 测试，我发现只要在请求中添加 X-Requested-With: XMLHttpRequest 头部，问题就会出现；移除该头部后则一切正常。服务器位于 Azure Front Door 之后，绕过它直接访问服务器则不会出现此问题。是 nginx 或搜索功能基于该头部做了特殊处理吗？位于反向代理之后是否会干扰请求？有什么修复建议吗？
您的反向代理绝不应丢弃客户端应用程序设置的任何标头。这可能导致一些明显的错误，也可能导致一些静默的错误，直到为时已晚您才会发现。
我猜应该不是丢弃了请求头，因为其他 XHR 请求都能正常工作。看起来这个请求在 Discourse 中 somehow 与其他请求不同。
您能否在 Meta 上复现同样的错误？
不，因为你不在前门后面。问题是由它经过代理引起的，我只是不知道为什么，因为其他 XHR 请求是正常的。这表明 Discourse 对发送到搜索的请求的处理方式与其他 XHR 请求不同。
Meta 运行在 AWS ALB 反向代理之后，并未出现此问题。
Try 运行在 HAProxy 反向代理之后，也未出现此问题。
大多数自建实例仅使用内部 nginx 反向代理，同样未出现此问题。
这让我怀疑是 Azure Front Door 导致的。这已不是 Azure 产品首次出现 奇怪的故障行为。
此外，我们也有其他 WAF 产品导致 Discourse 故障的经验，因此这些产品不受支持。
我并未使用 WAF 功能。我会看看能否进一步确定它是否以其他方式丢弃了请求头或其他内容。只是很奇怪，它似乎仅影响搜索请求。
上个月我调试的另一款 WAF 产品也曾导致预设回复和草稿保存功能失效。当它影响使用频率较低的功能时，可能需要较长时间才能发现所有不兼容之处。
我进行了进一步测试，发现 FD 似乎确实错误地传递了至少这一个 HTTP 头。我已向他们提交请求以修复此问题。我仍不确定搜索为何会关注此头，但我想还是先把 FD 的 bug 修复为妙。
我们通常建议人们避免选择复杂的配置，除非他们（出于某种原因）有不可更改的硬性要求必须如此。而在这些罕见的情况下，我们希望他们也已预留了预算，以便聘请专家协助管理这种必要的复杂性。