向 LinkedIn 请求 HEAD 时出现 999 错误代码答案

【问题标题】：999 Error Code on HEAD request to LinkedIn向 LinkedIn 请求 HEAD 时出现 999 错误代码
【发布时间】：2020-03-12 03:04:47
【问题描述】：

我们在 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 => 失败
Ubuntu 本地虚拟机（在 Mac 上）+（无 UA 更改）=> 失败
Ubuntu 本地虚拟机（在 Mac 上）+ Windows UA => 工作
Ubuntu 本地虚拟机（在 Mac 上）+ Mac UA => 工作

所以现在我认为他们会阻止任何不提供备用 UA 的 curl 请求并且也阻止托管服务提供商？

有没有其他方法可以从使用 PHP 的 Ubuntu 机器检查到linkedin 的链接是否有效，或者是否会导致他们的 404 页面？

【问题讨论】：

他们可能已将托管公司列入黑名单以强制他们使用 API。
当您通过像 lynx 这样的命令行浏览器加载链接时会发生什么？同样的 HTTP 错误？
我用 curl 和 wget 得到 999，但 elinks 从同一个 ip 工作。我的猜测也是他们以某种方式检测到 curl 和 wget。
@RichardBernards 与 lynx 相同 999。
@ceejayoz 我们尝试了一些不同的托管公司，包括一些较小的精品店。我想下一步是 Virtual Box Ubuntu，看看它是否与操作系统有关，或者他们刚刚阻止了一大堆托管服务提供商的 IP 块。

标签： php curl linkedin

【解决方案1】：

看起来他们根据用户代理过滤请求：

$ 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 这很奇怪，因为我现在尝试使用 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 运行新测试。
这适用于我的虚拟机，但在远程/服务器上失败。有关完整的试验矩阵，请参见上文。请问你是在远程机器上尝试吗？如果是，是哪个提供者？
@charltoons 不，测试是在我的本地机器上进行的。如果您确定您（或某个“邻居”，如果您共享 IP）没有发出足够的请求，那么您可能会受到限制（如果我在 24 小时后清除这些请求没记错），很可能他们对您的 IP 范围有一些限制。
他们过滤用户代理和IP地址。所以你需要某种有效的代理地址。

【解决方案2】：

我找到了解决方法，设置接受编码头很重要：

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

【讨论】：

这限制在大约 30-50 个请求/天左右。之后你会被屏蔽。

【解决方案3】：

似乎 LinkedIn 过滤了用户代理和 IP 地址。我在家里和数字海洋节点都试过这个：

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 或其他的代理服务（没有测试过，所以我不能说它是否有效）。 Here 是代理服务的一个很好的对比。

或者您可以在家庭网络上设置代理，例如使用 Raspberry PI 代理您的请求。 Here 是这方面的指南。

【讨论】：

代理是小型项目的可行解决方案，但不幸的是，这适用于较大的 Web 应用程序。我们以这种方式每小时验证数千个链接。恐怕我们无法代理所有这些请求。此外，LinkedIn 网址仅占其中的一小部分。
仅代理是无济于事的。我们尝试了 HMA 代理，但 LinkedIn 仍会阻止来自实际 Chrome 的个人资料的 URL。在更改 IP、清除 FireFox 中的所有 cookie 和历史记录并请求其他配置文件后，LI 仍然以 999 响应并重定向到登录页面。也许他们知道并阻止了 HMA IP 范围？

【解决方案4】：

代理可以工作，但我认为还有另一种方法。我从 AWS 和其他云中看到它被 IP 阻止了。我可以从我的机器发出请求，它工作得很好。

我确实注意到，在云服务的响应中，它返回了一些 JS，浏览器必须执行这些 JS 才能将您带到登录页面。在那里，您可以登录并访问该页面。登录页面仅供那些通过被阻止的 IP 访问的人使用。

如果您使用执行 JS 的无头客户端，或者直接进入后续链接并提供linkedin 用户的凭据，则可以绕过它。

【讨论】：

试过这个。大约 20 次登录后，您会收到一条“我们正在清理东西”。登录后我们会回来的消息。