2017 年，做稳定 HTTP 代理这件事

这一年发生了什么

2017 年，代理 IP 行业还处在一个特殊阶段。免费代理仍然是大量个人开发者的首选——网上随手一搜就是成百上千个 IP 地址和端口，看起来"够用"。但真正用它跑过业务的人都清楚：免费代理平均存活时间是以分钟计算的，很多时候刚配置好就已经失效了。

这一年，我们决定做一件事——做一款真正稳定的 HTTP 代理产品，面向那些被免费代理折磨过的企业和开发者。

行业背景

2017 年，整个代理市场处在几个关键变化中：

免费代理的质量断崖式下滑。 早期互联网上还有不少高质量的免费代理，但随着爬虫需求增长和防护升级，免费代理的存活时间越来越短。到 2017 年，大部分免费代理从发布到失效的平均时间已经缩短到 30 分钟以内。

付费代理开始出现但良莠不齐。 第一批商业代理服务商开始出现，但大多数还是"个人站长"模式——租几台服务器，挂个面板就开始卖。服务水平参差不齐，有的今天买明天就失联。

企业用户的需求在增长。 越来越多的企业开始做数据采集业务，它们需要的不是"今天能用的代理"，而是"长期稳定、有售后服务、出了问题有人管"的代理服务。

这个市场背景直接决定了我们第一年的策略：不追求规模，先做好基础。当时我们给自己定的目标是：第一年不追求用户数量，而是把服务跑通、把问题暴露出来、把解决这些问题的流程建好。

这个策略在后来被证明是对的——第一年没有大规模推广，但积累的技术经验和运维流程，让后续的产品上线和用户增长有了可靠的基础。

什么是稳定的代理

2017 年，我们花了大量时间思考一个问题：什么样的代理才算"稳定"？

最终我们把稳定性分解成了三个层次，这个框架至今仍是我们的基础。

第一层：协议层的可靠性。

HTTP 代理看起来很简单——客户端发一个 CONNECT 请求，代理转发数据就完了。但在真实的网络环境中，事情远比这个复杂。

先说一下 HTTP 代理的工作方式。当你的浏览器或程序配置了 HTTP 代理后，所有请求都会先发给代理服务器。如果是 HTTP 请求，代理直接转发；如果是 HTTPS 请求，代理先与目标服务器建立 CONNECT 隧道，再通过隧道传输加密数据。

这个过程中有三个环节最容易出问题：

第一个是连接复用。HTTP 协议本身支持 Keep-Alive，但代理服务器需要正确处理连接复用。如果处理不当，多个请求共用同一个连接时可能出现串数据的情况。你可能遇到过这种情况：两个不同的网页请求，返回的内容却是一样的。

第二个是超时处理。每个代理连接都有超时时间。如果代理服务器设置的超时太短，一个加载慢的页面就会频繁断开；如果太长，大量闲置连接会耗尽服务器资源。找到一个合适的平衡点，需要大量实际测试。

第三个是协议兼容性。不同的目标服务器支持的 HTTP 版本不同，有的还是 HTTP/1.0，有的已经升级到 HTTP/2。代理服务器需要兼容所有这些情况。

我们 2017 年大部分时间就是在做这些事情：搭建测试环境、模拟各种网络场景、验证不同协议实现在高并发下的表现。这些工作在当时看不到直接的"产品成果"，但为后来的产品稳定性打下了基础。

第二层：资源层的冗余。

一台服务器出问题了怎么办？如果资源池只有一个来源，那这个来源一旦不可用，整个服务就断了。

2017 年很多代理服务商犯的错误就是单点依赖。他们可能只租了一台服务器，或者只接了一个上游资源商。一旦这个唯一的依赖出问题，所有用户一起掉线。

我们在第一年就确定了多来源策略。即使当时规模不大，我们也在同时接入多个资源来源，任何一个来源出问题，其他来源可以立即顶上。这个架构思路一直延续到今天，现在我们的资源池比当年大了很多倍，但"永远不要只有一个依赖"的原则从没变过。

第三层：监控层的可感知。

如果用户比你先知道服务出了问题，那是监控没做好。

2017 年我们做了一件看起来简单但在当时并不普遍的事情：对每个代理节点做主动探测。不是等用户报故障，而是我们自己去测——每隔几分钟向每个节点发送测试请求，如果连续多次失败，就自动标记为异常并切换到备用节点。

