После исследования я обнаружил, что много людей сталкиваются с одной проблемой. Но пока я не решаю, это произошло после того, как я переключил свой сервер на linode.com
давайте возьмем пример. www.acemark2u.com является одним из сайтов, размещенных под linode-сервером, когда я пытаюсь отлаживать https://developers.facebook.com/tools/debug/og/object/ , он просто не мог получить информацию о царапинах правильно, и если я попытаюсь с одной из страниц www.acemark2u.com/about-us, это просто покажет мне ошибку «Ошибка анализа входного URL-адреса, данные не были кэшированы или данные не были очищены».
происходят странные вещи. при попытке отладки с использованием IP-адреса 106.187.35.114/~acemark2 все идет гладко. красиво, без ошибок 404 для страниц.
Я подозреваю, что это может быть вызвано функцией «gethostbyaddr» (ref: http://www.gearhack.com/Forums/DisplayComments.php?file=Computer/Network/Internet/Preventing_Your_Web_Server_From_Blocking_Facebook_Share ), но до сих пор у меня нет решений.
Для людей, которые испытывают одну и ту же проблему, но по разным причинам, я обнаружил несколько интересных фактов о том, как Facebook «царапает» страницы, проверяя журналы сервера при выполнении некоторых испытаний.
Прежде всего: если вы никогда не пытались поделиться страницей с FB, FB никогда не пыталась ее очистить, и она не будет пытаться это сделать, если вы только поместите URL-адрес в инструмент Debug . Это первая причина, потому что вы получаете ошибку: она просто заявляет, что FB не имеет информации на странице, вы должны «заставить» ее очистить страницу.
В первый раз, когда вы пытаетесь поделиться страницей, FB сбрасывает ее (запрашивает у вашего сервера первые 40k страницы и анализирует теги opengraph). Что может случиться, так это то, что вы не видите изображение: Facebook Share Dialog не отображает миниатюры с первой загрузкой
Причина в том, что FB за кулисами по-прежнему очищает вашу страницу и кэширует изображение. В следующий раз, на самом деле, у вас есть и изображение. Как его решить? Предварительное кэширование: https://developers.facebook.com/docs/sharing/best-practices#precaching
или просто добавить
<meta property="og:image:width" content="450"/> <meta property="og:image:height" content="298"/> Я нашел решение наконец.
В моей записи по умолчанию DNS A / AAAA я не удалял эти несколько ip
2400:8900::f03c:91ff:fe73:a95d Default mail 2400:8900::f03c:91ff:fe73:a95d Default www 2400:8900::f03c:91ff:fe73:a95d Default
поэтому некоторые пользователи указывают на указанный выше IP-адрес при доступе через соответствующий веб-адрес.
Этот вопрос уже принял ответ, но в случае, если этот ответ не работает для кого-либо, это то, что сработало для меня.
URL, который я предоставил в og:url адресе og:url был защищен URL-адресом, т. Е. Только те пользователи могут просматривать страницу, указанную URL-адресом, которые вошли в систему. Когда я изменил URL-адрес, чтобы указать на мою домашнюю страницу, которую можно просмотреть как подписанными, так и подписанными пользователями, а именно. http://www.ercafe.com все работало нормально.
У нас была аналогичная проблема на одном из наших сайтов.
Мы решили это, отключив apache mod_security, в то время как мы используем инструмент отладки объекта facebook для «получения новой информации о царапинах»,
Для меня решение заменило записи DNS A
example.sk 3600 1.2.3.4 www.example.sk 3600 1.2.3.4
в
example.sk 3600 1.2.3.4 *.example.sk 3600 1.2.3.4