logo标签列表

在向LinkedIn发送HEAD请求时出现999错误代码

phpcurllinkedin-api
54

我们在一个PHP应用程序中使用curl HEAD请求来验证通用链接的有效性。我们只检查状态码，以确保用户输入的链接有效。所有网站的链接都成功了，除了LinkedIn。

虽然它在本地（Mac）似乎可以工作，但当我们尝试从任何Ubuntu服务器发出请求时，LinkedIn返回999状态代码。这不是API请求，只是像我们为每个其他链接所做的简单curl请求。我们尝试在几台不同的机器上和尝试改变用户代理，但没有成功。我该如何修改我们的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机器+Mac UA => 可以 - Mac机器+Windows UA => 可以 - Ubuntu远程机器+（未更改UA）=> 失败 - Ubuntu远程机器+Mac UA => 失败 - Ubuntu远程机器+Windows UA => 失败 - 位于Mac上的Ubuntu本地虚拟机+（未更改UA）=> 失败 - 位于Mac上的Ubuntu本地虚拟机+Windows UA => 可以 - 位于Mac上的Ubuntu本地虚拟机+Mac UA => 可以 所以现在我想他们会阻止任何未提供备用UA的cURL请求，也会阻止托管提供者？
从一个Ubuntu机器上使用PHP，还有其他方法可以检查链接到LinkedIn的链接是否有效或是否会导致其404页面吗？
很有可能他们已经将托管公司列入黑名单，以迫使它们使用API。 - ceejayoz
当您通过命令行浏览器（如lynx）加载链接时会发生什么？是否会出现相同的HTTP错误？ - RichardBernards
我使用curl和wget得到999的错误，但是在同一IP下elinks可以正常工作。我的猜测是他们以某种方式检测到了curl和wget。 - Gerald Schneider
@ceejayoz 我们尝试了几家不同的托管公司，包括一些较小的精品公司。我想下一步是使用Virtual Box Ubuntu来查看它是否与操作系统有关，或者他们只是阻止了大量托管提供商的IP地址块。 - charltoons
@charltoons - 有更新吗？你已经搞定了吗？如果是，怎么实现的？ - Pramod Shinde
显示剩余2条评论
4个回答
24

看起来它们根据用户代理筛选请求：

$ 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
我们尝试更改用户代理，但是我们的响应如下：[Mac机器+ Mac UA => 正常工作] [Mac机器+ Windows UA => 正常工作] [Ubuntu机器+ Ubuntu UA => 失败] [Ubuntu机器+ Mac UA => 失败] [Ubuntu机器+ Windows UA => 失败]目前无法访问Windows机器，所以对此不确定。 - charltoons
1
@charltoons 这很奇怪，因为我刚才尝试了一下使用当前Chrome的UA curl -A "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36" -I --url https://www.linkedin.com/company/linkedin | grep HTTP 在我的Ubuntu上返回了 HTTP/1.1 200 OK。也许你使用了一个旧的（或不正确的）UA被他们阻止了？请使用我使用的UA进行新的测试。 - Alexandru Guzinschi
2
他们过滤了用户代理和IP地址。因此，您需要一种有效的代理地址。 - olefrank
1
这个答案可能是正确的，但在尝试解决如何检查领英链接时并不真正有帮助。提供虚假的用户代理并不是我想做或建议给别人的事情。我认为机器人和链接检查器应该正确地识别自己并提供联系信息。这就是我用我的链接检查器所做的。 - Sybille Peters
我使用用户代理标头时遇到了“HTTP 999”错误。 - Parzival
显示剩余3条评论
14

我找到了解决方法，设置"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
3
这是每天大约限制在30-50个请求左右。如果超过这个数量，您将被阻止。 - olive_tree
5

看起来 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（DigitalOcean）访问时，我却得到了999 Denied的状态码...

因此，您需要像HideMyAss这样的代理服务，或者其他代理服务（我没有测试过，无法确定其是否有效）。这里有一个很好的代理服务比较。

或者您可以在家庭网络上设置代理，例如使用Raspberry PI来代理您的请求。这里有一份指南。

1
代理对于小项目是可行的解决方案，但很遗憾这并不适用于较大的 Web 应用程序。我们以这种方式验证数千个链接每小时。恐怕我们无法代理所有这些请求。此外，LinkedIn URL 仅占其中的一小部分。 - charltoons
光是使用代理不足以解决问题。我们尝试了HMA代理，但LinkedIn仍然会屏蔽URL到实际Chrome中的个人资料页面。即使在FireFox中更换IP、清除所有cookie和历史记录并请求其他个人资料页面，LI仍然响应999并重定向到登录页面。也许他们知道并屏蔽了HMA IP范围？ - Denis Stepanenko
4
代理可能可行，但我认为有另一种方法。我发现从AWS和其他云平台访问被IP拦截时，可以从我的机器发出请求，并且可以正常工作。
我注意到云服务返回的响应包含一些JS，需要浏览器执行才能跳转到登录页面。一旦登录成功，就可以访问该页面。登录页面仅供那些通过被阻止IP访问的用户使用。
如果您使用一个执行JS的无头客户端，或者直接前往下一个链接并提供Linkedin用户的凭据，可能可以绕过此问题。
尝试了这个。大约登录20次后，您将在登录后收到“我们正在清理事务。我们会回来”的消息。 - olive_tree
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接