1. 项目概述与核心价值

最近在折腾一些需要跨地域、跨网络环境访问的服务时，路由问题总是最让人头疼的环节。你可能也遇到过类似情况：明明服务部署在A地，从B地访问时延迟高得离谱，或者干脆时通时不通，排查起来像大海捞针。传统的 ping 和 traceroute 工具虽然基础，但在面对复杂的网络拓扑、多运营商线路或者特定的防火墙策略时，信息粒度往往不够细，难以定位到链路中具体是哪个节点、哪个环节出了问题。

正是在这种背景下，我注意到了GitHub上一个名为 openclaw-route-check 的项目。这个项目由 pfrederiksen 维护，从名字就能看出它的核心使命——像“开放之爪”一样，帮你抓取和分析网络路由的完整路径与状态。它不是简单地替代 traceroute ，而是在其基础上，集成了更丰富的探测协议、更灵活的测试策略以及可视化的分析能力，旨在为开发者、运维工程师甚至是对网络质量有要求的普通用户，提供一个一站式的路由诊断工具。

简单来说， openclaw-route-check 能帮你做什么？它能从你的本地环境出发，向目标地址（域名或IP）发起一系列智能探测，不仅告诉你数据包经过了哪些节点（Hop），还能详细展示每个节点的延迟（RTT）、丢包率、所属的自治系统（AS）、地理位置（GeoIP），甚至能对整条路径的MTU、TCP握手情况等进行测试。这对于诊断跨国服务延迟、选择最优的CDN节点、验证云服务商的多线BGP公告是否生效，或者仅仅是搞清楚为什么家里的网络访问某个网站特别慢，都极具价值。

无论你是负责线上业务稳定性的SRE，是开发分布式应用的工程师，还是热衷于自建服务的极客，这个工具都能成为你网络工具箱里的一把利器。接下来，我将结合自己的使用和测试经验，带你彻底拆解这个项目，从设计思路到每一行配置，从基础使用到高阶技巧，让你不仅能上手，更能理解其背后的原理，真正用活它。

2. 项目整体设计与思路拆解

2.1 核心设计哲学：超越传统Traceroute

传统的 traceroute （或Windows下的 tracert ）工作原理是基于IP协议的TTL（Time To Live）字段。它发送一系列TTL值递增的探测包（通常是UDP、ICMP或TCP SYN包）。当路由器收到TTL为1的包时，会丢弃它并向源地址发送一个“TTL超时”的ICMP消息；收到TTL为2的包时，第一跳路由器将TTL减1后转发，第二跳路由器丢弃并返回错误，如此往复。通过这种方式，逐跳地发现路径上的路由器。

然而，这种方法有几个明显的局限性：

1. 信息单一 ：通常只返回节点的IP和往返延迟，缺乏网络归属、地理位置等上下文。
2. 协议受限 ：很多网络环境会过滤ICMP或非常用端口的UDP包，导致探测失败，但这并不代表TCP业务不通。
3. 路径不对称 ：互联网路由往往是不对称的， traceroute 显示的只是“去程”路径，回程路径可能完全不同。
4. 缺乏综合分析 ：它只是一个探测工具，对于路径稳定性、中间节点丢包、特定协议端到端连通性等，需要人工结合多次测试结果来分析。

openclaw-route-check 的设计哲学正是为了突破这些限制。它的思路是**“多协议、多维度、可扩展”**。

• 多协议 ：除了标准的ICMP/UDP traceroute ，它集成了基于TCP（如HTTP/HTTPS）、TLS甚至QUIC的探测能力。这意味着你可以模拟真实应用（如浏览器访问网页）的握手过程来测试路由，能有效绕过那些仅放行业务端口的网络策略。
• 多维度 ：它不仅收集跳点信息，还通过集成外部数据库（如MaxMind的GeoIP2）或API，自动查询并丰富每个节点的自治系统号（ASN）、所属组织（ISP）、国家、城市甚至经纬度。同时，它可以进行持续的探测，计算丢包率和延迟抖动，从而评估路径的稳定性。
• 可扩展 ：项目采用模块化设计，探测模块、解析模块、输出模块相对独立。这意味着未来可以相对容易地添加新的探测协议（如MPTCP）、新的数据源（如IP到运营商的映射）或新的输出格式（如直接对接Prometheus进行监控）。

2.2 技术栈与架构选型分析

