999 Код ошибки при запросе HEAD к LinkedIn
Мы используем запрос curl HEAD в приложении PHP для проверки правильности родовых ссылок. Мы проверяем код состояния только для того, чтобы убедиться, что введенная пользователем ссылка действительна. Ссылки на все сайты успешно, кроме LinkedIn.
Кажется, что он работает локально (Mac), когда мы пытаемся выполнить запрос с любого из наших серверов Ubuntu, LinkedIn возвращает код состояния 999. Не запрос API, просто простой завиток, как мы делаем для любой другой ссылки. Мы пробовали на нескольких разных машинах и пытались изменить пользовательский агент, но не играли в кости. Как мне изменить наш curl, чтобы рабочие ссылки возвращали 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 немного лучше. Мы попытались замаскировать агентов пользователя. Подводя итоги наших испытаний:
- Mac machine + Mac UA => работает
- Mac машина + Windows UA => работает
- Удаленная машина Ubuntu + (без смены UA) => терпит неудачу
- Удаленная машина Ubuntu + Mac UA => терпит неудачу
- Удаленная машина Ubuntu + Windows UA => терпит неудачу
- Локальная виртуальная машина Ubuntu (на Mac) + (без изменений UA) => терпит неудачу
- Локальная виртуальная машина Ubuntu (на Mac) + Windows UA => работает
- Локальная виртуальная машина Ubuntu (на Mac) + Mac UA => работает
Так что теперь я думаю, что они блокируют любые запросы curl, которые не предоставляют альтернативный UA и также заблокировать хостинг провайдеров?
Есть ли другой способ проверить, является ли ссылка на linkedin действительной или приведет ли она к их странице 404 с компьютера с Ubuntu, использующего PHP?
Решение
Похоже, они фильтруют запросы на основе агента пользователя:
$ 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 ОК, от DO я получил 999 Отказано …
Так что вам нужен прокси-сервис, такой как HideMyAss или другой (не проверял, поэтому я не могу сказать, действительно ли это или нет). Вот хорошее сравнение прокси сервисов
Или вы можете настроить прокси в вашей домашней сети, например, использовать Raspberry PI для прокси-запросов. Вот это руководство по этому вопросу.
Прокси будет работать, но я думаю, что есть и другой способ. Я вижу, что из AWS и других облаков он заблокирован IP. Я могу выдать запрос с моей машины, и он работает просто отлично.
Я заметил, что в ответе облачного сервиса он возвращает JS, который должен выполнить браузер, чтобы перейти на страницу входа. Оказавшись там, вы можете войти и получить доступ к странице. Страница входа предназначена только для тех, кто получает доступ через заблокированный IP-адрес.
Если вы используете безголовый клиент, который запускает JS, или, возможно, перейдете по следующей ссылке и предоставите учетные данные пользователя с вопросом, вы сможете его обойти.