如何检查代理是否正常工作（以及它为什么会停止工作）

昨天还能用的代理服务器今天可能完全失效了——这就是免费且公开获取的代理服务器的本质。与其在任务进行到一半时才发现这一点，不如花点时间了解代理为什么会停止工作、正常运行时间和响应时间数字的实际含义，以及如何在依赖它之前确认代理确实处于活动状态。本文将涵盖所有这三个方面。

为什么代理会停止工作

免费代理通常运行在共享、无人管理或重新利用的基础设施上，背后没有任何服务协议，因此一个正常工作的代理变死代理有几个常见原因：

• 服务器离线。 运营者将其关闭、崩溃，或者其托管服务直接过期。
• 服务器过载。 免费代理被所有找到它的人共享，并发用户过多会导致超时或拒绝新连接。
• IP 被重新分配或重新配置。 IP 可能被完全用于其他用途，从而关闭了原本充当代理的端口。
• 开始阻止自动化检查。 某些代理被配置为拒绝看似机器人或扫描器的流量，这会使一个本来正常的代理在检查器中显示为死代理。
• 目标网站开始专门阻止它。 代理在总体上可能是完全可访问的，而某个特定网站在检测到来自它的异常流量后，已将其 IP 加入黑名单。

这并不意味着免费代理总体上不可靠——这意味着任何单独的代理都有有限且不可预测的寿命，这正是本网站的列表每 15 分钟自动更新一次而不是显示静态快照的原因。

代理不工作的征兆

在寻找专用检查器之前，有几个现象值得自行识别：

• 页面超时或通过代理加载永远无法完成。
• 连接被立即拒绝，而不是超时。
• 响应返回了，但看起来根本没有通过代理（你的真实 IP 暴露了）。
• 间歇性工作——有时连接，有时不连接——这通常表明服务器过载，而不是完全挂掉。
• 请求成功，但与正常浏览相比返回异常缓慢，暗示服务器正承受来自其他用户的沉重负载。

运行时间和响应时间的实际测量内容

在本网站的 代理列表 上，每个条目都显示两个实时指标，在依赖它们之前了解这些指标非常有用。运行时间（Uptime）是该代理成功响应的最近检查的百分比——运行时间为 90% 的代理最近很可靠，而 20% 的代理失败频率远高于成功频率。响应时间（Response time）是最近一次成功连接花费的时间（以毫秒为单位）——数值越低越快。列表中默认的“最快响应”排序并不单纯追逐最低响应时间；它首先将运行状况良好的代理（绿色或琥珀色）排在不可靠的代理前面，然后才在该组内按速度排序，因为一个失败率达一半的极速代理实际上并不是好选择。

如何手动检查代理

最简单的手动测试是在浏览器中配置代理（请参阅 如何在电脑和手机上设置代理）并访问 IP 查询网站——如果显示的地理位置和 IP 与代理匹配而不是你自己的连接，说明它正在工作。这对于检查单个代理很好，但如果你有不止一两个要测试，它就很慢且完全是手动的，而且它不会提供可用于比较候选者的响应时间数据。

如何使用代理检查器批量检查代理

对于单个代理之外的任何需求，专用检查器要快得多：本网站上的 代理检查器 工具允许你一次性粘贴整个列表（每批最多 30 个），选择列表使用的协议和格式，它就会并行连接每一个代理，通常只需几秒钟即可完成。无需安装，无需帐户，提交的任何内容事后都不会被存储。

使用方法：粘贴你的代理（每行一个），选择它们是 HTTP、HTTPS、SOCKS4 还是 SOCKS5，选择与你的列表匹配的格式（纯 host:port，或包含凭据的格式之一，如 host:port:username:password），然后点击“检查代理”。每一个代理都通过到实时端点的真实连接进行测试，而不仅仅是 ping 或端口开放检查——这很重要，因为代理的端口技术上可能是开放的，而代理本身却配置错误或拒绝实际转发流量。

理解结果

每个被检查的代理都会返回以下两种状态之一：