浏览项目代码库，可以发现它主要基于 Python 3 开发。选择Python是明智的，因为它拥有极其丰富的网络库（如 scapy 用于底层包构造和嗅探， requests 用于HTTP客户端），在数据处理和集成外部API方面也异常便捷，同时保证了工具在Linux、macOS甚至WSL上的跨平台能力。

项目的核心架构可以理解为 一个探测调度引擎加上多个插件化的探测器 。

1. 调度引擎 ：负责解析用户输入的目标、协议、参数，然后调度相应的探测模块执行任务。
2. 探测模块 ：
   • ICMP/UDP Traceroute ：基于 scapy 或系统原生 socket 实现，完成传统的路径发现。
   • TCP Traceroute ：通过发送TCP SYN包（可指定目标端口，如80、443）来实现。这对于探测防火墙后的服务特别有用，因为业务端口通常是开放的。
   • HTTP/HTTPS Probe ：这不仅仅是路由发现，更是端到端的应用层测试。它会尝试建立完整的TCP连接，甚至发送HTTP GET请求，记录每一步的耗时和结果，可以精准定位是网络路由问题还是服务本身问题。
3. 数据增强模块 ：在获取到IP列表后，这个模块会调用本地数据库或远程API，为每个IP地址查询ASN和地理信息。项目通常推荐使用MaxMind的GeoLite2免费数据库，需要用户自行下载并配置路径。
4. 输出渲染模块 ：将收集到的路径信息、延迟数据、增强信息，以人类可读的格式（如彩色终端输出、Markdown、JSON）或机器可读的格式（JSON、CSV）呈现出来。清晰的终端表格输出是它的一个亮点。

注意 ：由于需要进行原始套接字操作（构造和发送特定协议的包）， openclaw-route-check 在大多数系统上需要 以管理员权限（root或sudo）运行 。这是此类底层网络工具的普遍要求。

2.3 与同类工具的差异化优势

市面上也有其他增强版路由跟踪工具，如 mtr （My Traceroute），它结合了 traceroute 和 ping 的功能，能持续测试并统计丢包。那么 openclaw-route-check 的独特价值在哪里？

1. 协议模拟更贴近业务 ： mtr 主要还是基于ICMP。而 openclaw-route-check 的TCP/HTTP探测能力，让你能直接回答“为什么我的客户端连不上服务器的443端口”这类业务问题，而不仅仅是“网络通不通”。
2. 上下文信息更丰富 ：集成的GeoIP和ASN信息，能快速帮你判断路径是否“绕路”。例如，你访问国内的服务，却发现路径中出现了海外ASN（如 AS4134 中国电信国际），这很可能就是导致延迟高的原因。
3. 输出更利于分析与报告 ：其结构化的JSON输出，可以轻松被其他脚本或监控系统消费，用于自动化分析或生成历史趋势图表。而 mtr 的输出更偏向于实时交互式查看。
4. 灵活性 ：作为Python项目，它的配置和扩展方式对开发者更加友好。你可以通过修改配置文件或编写小脚本，定制化探测参数和输出逻辑。

3. 核心细节解析与实操要点

3.1 环境准备与安装避坑指南

安装 openclaw-route-check 最推荐的方式是通过Python的包管理工具 pip 。但这里有几个关键细节，直接关系到安装成败和工具的正常运行。

首先，确保你的Python版本在3.7以上。然后，通常的安装命令是：

pip install openclaw-route-check

或者从GitHub仓库克隆后安装：

git clone https://github.com/pfrederiksen/openclaw-route-check.git
cd openclaw-route-check
pip install -e .

实操心得与常见坑点：

1. 权限与虚拟环境 ：强烈建议在Python虚拟环境（ venv ）中安装，避免污染系统Python环境。创建并激活虚拟环境：

   python3 -m venv .venv
   source .venv/bin/activate  # Linux/macOS
   # .venv\Scripts\activate  # Windows
   

   然后在虚拟环境中执行 pip install 。

2. 系统依赖缺失 ：工具底层可能依赖一些C语言库。在Linux上，你可能需要先安装 libpcap-dev 或 python3-dev 等包。例如在Ubuntu/Debian上：

   sudo apt update
   sudo apt install libpcap-dev python3-dev -y
   

   在macOS上，如果使用Homebrew，可能需要 brew install libpcap 。