这个机制在今天看来是标配，但在 2017 年，很多代理服务商根本没有监控。它们的方式是"用户报修了才去查"，这中间的时间差可能长达几个小时。

怎么判断代理稳不稳

2017 年，我们教用户看的第一个指标是连通率。

连通率的计算方法很简单：

连通率 = （成功连接次数 / 总尝试次数） × 100%

但关键在于测试条件，同一个连通率数字，不同的测试方式可能差很远。

测试频率的影响。 如果每小时测一次，一天只能得到 24 个数据点，一个短暂的网络波动可能完全被遗漏。如果每分钟测一次，就能捕捉到更细粒度的状态变化。所以同样标称 99% 连通率的服务，测试频率不同，实际体验可能是天壤之别。

测试目标的影响。 连通率是相对于某个目标而言的。测百度、测谷歌、测一个冷门网站，结果完全不同。有的服务商只测自己的服务器（那当然永远是 100%），但你用它访问目标网站时可能完全不通。正确的做法是模拟用户的实际访问目标来测。

测试时长的影响。 测 5 分钟和测 24 小时，看到的稳定性完全不是一个量级。有些代理服务在短时间内表现很好，但拉长到一天就会发现晚上高峰期大量失败。所以单个时点的测试数据参考价值有限，长期持续监测才有意义。

一个连通率 99% 的服务，意味着每 100 次请求中只失败 1 次。听起来很好，但如果你一天发 10 万次请求，那就意味着 1000 次失败。所以对用户来说，真正重要的不只是"有没有失败"，而是"失败后怎么办"——有没有重试机制？切换节点是否够快？这才是实际体验的决定因素。

这一年我们的投入

2017 年，公司刚成立，团队规模不大。但我们做的几件事，为后续的稳定性体系打好了基础：

协议验证。 完成了 HTTP/HTTPS 和 SOCKS5 协议在代理场景下的完整适配验证。这项工作包括搭建多种网络环境的测试平台、模拟高并发场景、验证不同协议实现的行为差异。虽然这些工作不直接面向用户，但它们是产品稳定性的基石。

多来源架构。 搭建了初步的多来源资源池。我们的原则从一开始就是：不依赖任何单一的资源来源。每一个节点都有至少一个备用节点，每一条线路都有至少一条备用线路。

主动监控。 建立了基础的主动监控体系，对每个节点进行持续的可用性探测。监控系统会记录每个节点的响应时间、成功率、失败模式，并自动切换异常节点。

首批用户。 积累了第一批企业用户。这些用户在给我们付费用的同时，也给了大量真实场景下的使用数据。哪些协议兼容性差、哪些网络环境问题多、哪些功能是用户真正需要的——这些反馈直接驱动了我们后续版本的方向。

创业第一年的认知

第一年最大的收获不是技术积累，而是对"稳定"这两个字的重新理解。

在开始做之前，我们认为稳定就是"代码写对、服务器配好"。但真正开始服务用户之后才发现，稳定不只是技术问题，更是组织问题、流程问题和沟通问题。

技术层面的稳定可以通过架构设计解决，但服务层面的稳定需要整个团队的配合。用户遇到问题时能不能快速响应、故障能不能在用户发现之前修复、升级维护能不能不中断服务——这些"软"的方面对稳定性的影响，有时比技术硬指标更大。

2017 年团队还不大，但这个认知让我们从一开始就把稳定性当作一个系统工程来做，不只看代码，也看流程。

展望 2018

第一年打下的基础让我们确定了 2018 年的方向：协议层的适配验证基本完成，接下来要把这些技术能力转化为产品。2018 年的目标是完成产品的标准化，让用户不用再通过"找我们聊"的方式接入，而是可以自助使用。

从稳定性的角度看，2017 年我们在 "做实验"，2018 年我们要在实验的基础上搭建可规模化的稳定服务体系。

2017 年的代理市场选择

2017 年一个想用代理的用户面临的选择大致有几种：

第一种：免费代理。 成本为零，但质量不稳定。你在网上搜到的免费代理列表，可能发布时是好的，等你拿到手配置好已经失效了。真正能用且相对稳定的免费代理每个 IP 的存活时间很难超过 1 小时。对于短时间测试来说够用，但跑正式业务就是灾难。

