摘要

  • 在所检查的 RIPE Atlas Tools 源码中，默认十秒的 HTTP 超时会传给 Google 的地理位置查询，却没有进入经 Cousteau 创建 Atlas 测量的请求。
  • 将设置改为 3、10、30 的本地参数捕获测试确认了这条边界。测试没有联网、使用密钥、创建测量或消耗积分，不代表线上故障，也不能概括所有安装环境。

十秒写进配置，不等于写进请求

RIPE Atlas Tools 的配置里有一个很容易理解的数字：HTTP 超时默认十秒。但配置的名字不能替代执行路径。要知道它管什么，必须继续追问：哪一次请求收到了这个值？

官方变更记录把可配置的 HTTP 超时列在 3.4.0 版本中，发布日期是 2026 年 6 月 3 日。本文是在九月检查六月已公布的代码，不是报道九月新发布了一个版本。默认设置中确实存在 http-timeout，因而问题并非一个虚构开关，而是开关的适用范围。

一条路径有明确答案。搜索探针时，程序会向 Google 查询地点的经纬度。该方法把配置中的超时值交给 Requests，并处理超时错误。这说明设置在一个具体调用上生效，不应因为另一条路径不同，就否定它的全部作用。

另一条路径用于创建 Atlas 测量。命令行工具构造 AtlasCreateRequest，传入 API 服务器、授权密钥、客户端标识、测量定义、探针来源及是否单次执行，却没有传入 HTTP 超时设置。

在检查的 Cousteau 2.3.0 源码中，AtlasCreateRequest 继承 AtlasRequest。后者组织 HTTP 参数、请求头、TLS 验证和代理配置；发送 POST 时再加入 JSON 正文。最终交给 Requests 的参数集合里没有超时参数。设置并没有因为两层软件属于同一套机构工具，就自行跨过这条边界。

本地测试证明了什么

为了核对传递过程，我们从固定版本源码中按语法结构抽取了真实的测量创建、地理位置查询方法，以及 SDK 的请求与创建类。测量定义、来源构造器和传输响应使用本地测试对象。传输函数只捕获调用参数，不向 Atlas 发请求；返回的也不是 Atlas 服务器响应。

把设置分别改为 3、10、30，地理位置调用收到的就是 3、10、30。三次捕获到的 Atlas POST 参数中都没有超时。被抽取的代码没有可用的联网函数，因此没有使用 API 密钥，没有实际测量、远程任务或积分支出。

这是对指定方法和类的参数传递检查，不是完整运行已安装的命令行程序，也不是整包集成测试、服务器实验或延迟测量。它不能证明某位用户等了三十秒，不能证明 Atlas 曾经堵塞，更不能证明远端接受过本次测试的任务。

这一限制并不削弱代码结论，而是给结论划定位置。我们知道值在哪条路径缺席；不知道实际安装环境用什么外部措施补足它，也不知道这条缺席造成过多少影响。

超时参数不是全程倒计时

Requests 的文档区分了两个常被混在一起的概念。没有显式超时参数时，请求没有指定的 Requests 超时；即使给出参数，它也不是下载整个响应所允许的总时长。连接上的等待控制，并不等于整项任务的截止时间。

所以，地理位置查询拿到了十秒，也不能承诺命令从启动到结束恰好只等十秒。Atlas 路径没有这个参数，同样不能被写成“必然永远等待”：操作系统、连接、代理或外部进程监督措施仍可能中断等待。本文没有审计这些措施。

此外，向 API 等待 HTTP 响应，与探针对测量数据包设置的超时、客户端监听结果的时间限制，是不同控制。创建请求回得慢，并不说明探针测到的网络慢。把控制面的等待当作网络性能，会产生另一种误读。

停掉客户端，未必知道远端结果

实际意义在于如何处理未知状态。假设服务器已经接受创建请求，回包却丢失，此时结束本地进程，并不能证明任务在远端遭到拒绝。这是分析情景，不是本地测试发现的一次线上事件。

决定是否再次提交之前，操作者需要核对有权访问的远端任务记录，或者明确保留“结果未知”的状态。不能把本地截止时间当作服务器拒绝证明，也不能自动把本地停止等同于远端任务取消。

一份可操作的说明应把地理位置查询、SDK 的 Atlas 调用和自动化流程的总时限分开，写明各由哪一层控制、触发后如何核对结果。它不必让所有操作都使用同一个十秒值。它必须让使用者知道，一个可见设置究竟承诺了哪一段行为。

来源