3. GeoIP数据库配置 ：这是让工具发挥最大价值的一步，但也是新手最容易忽略的一步。工具本身不包含GeoIP数据库。你需要从MaxMind官网（需注册账号）下载免费的GeoLite2 City和ASN数据库（文件为 .mmdb 格式）。下载后，你需要通过环境变量或配置文件告诉工具数据库的位置。

   • 方法一（环境变量） ：

     export GEOIP_CITY_DB=/path/to/your/GeoLite2-City.mmdb
     export GEOIP_ASN_DB=/path/to/your/GeoLite2-ASN.mmdb
     

     然后运行工具。
   • 方法二（配置文件） ：在用户主目录下创建配置文件 ~/.openclawrc （或工具指定的其他位置），内容如下：

     [geoip]
     city_db = /path/to/your/GeoLite2-City.mmdb
     asn_db = /path/to/your/GeoLite2-ASN.mmdb
     

   没有配置GeoIP数据库，工具依然可以运行，但输出的节点信息将缺少AS号和地理位置，实用性大打折扣。

3.2 核心参数与命令模式详解

安装成功后，核心命令是 openclaw 。它的参数设计兼顾了简单易用和灵活强大。下面解析最常用和关键的几个参数。

基础探测模式：

• openclaw <目标主机或IP> ：这是最简单的用法，默认会使用ICMP协议进行路由跟踪，并尝试进行GeoIP信息查询（如果已配置）。
• -p, --protocol <协议> ：指定探测协议。这是核心参数之一。可选值通常包括：
  • icmp ：默认值。使用ICMP Echo Request包。
  • udp ：使用UDP包，目标端口可自定义（ --udp-port ）。
  • tcp ：使用TCP SYN包。 必须 配合 --tcp-port 参数指定目标端口（如443）。
  • http / https ：进行完整的HTTP(S)请求。这会模拟浏览器行为，不仅走通路由，还会建立TCP连接、完成TLS握手、发送HTTP请求。
• -m, --max-hops <跳数> ：设置最大TTL，即探测的最大跳数。默认通常是30，对于绝大多数互联网路径足够了。如果路径非常复杂，可以适当调高。
• -q, --queries-per-hop <数量> ：对每一跳发送的探测包数量。默认可能是3。增加这个值（如设为5）可以得到更稳定的延迟和丢包率统计，但测试时间会变长。
• -w, --wait-time <秒> ：等待每个探测包回复的超时时间。默认2秒。在网络条件较差或跨洋链路时，可以适当增加（如5秒），避免因超时误判为节点无响应。

信息增强与输出控制：

• --no-geoip ：禁用GeoIP查询。如果你没有配置数据库，或者本次探测不关心地理位置，可以使用此选项加速探测。
• --no-asn ：禁用ASN查询。
• -o, --output <格式> ：指定输出格式。 table （默认，彩色表格）、 json （机器可读）、 csv 、 markdown 等。 json 格式非常适合用于自动化脚本分析。
• -v, --verbose ：详细输出模式，会打印更多调试信息，对于排查工具自身问题很有用。

高级与实验性功能：

• --source-ip <IP> ：指定源IP地址。在多网卡主机上，你可以强制从某个特定出口IP发起探测。
• --source-port <端口> ：指定源端口（对于UDP/TCP探测）。
• --mtu-discovery ：尝试进行路径MTU发现。这有助于诊断因MTU不匹配导致的大包分片问题。

3.3 输出结果深度解读

一份典型的 openclaw 表格输出包含大量信息，读懂它们是诊断的关键。以下面一行输出为例（假设）：

Hop  IP Address        Loss%   Avg RTT  ASN        Organization                 Location
5    203.0.113.10     0%      45.2 ms  AS4766     Korea Telecom               Seoul, KR
6    192.0.2.1        20%     152.1 ms AS1299     Telia Company               Stockholm, SE
7    198.51.100.100   0%      180.5 ms AS15169    Google LLC                  Los Angeles, US