第二种：自己搭建代理。 如果你有服务器，可以自己搭 Squid、Shadowsocks 等服务。自己搭的好处是完全可控，但需要自己维护服务器，解决 IP 被封、带宽不足、单点故障等问题。一个人维护一个代理池的时间成本相当高。

第三种：购买商业代理。 2017 年国内的商业代理服务商可以一只手数得过来。价格相比现在贵不少，但至少有人管运维、有客服可联系。选择商业代理的关键问题变成了：哪家是真正在做服务的，哪家只是挂个面板卖流量的。

三种方式各有优劣，我们当时的目标就是让第三种成为性价比最高、最省心的选择。

免费代理的质量数据

2017 年我们做过一个持续一个月的免费代理质量测试，覆盖了当时主流的免费代理发布渠道。结果如下：

这也是我们决定做付费代理的直接原因。如果你在 2017 年用免费代理跑数据采集，你花在处理代理失效上的时间，可能比你花在实际业务上的时间还多。

代理连接建立的完整过程

理解代理稳定性，需要先理解一个 HTTP 代理请求的完整生命周期。

当你配置好代理后，一个 HTTP 请求大致经过以下步骤：

1. 你的程序向代理服务器发起 TCP 连接（三次握手）
2. TCP 连接建立后，发送 HTTP 请求到代理
3. 代理服务器解析请求，确定目标地址
4. 代理服务器向目标服务器发起连接
5. 如果是 HTTPS，代理先与目标进行 CONNECT 握手
6. 代理开始在客户端和目标之间转发数据

这个过程看似简单，但每一步都可能出现问题：

第一步的 TCP 握手可能因代理服务器负载过高而超时。 如果代理同时处理的连接数太多，新连接只能在队列中等待，用户侧表现为连接缓慢或超时。这就像高峰期排队，不是服务不可用，但要等很久。

第三步的域名解析可能因为 DNS 缓存污染而失败。 代理服务器需要解析你请求的目标域名。如果 DNS 解析出现问题，你的请求就无法到达目标。有些代理服务出于性能考虑使用了公共 DNS 缓存，这在大规模使用时会遇到缓存污染或限流的问题。

第四步到第五步的代理到目标连接是最脆弱的环节。 代理服务器到目标服务器之间的网络路径经过的节点最多，任何一个节点出问题都会导致连接失败。如果代理和目标之间的国际链路拥堵，即使代理本身没问题，用户一样感觉"代理不稳定"。

第六步的数据转发阶段可能因为带宽不足而变慢。 如果代理的出口带宽有限，大量用户共享时就会变慢。这不是连接失败的问题，但用户感知到的仍然是"这个代理不好用"。

这个完整的链路告诉我们一个道理："代理稳不稳"不只是一个节点的问题，而是从你到代理、代理到目标、再从目标返回你的整条链路的质量总和。任何一个环节出问题，感受都是"代理不行"。

所以 2017 年我们做的一个关键决策是：不在单一环节上追求极致，而是保证整个链路的每一段都可控、可监测、可切换。每一段都有冗余，每一段都有监控，每一段都有应急预案。

HTTP 代理与 SOCKS5 代理的早期选择

2017 年我们面临的一个重要技术决策是：先做 HTTP 代理，还是直接做 SOCKS5？

HTTP 代理的优势是兼容性好。几乎所有的编程语言、操作系统、浏览器都原生支持 HTTP 代理配置。用户不需要安装额外软件，配置一下地址和端口就能用。对于首次使用代理的用户来说，HTTP 代理的入门门槛最低。

SOCKS5 的优势是灵活性高。它不限于 HTTP 协议，可以转发 TCP 和 UDP 流量。如果你需要代理访问非 HTTP 服务、或者需要使用 UDP 协议，SOCKS5 是必需的选择。但不利之处在于，2017 年支持 SOCKS5 的商业代理服务还不多，用户对这种协议也比较陌生。

我们的决定是两个都做。HTTP 代理优先上线覆盖最大需求的用户群体，SOCKS5 同步开发和验证，后续作为独立产品线推出。这个"HTTP 优先、双协议并行"的策略，让我们既能快速触达用户，又能为后续的产品扩展储备技术能力。

这个决策在后来被证明是正确的：2017-2018 年期间 HTTP 代理承担了绝大部分流量，而当我们 2019 年正式推出 SOCKS5 产品时，底层技术已经经过了充分的测试和优化。

