亮点
自成立以来，FourA 一直只有一扇门：你发送 URL，我们返回页面。本周我们开放了第二扇门，一个标准的 proxy endpoint，你可以直接粘贴到任何 HTTP 客户端中，并使用在 Dashboard 中创建的凭证。Proxy Finder 现在还支持在目标网站拒绝其他所有出口时使用付费出口，Auto 也更擅长记住哪些出口有效。
新增功能
将任何 HTTP 客户端指向我们
Dashboard 中的新部分：ACCESS，然后是 Proxy。创建一个 proxy 用户，页面就会为你提供准确的连接字符串，旁边附带 cURL、Python 和 Node 示例。选择出口类型、国家/地区、是否在多次 request 运行中保持相同的出口，连接字符串会在你选择时自动更新。
既然 API 已经可用，为什么还要构建这个功能？有些任务并非简单的 request 和 response 模式。隧道会在字节到达时直接复制：没有 JSON 封装，没有缓冲。这正是大文件或视频流所需要的，而我们的 API 从未打算支持这种场景。
付费出口支持更深度的定位：地区、城市、按 ISP 名称划分的网络，以及出口保留时长。我们自己的池故意只支持国家级别。在覆盖较少的国家内，一个城市可能只有少数几个地址，一个大部分时候都失败的过滤器比没有过滤器更糟糕。
明确说明一个取舍。通过普通隧道，是由你的客户端与目标网站建立连接，而不是我们，因此我们的 API 代表你处理的那些工作并不在该路径中：unblocker 标志、基于浏览器的解析、validate 规则、session 重放。隧道为你提供我们的出口和带宽。API 为你提供我们在此之上构建的功能。请按具体任务选择，而不是按公司做全局绑定。
Premium 出口，以及标明服务来源的 response
/api/proxy 现在接受 exitClass，可选 standard 或 premium。Premium 会将你的流量路由至我们付费购买的出口，专用于我们自身池屡次受阻的目标网站。
如果不传值，则默认为 auto：优先使用共享池，仅当该检索受阻时付费出口才会介入。指定一个类别，我们就会严格执行。standard 绝不会自动升级，这也正是明确指定它的全部意义所在。
response 会带回 exitClass，以便你随时了解是哪个出口提供了服务。由我们自己的池优先响应的 premium request 会返回 standard，这代表成功，而不是降级。如果你的套餐不包含 premium，request 会直接被拒绝，而不是静默地从其他地方提供服务。
Premium 会作为你带宽的一部分显示，绝不会作为第二个独立总量：Quota 中的一行、Metrics 中的一列、Activity 中通过该方式发出的行标记，以及 Overview 卡片中的一个磁贴。Playground 也增加了该控件，其留空选项具有实际意义：保持未设置状态不会发送任何字段，因为“从未要求”与“要求绝不升级”是不同的 request。
Auto 记住有效出口
Auto 的阶梯策略一直会记录哪些出口失效。现在它还会记录哪些出口成功交付，覆盖每一层阶梯而不仅是浏览器层，并且只有在内容通过页面交付校验后才会记录。对于不会返回给您的页面，其对应的出口绝不会被标记为可用。
封禁状态现在也会按各自的时间独立老化过期。过去每当目标主机出现新的封禁时，其整个排除列表的有效期都会被刷新；现在每个封禁记录都严格按照预设周期独立过期。
此外，当单次运行达到您套餐的浏览器配额上限时，阶梯策略不再直接中断。它会转而在 proxy 层继续重试，并缓存胜出的出口，以便后续调用可以通过 Single 模式低成本复用。
Auto 依然是路径探测工具，而非生产环境的常规路由。建议让它帮您测出胜出的层级并交回 session，随后直接针对 /api/single 或 /api/browser 使用该 session 发起批量请求。这正是 Auto 发布时的核心设计理念，目前的改进完全保留了这一点。
响应内容与请求目标不符
部分出口位于受过滤的企业网络内部，此时响应来自网关而非目标网站。返回的 response 状态码为 200 且包含 body，甚至能通过我们以往的各项检查。现在这种情况已被修正：此类页面现在会被判定为出口不可用的证据，而非目标网站正常响应的依据，因此 request 会自动绕过该出口，并且该出口也不再会被优先选用。
我们匹配的每种页面结构都带有大小边界限制，因此恰好引用了相关关键字的真实文档不会被误判。大小仅作为防护阈值，绝不作为特征信号。两周前我们在当拦截误显为正常数据点时一文中对此进行了更广泛的探讨。
底层实现
在占用任何共享容量之前，系统现在会首先根据您自身账户的上限检查 rate limit。单一账户内的突发流量会直接触发其自身限制并被即时拒绝，不会挤占其他用户正在排队等待的槽位。
控制台中的在途请求数值现在来自各实例每秒重新发布的实时指标，而非可能持续上涨且无法回落的简单累加器。监控界面与限流器现在读取的是完全一致的数值。
数据表现
在我们的内部测试中，针对已有可用出口的目标主机建立 tunnel，在十几个样本中的耗时为 63 到 672 ms，多数低于 260 ms。首次访问从未承载过的主机则相对较慢：需要数秒甚至数十秒，期间系统需要在资源池中检索适用于该目标的可用出口。这一探测过程每个主机仅需执行一次，而非每个 request 重复执行。样本量较小，仅供参考。
两种接入方式带来了一个此前无需考虑的选择：当前任务的核心是传输数据本身，还是突破访问限制？如果要传输大文件，tunnel 是性价比最高的方案。除此以外更复杂的抓取场景，依然应该交给 API 处理。