• Hop ：跳数。从你的主机出发，经过的第几个路由器。
• IP Address ：该跳路由器的接口IP。注意，有些路由器可能配置了不响应ICMP TTL超时，或者其返回地址并非你路径上的接口IP，这会导致显示为 * 。
• Loss% ： 丢包率 。这是基于你对这一跳发送的多个探测包（由 -q 参数控制）计算得出的。例如，Hop 6显示20%丢包，意味着发往该地址的5个探测包中，有1个没有收到回复。 需要谨慎解读 ：中间路由器的策略性丢包（如限速）或路径不对称，都可能导致该值异常。通常更应关注最后一跳（目标）或最后几跳的丢包。
• Avg RTT ：平均往返延迟。这是网络延迟最直观的体现。延迟的突然跃增（如从Hop 5的45ms跳到Hop 6的152ms）往往意味着数据包进入了更高延迟的链路（如跨海光缆）。
• ASN ：自治系统号。这是理解网络归属的核心。 AS15169 代表谷歌， AS4134 代表中国电信。如果路径中出现了意料之外的ASN（例如访问国内网站路径中出现了海外运营商ASN），通常意味着路由绕行或BGP选路不佳。
• Organization ：ASN对应的组织名称。由GeoIP ASN数据库提供。
• Location ：地理位置。由GeoIP City数据库提供。结合延迟看地理位置非常直观：从首尔到斯德哥尔摩延迟大增是符合预期的。

诊断逻辑 ：当你遇到高延迟问题时，顺着输出表格从上往下看，找到RTT发生显著跃增的那一跳。然后查看该跳的ASN和Location。如果这一跳的ASN从你的ISP变成了一个国际运营商（如 AS1299 Telia ），并且位置到了海外，那么问题很可能出在从你的本地网络到国际出口这一段，或者目标服务本身就部署在海外。如果延迟是在接近目标服务器的最后几跳突然增加的，那可能是目标服务器所在的机房或服务器本身负载过高。

4. 实操过程与核心环节实现

4.1 场景一：诊断跨境网站访问延迟

假设你在中国大陆，访问部署在德国法兰克福的某服务 api.example.de 速度很慢。我们使用 openclaw 来一探究竟。

命令与思路 ： 我们使用TCP协议探测443端口，因为这是HTTPS服务的标准端口，能真实反映业务流量路径。

sudo openclaw api.example.de -p tcp --tcp-port 443 -q 4 -w 3

• sudo ：因为需要发送原始TCP SYN包。
• -p tcp --tcp-port 443 ：模拟HTTPS客户端建立连接的行为。
• -q 4 ：每跳发4个包，获得更稳定的统计。
• -w 3 ：超时设为3秒，给跨境链路更宽松的响应时间。

关键输出片段分析 ： 假设我们得到如下关键几跳（已简化）：

...
8    202.97.xx.xx     0%      38.5 ms  AS4134     CHINANET-BACKBONE          Shanghai, CN
9    202.97.xx.xx     0%      39.1 ms  AS4134     CHINANET-BACKBONE          Shanghai, CN
10   218.30.xx.xx     0%      180.2 ms AS4134     CHINANET-BACKBONE          Los Angeles, US
11   129.250.xx.xx    0%      205.7 ms AS2914     NTT Communications          Los Angeles, US
12   213.198.xx.xx    0%      280.5 ms AS1299     Telia Company               Frankfurt, DE
...

解读与结论 ：

1. 第8-9跳属于中国电信骨干网（AS4134），延迟在40ms以内，正常。
2. 关键点在第10跳 ：IP仍属于 AS4134 （中国电信），但位置显示为 Los Angeles, US （美国洛杉矶），且延迟跃升至180ms。这清晰地表明，流量从上海出国后，没有直接前往欧洲，而是先绕道了美国。
3. 第11跳进入NTT（AS2914，日本运营商，但在全球有网络），仍在洛杉矶。
4. 第12跳进入Telia（AS1299，欧洲运营商），到达目的地法兰克福，延迟高达280ms。

结论 ：延迟高的主要原因是 路由绕行 。中国电信去往德国法兰克福的流量，没有选择最优的欧亚直连线路（例如经过中亚或俄罗斯），而是绕道了美国。这可能是由于运营商之间的对等互联（Peering）策略或某段链路临时拥塞导致的绕行。作为用户，你可能无法改变运营商的路由，但这个信息非常有价值：你可以考虑使用位于其他地域（如新加坡、日本）的接入点，或者向服务提供商反馈，看其是否接入了更好的国际运营商（如接入了中国电信的欧洲直连POP点）。

4.2 场景二：验证多云服务商BGP通告

假设你的公司使用了多云架构，在AWS东京区域和阿里云杭州区域都部署了服务，并通过Anycast或Global Accelerator对外提供一个IP地址 203.0.113.100 。你想验证从不同地区访问这个IP，是否真的能智能路由到最近的后端。

操作流程 ：