什么样的代理业务需要特别注意稳定性

2017 年，不同用户对稳定性的敏感度差异很大。根据我们与首批用户的交流，以下几种业务对稳定性的要求最高：

自动化数据采集。 如果你有几百上千个任务同时在跑，任何一个任务的失败都可能是整个管道中的一环。一个不稳定的代理会导致大量重试，重试又增加延迟，延迟累积可能导致整个任务超时。这里的关键不是单个代理的可用率，而是整体采集管道的吞吐量。

电商业务监控。 做竞品监控、价格跟踪的用户需要持续稳定的代理连接。如果代理每天断几次，监控数据就会有断档，影响定价决策。这类业务通常需要 7×24 小时的连续服务。

广告验证。 需要模拟不同地区的用户查看广告投放情况。代理切换频率高，而且每次切换后需要在短时间内完成一系列操作。代理不稳定意味着验证结果不可靠。

账号注册与管理。 大量社交媒体账号需要不同的 IP 来管理。如果代理频繁掉线，不仅影响操作效率，还可能因为 IP 频繁变化被平台判定为异常行为。

每种业务对稳定性的具体需求不同，但它们的共同点是：不稳定的代理直接影响了业务收入和运营效率，而不是锦上添花的体验问题。

反思：第一年做对了什么，做错了什么

2017 年结束后，我们做了第一次全面的复盘。

做对的事情：

• 协议验证投入足，后续产品没有因协议问题返工。第一年我们搭建的协议测试框架后来持续用了很多年，每次版本升级都在这个框架上验证
• 多来源架构的决策，让服务从一开始就具备基础的高可用能力。这个决策在后来多次上游资源波动中证明了价值
• 主动监控机制，让团队能比用户先发现问题。虽然当时的监控还很简陋，但这个机制建立了"稳定性从监控开始"的团队意识

做错或可以更好的事情：

• 产品化做得不够。2017 年我们更多的是在做"技术验证"而非"产品发布"。技术上走得比产品快，这意味着用户需要等到 2019 年才能用上正式产品，中间一年多只能通过定制方式接入
• 缺乏标准化的接入文档，首批用户接入时反复确认信息。每一家新用户接入都需要大量人工沟通，效率低、易出错
• 没有明确的 SLA 承诺，用户对服务预期不清晰。部分用户以为我们承诺 100% 可用，部分用户以为"晚上可能没人值班"，预期管理全靠口口相传

2017 年的行业展望

回头看 2017 年，代理行业正在经历从"个人站长时代"向"企业服务时代"的过渡。免费代理还在大量存在，但付费代理的市场接受度在快速提升。

行业的最大变化是什么？我们没有简单总结为"更多用户愿意付费了"，而是看到更深层的趋势：用户对代理的需求从功能需求变成了服务需求。 功能需求是"给我一个能用的 IP"，服务需求是"当我遇到问题时，有人能快速解决"。

这个转变意味着，代理服务的竞争不再是 IP 资源的竞争，而是服务体系的竞争。谁的监控更完善、响应更快、文档更清晰、SLA 更可靠，谁就能获得企业用户的信任。

这些反思直接影响了 2018 年的工作重点。

回顾 2017 年，这是我们在代理服务领域打基础的一年。当时做的很多技术决策，后来被证明是正确的。也有一些当时没做好的地方，在后面几年逐步改进。

但最重要的一点是：第一年让我们明白了稳定不是一个技术目标，而是一个服务目标。它不是靠一次架构升级就能达到的，而是需要持续投入、长期积累的。

给用户的一句话建议

选代理服务时，不要只看"现在能不能用"，要看"长期连通率是多少"，以及"连通率是怎么测出来的"。一个标榜 99% 连通率的服务，如果它的测试频率是每小时一次、测试目标是自己的服务器、测试时长只有 10 分钟，那这个 99% 对你来说可能一文不值。

另外，如果服务商没有公开的监控体系或状态页面，说明它在稳定性上的投入可能不够。2017 年我们自己的经验也证明了这一点：主动监控不是锦上添花，而是稳定性的基础组件。

最后，如果你正在选择代理服务，建议先问服务商几个关键问题：你们的连通率是怎么测的？测试频率和数据来源是什么？如果节点故障，切换需要多少时间？对这些问题能否给出清晰回答，本身就是一个判断标准。