• 活动（Alive）： 检查器成功通过它完成了真实请求。显示的 IP、国家和城市是直接从该响应中读取的——这是代理当前实际的出口点，而不仅仅是列表声称的内容。
• 死（Dead）： 连接失败、超时或未返回可用响应。这并不一定意味着代理永远消失了——它可能是暂时过载——但这意味着你现在不应该依赖它。

检查器还会报告每个活动代理的响应时间（以毫秒为单位），一旦你知道哪些代理真正可用，这就可以兼作按速度对批次进行排序的快捷方式。如果一个你期望工作的代理返回为死代理，在彻底放弃它之前，值得在一两分钟后再试一次——暂时过载的服务器可以恢复，而真正离线的服务器则不会。

自动化重复检查

如果你经常使用相同的代理轮换，在浏览器中逐个检查很快就会变得乏味——即使是基于网页的代理检查器每次也需要手动访问。对于需要按计划验证代理的工作流程（例如在每次抓取运行之前），底层思想是可以通过编程实现的：通过每个代理向已知端点发送真实请求，设置较短的超时时间，并将成功的响应视为“活动”，将超时或错误视为“死”。大多数 HTTP 客户端库（在你用于自动化的任何语言中）都支持直接通过代理路由请求，这使得构建一个小型脚本变得很简单，该脚本检查一批代理并只保留响应的代理——这与代理检查器工具运行的逻辑完全相同，只是连接到你自己的管道而不是浏览器。

常见问题的快速解答

为什么我还能通过代理浏览网页时，检查器却说代理已经死了？

这通常意味着代理间歇性过载——能够处理某些请求，但无法处理检查器发送的特定请求，或者在检查器更严格的时间限制下超时。稍等片刻后再试一次。

代理可以是“活动的”但仍然使用不安全吗？

是的——“活动”只证实它目前成功转发流量，并不代表是谁在运营它或它有多值得信赖。无论其状态如何，请将每个免费代理视为未经验证的代理，并避免通过其中任何一个进行敏感登录或付款。

快速的响应时间能保证是好代理吗？

并非必然——代理可能速度快但不可靠（运行时间低），或者速度快但地理位置不符合你的需求。请将响应时间与运行时间和位置结合起来检查，而不是孤立地看。

我应该多久重新检查一次经常使用的代理？

鉴于免费代理状态变化的速度之快，每次使用前检查是最安全的。如果你反复依赖同一个代理，至少每天重新检查一次。

死代理值得以后再试一次吗?

通常是的。因暂时过载而检查失败的代理可能会在几分钟或几小时内恢复，因此对对你很重要的代理进行重新测试是合理的，而不是在单次检查失败后就永久丢弃它——只是不要构建依赖于任何特定代理长期保持可用的工作流程。

检查器会减慢或影响代理本身吗？

不会——检查是一个轻量级的单个请求，相当于通过代理加载一个小页面。它对代理的影响不会超过任何其他简短的正常使用。

获得可靠结果的最佳做法

1. 每次会话前重新检查，而不仅仅是一次。 代理的状态可能会在几分钟内发生变化，因此“之前能用”并不能保证现在能用。
2. 在你计划使用的同一批次中进行测试。 如果你为了一个任务轮换几个代理，请在开始之前立即一起检查所有代理，而不是依赖旧的检查。
3. 保留比你需要更多的候选者。 如果一个任务需要 3 个工作代理，请检查 6-8 个——其中一些不可避免地会死掉，特别是来自免费列表的代理。
4. 使格式与你的列表完全匹配。 解析不匹配（选择错误的格式）会显示每个代理无效，即使它们实际上完全没问题——仔细检查格式下拉菜单是否与你的列表结构相匹配。
5. 不要过度信任单次检查。 刚刚通过的代理在实际使用中片刻后仍可能失败，特别是如果该使用比快速验证请求更重的话——将“活动”视为“当前可访问”，而不是永久的保证。

免费代理本质上是一个移动的目标，但在依赖它之前花几秒钟进行检查，可以节省调试一个从一开始就无法工作的连接所需要的大量时间成本。