999 Код ошибки в запросе HEAD для LinkedIn

Мы используем curl HEAD-запрос в приложении PHP для проверки достоверности общих ссылок. Мы проверяем код состояния только для того, чтобы убедиться, что ссылка, введенная пользователем, действительна. Ссылки на все веб-сайты преуспели, кроме LinkedIn.

Хотя он работает локально (Mac), когда мы пытаемся выполнить запрос с любого из наших серверов Ubuntu, LinkedIn возвращает код состояния 999. Не API-запрос, просто простой завиток, как мы делаем для каждой другой ссылки. Мы пробовали на нескольких разных машинах и пытались изменить пользовательский агент, но не играли в кости. Как изменить наш завиток, чтобы рабочие ссылки возвращали 200?

Образец запроса HEAD:

curl -I --url https://www.linkedin.com/company/linkedin

Образец ответа на машину Ubuntu:

 HTTP/1.1 999 Request denied Date: Tue, 18 Nov 2014 23:20:48 GMT Server: ATS X-Li-Pop: prod-lva1 Content-Length: 956 Content-Type: text/html 

Откликнуться на @ alexandru-guzinschi немного лучше. Мы пробовали маскировать User Agents. Подводя итог нашим исследованиям:

  • Mac машина + Mac UA => работает
  • Mac машина + Windows UA => работает
  • Удаленный компьютер Ubuntu + (без изменения UA) => сбой
  • Удаленная машина Ubuntu + Mac UA => не работает
  • Удаленный компьютер Ubuntu + Windows UA => не работает
  • Локальная виртуальная машина Ubuntu (на Mac) + (без изменения UA) => сбой
  • Локальная виртуальная машина Ubuntu (на Mac) + Windows UA => работает
  • Локальная виртуальная машина Ubuntu (на Mac) + Mac UA => работает

Итак, теперь я думаю, что они блокируют любые запросы на завивание, которые не предоставляют альтернативный UA, а также блокируют хостинг-провайдеров?

Есть ли другой способ проверить, действительно ли ссылка на linkedin действительна или если она приведет к их странице 404, с компьютера Ubuntu с использованием PHP?

Related of "999 Код ошибки в запросе HEAD для LinkedIn"

Похоже, что они фильтруют запросы на основе пользовательского агента:

 $ curl -I --url https://www.linkedin.com/company/linkedin | grep HTTP HTTP/1.1 999 Request denied $ curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3" -I --url https://www.linkedin.com/company/linkedin | grep HTTP HTTP/1.1 200 OK 

Я нашел обходное решение, важно установить заголовок accept-encoding:

 curl --url "https://www.linkedin.com/in/izman" \ --header "user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36" \ --header "accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" \ --header "accept-encoding:gzip, deflate, sdch, br" \ | gunzip 

Похоже, что LinkedIn фильтрует как пользовательский агент, так и IP-адрес. Я пробовал это как дома, так и с узла Digital Ocean:

 curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3" -I --url https://www.linkedin.com/company/linkedin 

Из дома я получил 200 OK, от DO я получил 999 Denied …

Поэтому вам нужен прокси-сервис, такой как HideMyAss или другой (не проверял его, поэтому я не мог сказать, действительно ли он или нет). Вот хорошее сравнение прокси-сервисов.

Или вы можете настроить прокси-сервер в своей домашней сети, например, использовать малиновый PI для проксирования ваших запросов. Вот руководство по этому поводу.

Прокси-сервер будет работать, но я думаю, что есть другой способ. Я вижу, что от AWS и других облаков, что он заблокирован IP. Я могу отправить запрос с моей машины, и он работает нормально.

Я заметил, что в ответ от облачной службы он возвращает некоторые JS, которые браузер должен выполнить, чтобы перейти на страницу входа. После этого вы можете войти в систему и получить доступ к странице. Страница входа доступна только для тех, кто обращается через заблокированный IP-адрес.

Если вы используете безголовый клиент, который выполняет JS, или, может быть, сразу перейти к следующей ссылке и предоставить учетные данные связанного пользователя, вы можете обойти его.