1. 准备多个探测点 ：你需要在不同地理位置的服务器或VPS上安装 openclaw 。例如，一台在阿里云华北2（北京），一台在AWS美西（俄勒冈），一台在DigitalOcean的伦敦机房。
2. 编写统一探测脚本 ：在每台机器上运行相同的命令，并将JSON结果输出到文件。

   # 在每个探测点执行
   sudo openclaw 203.0.113.100 -p icmp -o json > result_$(hostname).json
   

3. 收集与分析结果 ：将各点的JSON结果文件收集起来。你可以编写一个简单的Python脚本进行对比分析，重点关注：
   • 最后一跳的IP或倒数几跳的ASN ：如果Anycast配置正确，北京探测的最后一跳很可能属于阿里云（AS37963），而俄勒冈探测的最后一跳则属于AWS（AS16509）。
   • 整体路径延迟 ：北京到 203.0.113.100 的延迟应显著低于伦敦到该地址的延迟。
   • 路径入口 ：观察流量是从哪个运营商的网络进入目标云服务商的。这可以验证云服务商的多线BGP接入是否生效。

实操心得 ：

• 使用 -o json 输出格式是进行自动化对比分析的前提。JSON结构化了所有跳数、延迟、ASN和地理信息。
• 对于Anycast测试，ICMP协议通常就足够了，因为Anycast节点本身会响应ICMP。
• 如果后端服务是TCP/HTTP，可以结合TCP探测，验证业务端口的路由一致性。

4.3 场景三：排查企业内网特定端口连通性

开发报告说，办公室A区的客户端无法访问部署在数据中心B区的服务器 10.20.30.40 的TCP 8080端口，但能ping通。

排查命令 ：

# 在出问题的客户端执行
sudo openclaw 10.20.30.40 -p tcp --tcp-port 8080 -w 1

可能的结果与排查方向 ：

1. 路径完整，最终超时 ：输出显示路径经过了公司内部的核心交换机、防火墙，最终到达目标IP 10.20.30.40 ，但在最后一跳显示 * （无响应）或超时。这强烈暗示 目标服务器 10.20.30.40:8080 的防火墙（可能是主机防火墙 iptables 或 firewalld ）丢弃了SYN包 ，或者8080端口上没有监听服务。
2. 路径在中间中断 ：输出显示路径到达公司防火墙（假设IP为 10.10.10.1 ）后就再无后续响应。这表明 防火墙策略拦截了从A区到B区8080端口的流量 。你需要检查防火墙规则，是否允许 源: A区网段 访问 目标: 10.20.30.40:8080 。
3. 路径绕行或异常 ：输出显示流量没有走预期的内部直连链路，反而绕到了其他网络区域。这可能是内部路由协议（如OSPF）配置问题，导致去往 10.20.30.0/24 网段的路由下一跳错误。

优势 ：相比于简单的 telnet 10.20.30.40 8080 （只能告诉你通不通）， openclaw 给出了 路径可视化 。你不仅能知道不通，还能精准定位是在网络路径的哪个设备上开始不通的，极大缩小了排查范围。

5. 常见问题与排查技巧实录

即使工具本身强大，在实际使用中也会遇到各种问题。下面是我在多次使用中踩过的坑和总结的技巧。

5.1 工具运行报错与解决

问题1：执行命令时报错 PermissionError: [Errno 1] Operation not permitted

• 原因 ：这是最常见的问题。因为需要发送原始套接字数据包，工具必须拥有底层网络堆栈的访问权限。
• 解决 ： 使用 sudo 以root权限运行 。这是最直接的方法。在Linux/macOS上： sudo openclaw ... 。在Windows上，需要在管理员权限的PowerShell或CMD中运行。

问题2：GeoIP信息全部显示为“N/A”

• 原因 ：工具没有找到或无法读取GeoIP数据库文件。
• 排查步骤 ：
  1. 确认数据库已下载 ：确保你已经从MaxMind下载了 GeoLite2-City.mmdb 和 GeoLite2-ASN.mmdb 文件。
  2. 确认路径正确 ：检查你设置的环境变量（ GEOIP_CITY_DB , GEOIP_ASN_DB ）或配置文件中的路径是否完全正确，并且运行命令的用户（尤其是使用 sudo 时）有权限读取该文件。
  3. 测试数据库 ：可以写一个简单的Python脚本测试数据库是否能被 geoip2 库读取。
  4. 使用 --no-geoip 和 --no-asn 参数 ：如果暂时无法解决，可以先加上这些参数跳过GeoIP查询，让工具先跑起来。

问题3：探测过程中大量跳数显示为 * （星号）

