Facebook Open Graph 无法正常工作；没有链接预览答案

【问题标题】：Facebook Open Graph not working properly; no link previewsFacebook Open Graph 无法正常工作；没有链接预览
【发布时间】：2021-07-01 22:54:13
【问题描述】：

我的 OG 标签有问题。它在 <head> 中正确显示，但 Facebook Open Graph 返回错误响应代码。

这里是网址：https://www.sentosa.com.sg/en/get-inspired/sentosa-guides/mums-recommend-fun-activities-on-sentosa/

<head>
   <title data-react-helmet="true">Mums Recommend: Fun Family Activities On Sentosa</title>
   <meta data-react-helmet="true" property="og:title" content="Mums Recommend: Fun Family Activities On Sentosa"/>
   <meta data-react-helmet="true" name="keywords" content="things to do, fun activities in sentosa, family"/>
   <meta data-react-helmet="true" name="title" content="Mums Recommend: Fun Family Activities On Sentosa"/>
   <meta data-react-helmet="true" name="description" content="It’s true – mothers know best!"/>
   <meta data-react-helmet="true" property="og:description" content="It’s true – mothers know best!"/>
   <meta data-react-helmet="true" property="og:url" content="https://www.sentosa.com.sg/get-inspired/sentosa-guides/mums-recommend-fun-activities-on-sentosa"/>
   <meta data-react-helmet="true" property="og:image" content="https://www.sentosa.com.sg/-/media/sentosa/article-listing/articles/2021/mums-recommended-fun-activities-to-do-in-sentosa/mums_hero.jpg?revision=7e8e6d47-8f17-4686-8cf2-b34dc387a461"/>
   <link data-react-helmet="true" rel="canonical" href="https://www.sentosa.com.sg/get-inspired/sentosa-guides/mums-recommend-fun-activities-on-sentosa/"/>
   <link data-react-helmet="true" rel="shortcut icon" href="https://www.sentosa.com.sg/-/media/sentosa/features/header/favicon-new.png?revision=b492cc89-69c8-448d-a928-15c3e56b2e88"/>
   <script data-react-helmet="true" async="true" src="https://assets.wogaa.sg/scripts/wogaa.js"></script>
   <meta charset="utf-8"/>
   <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
   <meta name="viewport" content="width=device-width,initial-scale=1,shrink-to-fit=no"/>
   <meta name="theme-color" content="#000000"/>
   <script async src="https://www.googletagmanager.com/gtag/js?id=DC-8858992"></script><script>function gtag(){dataLayer.push(arguments)}window.dataLayer=window.dataLayer||[],gtag("config","DC-8858992")</script>
   <link href="/dist/sentosa/static/css/main.24239852.chunk.css" rel="stylesheet">
</head>
<body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-536FZZK" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
   <div id="root">
   <style data-styled="bhTETV gthcLv jWNKzs ffTmSH gzHAtR gXecBG bzgUGP cOeqpc kdJMol eUYsaW kHNbps ftjTQW stNPD cTYkaX eXgrYR kvnZyw dUFPwu dfcRpc kZrfbx cNdvkR fXtlEt PaNCb" data-styled-version="4.4.1">

【问题讨论】：

您的服务器正在以 503 Service Unavailable 响应响应 Facebook（它可能响应 Twitter，就像我无法获得要验证的卡一样）。我通过 Facebook 的用户代理 facebookexternalhit/1.1 和 Twitter 的 Twitterbot/1.0 使用 Rex Swain viewer 访问了您的 URL - 两者都有效。消息应用程序 KakaoTalk 能够访问您的 OG 信息并发送丰富的链接预览。您可以与您的主机核实，因为这似乎是您的主机阻止某些机器人的问题。 一个不相关的注释 - 你的 head 标签应该在 html 标签之后。
谢谢里奇。会让我们的开发人员对此进行调查。此问题仅在我们为整个站点实施 Azure Front Door 时发生。不确定这是否是导致此问题的原因，

标签： facebook-opengraph

【解决方案1】：

我有 same problem with Azure Front Door - 该问题似乎是由 Accept-Encoding 和 Range 标头的组合引起的 - 这会导致 Front Door 返回 503 响应，即使后端服务器能够提供响应。

我的解决方案是创建一个规则引擎规则，如果还有 Range 标头，则删除 Accept-Encoding 标头。这可确保爬网站点仍能获得正确的 200 或 206 响应，其负载不超过其规定的要求。

以下规则适用于我们测试的社交分享工具（主要是 Facebook、WhatsApp、Twitter、LinkedIn）：

IF
  Condition: "Request header"
  Header name: "Range"
  Operator: "Any"
AND IF
  Condition: "Request header"
  Header name: "Accept-Encoding"
  Operator: "Contains"
  Header value: "gzip"
  Transform: "To lowercase"

THEN
  Action: "Request header"
  Operator: "Delete"
  Header name: "Accept-Encoding"

编辑以添加

这最近停止了对我们的工作，结果证明是因为我们的服务器返回了不一致的缓存标头。

当cache-control标头内部一致时，一切正常，例如：

可缓存页面：Cache-Control: public, max-age=1322 要么不可缓存页面：Cache-Control: no-store, no-cache

但是有些页面正在返回：

Cache-Control: public, no-store, max-age=1800

对于正常请求（即 Front Door 没有缓存页面）似乎“按预期”工作，但是当使用 Range 标头（带有或不带有 Accept-Encoding 标头）请求时，我们开始看到再次出现503错误。更正缓存控制标头解决了带有 range 标头的 503。

【讨论】：

– 我看到了您对 Microsoft 的问题和 Sai Kishor 对它发生原因的解释（当请求包含范围标头时，Front Door 会向源站两次或更多次以确认请求 - 如果请求未得到确认，Front Door 以 503 响应）。您是否能够创建一个规则来处理包含范围标头的所有请求，或者您是否必须为 Facebook 和 LinkedIn（以及 WhatsApp 和任何其他想要创建丰富链接预览的应用程序）创建单独的规则？
@RichDeBourke 更新了我们正在使用的单一规则 - 通过基于问题标头，它不需要关心用户代理，这意味着如果新的用户代理开始在同样的方式，他们仍然会收到正确的请求。仅仅因为用户代理接受 gzip 编码并不意味着您必须尊重它。
感觉我在这里绕圈子——这条规则最近对我们不起作用——请求带有 Range 标头的缓存页面会导致 Front Door 出现 503 错误，但我无法删除请求中的范围标头。
@Zhaph-BenDuguid 我也面临同样的问题。有什么解决办法可以分享吗？
@DANLEE - 当我们停止发布冲突的缓存控制标头时，重复的问题得到了解决。