• 原因 ：路径上的某些路由器被配置为不响应ICMP TTL超时消息（或你使用的探测协议包），这是一种常见的安全或管理策略。
• 影响与应对 ：
  • 这不会影响路径的最终可达性判断，只要最后一跳（目标）有响应即可。
  • 星号会导致丢包率（Loss%）计算失真，因为工具无法区分是包丢了，还是路由器静默丢弃。
  • 尝试切换协议 ：如果默认ICMP全是星号，尝试使用 -p tcp --tcp-port 80 （针对HTTP服务）或 -p udp --udp-port 53 （针对DNS服务）。业务端口被过滤的可能性低于管理协议。
  • 这是互联网路由跟踪的正常现象，不必过分担心。

5.2 网络现象解读与误区

误区一：中间某跳丢包率（Loss%）高，就一定代表网络有问题

• 不一定 。如前所述，中间路由器可能策略性不回复某些探测包。更可靠的判断方法是：
  1. 关注趋势而非单点 ：连续多次测试，如果同一跳持续高丢包，可能性更高。
  2. 关注最后几跳和目标 ：如果路径末尾的节点丢包率高，尤其是目标服务器本身丢包，那几乎可以肯定存在网络问题或服务器负载过高。
  3. 结合延迟（RTT）看 ：如果某跳丢包率高，同时其后所有跳的RTT都异常增高或也出现丢包，那么这一跳很可能确实是问题点。

误区二：延迟（RTT）越低，路径就一定最优

• 不一定 。延迟是重要指标，但也要结合 路径稳定性 （抖动和丢包）和 带宽 来看。一条延迟稍高（如增加10ms）但极其稳定、带宽充足的路径，通常比一条延迟低但抖动剧烈、偶尔丢包的路径，更能提供良好的用户体验（尤其是对于视频、语音、实时游戏等应用）。 openclaw 通过多次探测（ -q 参数）能给出延迟的分布情况，有助于判断稳定性。

如何区分路由绕行和正常跨境延迟？

• 这需要结合 ASN 和 地理位置 信息。
• 正常跨境 ：例如，从中国访问美国西海岸服务器。路径显示：中国运营商(AS4837) -> 国际出口 -> 美国运营商(AS7922)。地理位置从中国城市平滑过渡到美国城市，延迟增长符合物理距离（约150-200ms）。
• 路由绕行 ：例如，从中国访问日本服务器。路径显示：中国运营商(AS4134) -> 位置显示为“Los Angeles, US”的节点(AS4134) -> 日本运营商(AS2914)。这里出现了矛盾：数据包在属于中国电信的节点上，但地理位置却在美国。这明确说明流量没有走中日直连海底光缆，而是绕道了美国，这就是不合理的绕行，会导致额外延迟。

5.3 性能优化与使用技巧

1. 合理设置超时（ -w ）和每跳探测数（ -q ） ：

   • 对于国内或局域网探测， -w 1 （1秒）和 -q 3 通常足够，测试速度快。
   • 对于国际链路，建议 -w 3 甚至 -w 5 ， -q 4 或 5 ，以获得更准确的结果，避免因单次超时误判。
   • 增加 -q 值能提高统计显著性，但会线性增加测试总时间（总时间 ≈ 最大跳数 × -q × -w ）。

2. 使用JSON输出进行自动化 ：

   • 将 -o json 输出重定向到文件，然后利用 jq 命令或Python的 json 库进行解析，可以自动化完成很多工作，比如：
     • 监控特定路径的延迟是否超过阈值。
     • 定期检查去往关键服务的路由是否发生变化（ASN变更）。
     • 生成路由路径的历史变化图表。

3. 结合其他工具 ：

   • openclaw 擅长路径发现和节点信息丰富。对于持续的、高频率的网络质量监控（如每秒钟一次的延迟和丢包测试）， mtr 可能更合适。
   • 对于带宽测试，仍需使用 iperf3 或 speedtest-cli 。
   • 将 openclaw 的路径发现能力与 ping 的持续监测能力、 iperf3 的带宽测试能力结合，就能构成一个完整的网络诊断工作流。

4. 注意安全与合规 ：

   • 在企业网络或云环境中使用前，请确保你的行为符合公司的安全策略。未经授权的端口扫描或路由探测可能触发安全警报。
   • 对公网目标进行大量、高频的探测是不礼貌的，可能被视为网络攻击的前期侦查。请合理、节制地使用。