PSPing网络排障指南：ICMP、TCP、UDP与带宽测试实战

1. 先搞清楚 PSPing 补的是哪块短板

先讲个我遇到过很多次的情况。业务方跑来说管理后台打不开了，你在自己工位上ping一下目标地址，四行回包齐刷刷，丢包率 0%，平均延迟 1ms，一切正常。然后你打开浏览器一访问，转圈五分钟，最后超时。这时候如果你只带着系统自带的 ping 去排查，基本等于拿着卷尺去修发动机——工具没错，但测的维度不对。

系统自带的 ping 只做一件事：发 ICMP Echo Request，等 ICMP Echo Reply。它测的是"ICMP 这一层协议能不能到达对端"，注意是协议层能到达，不是业务能到达。中间隔着的防火墙完全可以把 ICMP 放通、把 443 或 3389 全掐掉；也可以反过来，把 ICMP 全禁，只留业务端口。这两种配置在任何稍微规范一点的网络里都是常态。所以你看到"能 ping 通"，真实含义往往只是"这条路对 ICMP 开放"，离"这个服务可用"隔了好几个数量级。

PSPing 出现的意义就在这里。它把网络连通性从单一维度拆成了四条通道：ICMP、TCP、UDP，再加上一个带宽吞吐测试。你不用换机器、不用装抓包工具，一条命令就能回答"这个端口到底开没开""建链花了多久""这条链路实际能跑多少兆"这几个具体问题。它是个单文件命令行工具，不需要安装，扔到任意目录双击就能跑，输出格式干净，方便直接粘贴到工单里。

适合谁看：日常要处理网络问题的运维和研发、需要验证防火墙策略的实施人员、写自动化巡检脚本的工程师，以及只是单纯想知道"为什么我家宽带上某个服务特别慢"的折腾型用户。下面我会把四种模式的原理、参数取法、输出判读、踩过的坑一条条拆开，命令都是可以直接抄的。

1.1 三个盲区：ICMP 通、端口关、链路虚

第一个盲区是"ICMP 通但端口关"。这是最典型的误判来源。很多防火墙的默认策略是 ICMP 全放行、业务端口白名单，结果就是ping一路绿灯，telnet 端口卡住。PSPing 的 TCP 模式直接对目标端口发起一次完整的连接建立，连上了返回耗时，连不上返回拒绝或超时，两种结果的区别非常关键，后面第 4 章会细讲。

第二个盲区是"延迟低但链路虚"。ICMP 默认只发 8 字节或 32 字节的小包，小包不触发分片、不撑满链路、不进队列深处。真实业务报文动辄 1400 字节以上，一旦链路上有 MTU 不匹配、有 QoS 限速、有带缓冲的中间设备，小包延迟漂亮、大包直接趴窝的情况太多了。PSPing 允许你用-l指定请求大小，把包撑到你业务的真实尺寸再测一遍，很多"玄学卡顿"到这一步就现原形了。

第三个盲区是"能连但慢"。TCP 建链耗时 3ms 和 300ms 在业务侧的体感完全是两回事。系统工具根本没这个维度，PSPing 的 TCP 模式会把每一次建链的耗时打出来，你能直接看到最大值、最小值、平均值和分布，判断到底是物理距离导致的固有延迟，还是中间设备在做策略丢弃或者队列积压。

提示：判断"能不能通"和"快不快"是两件独立的事，先解决通不通，再谈快不快。混在一起排查，很容易在错误的方向上耗掉半天。

1.2 四种模式的分工对照

不同模式解决不同问题，选错了就是白测。我整理了一张对照表，基本覆盖日常九成场景：

从表里能看出来，TCP 模式是我用得最多的，因为它最接近业务真实行为。ICMP 模式我更倾向于用来做基线对比——先记下同一时刻的 ICMP 延迟，再测 TCP 建链延迟，两个数字一减，多出来的部分就是中间设备和服务端处理引入的开销。这个差值分析法是排障里性价比最高的技巧之一。

带宽模式的定位要摆正：它测的是"单条 TCP 流在当前参数下能跑到多少"，不是"这条链路的最大能力"。这两个数字在长肥管道上能差十倍以上，第 6 章我会用一个具体计算说明原因。

1.3 什么情况下别用它

工具没有万能的。需要看到具体哪个包被丢了、被谁丢了，得用抓包，PSPing 只能告诉你"有丢"不能告诉你"谁丢的"。需要压测并发连接数、跑长稳测试，得用专门的压测工具，PSPing 是单流顺序测试，压不出并发瓶颈。需要测路由每一跳的延迟，那是路径探测工具的活。需要测应用层接口的响应时间，用 HTTP 模式或者直接打接口更准，别拿 TCP 建链耗时去近似接口耗时——中间还差着 TLS 握手、请求处理、数据库查询一长串。

把工具的边界想清楚，比把工具的用法背下来更重要。我见过有人拿 TCP 建链 2ms 就断定"服务没问题"，结果接口实际耗时 3 秒，原因是数据库慢查询。这种误判的根子不在工具，在于用错了层次。

2. 拿到工具到第一次跑通

2.1 获取方式与运行环境

PSPing 是个独立的命令行可执行文件，随一套常见的系统管理工具包分发，也可以从官方工具集页面单独下载。下载下来是个压缩包，解开之后里面通常有 32 位和 64 位两个版本，现在基本都是 64 位系统，直接用 64 位那个就行。不需要安装、不写注册表、不驻留后台，用完删掉也没关系，这一点对需要在客户现场、跳板机上临时排查的场景特别友好。

有一点容易被忽略：它的文件名带架构后缀，很多人为了敲命令方便会改名成psping.exe。这本身没问题，但如果你写脚本分发到多台机器，务必保证所有机器上的名字和路径一致，否则脚本会因为找不到文件而静默失败。我吃过这个亏，一个批量巡检脚本在十几台机器上跑得好好的，唯独一台新机器上没出结果，查了半小时才发现那台机器上的文件名不一样。

跑之前建议先执行一次帮助命令，把当前版本的参数列表打出来看一眼：

psping64.exe -?

这里我要强调一下：不同版本的参数集会有细微差异，尤其是较新的版本增加了 HTTP 模式，老的参数说明文档里没有。任何时候以本机-?的输出为准，别照搬网上的截图。养成这个习惯能省掉很多"为什么我的命令报参数错误"的困惑。

2.2 最小可用命令与输出字段

最保守的第一次测试就用默认的 ICMP 模式，目标写你要查的地址：

psping64.exe 192.168.10.20

不加任何参数时，它默认走 ICMP，默认发 4 次请求，每次请求 8 字节。输出里你会看到每一行的回包信息，包括字节数、往返耗时、TTL，最后是汇总统计：发送数、接收数、丢包率，以及最小值、最大值、平均值。

这几个字段里，我建议你重点盯三个：

• 平均值：基线，用来和别的目标横向对比。同一个网段内互访，平均值应该在个位数毫秒。
• 最大值：这是排障时最有价值的数字。平均值 1ms、最大值 300ms 的链路，业务侧感受到的就是"时不时卡一下"。只看平均值会把这类问题完全掩盖。
• 丢包率：哪怕只有 1%，在长连接场景下也会被放大成明显的问题。

TCP 模式的命令是在目标后面跟端口，用冒号分隔：

psping64.exe -t 192.168.10.20:443

这条命令会尝试与目标 443 端口建立一次完整的 TCP 连接，成功就返回建链耗时，失败就返回明确的失败原因。这个"明确的失败原因"是它比很多同类工具强的地方——连接被拒绝和连接超时是完全不同的两种故障，前者说明包到了、对端回了重置，后者说明包要么没到、要么回包没回来，排查方向完全不同。

2.3 三个最常见的"跑不起来"

第一个是权限。普通 ICMP 和普通 TCP 连接不需要管理员权限，但如果你用了原始套接字相关的参数，就必须以管理员身份运行命令行。报错信息通常是权限不足或者套接字创建失败。解决方式很简单，右键以管理员身份打开终端再跑。

第二个是防火墙。这里要分清两边：出方向被本地安全软件拦了，表现是"连接超时"，而且换任何工具都一样；入方向被目标侧拦了，表现也是超时。区分方法是换一个你确定开放的目标端口试一下，如果那个也超时，问题在本地；如果那个正常，问题在目标侧策略。这个交叉验证的思路我在第 8 章还会展开讲。

第三个是地址族。目标主机同时有 IPv4 和 IPv6 地址时，解析结果可能不是你期望的那个。想强制走某一族，加-4或-6参数明确指定。这个坑在双栈环境里出现频率极高，尤其是你明明测的是内网地址，结果解析到了另一族地址上，数据完全没有参考价值。

注意：任何一次测试之前，先确认你测的地址和你以为的地址是同一个。用-d参数让它把解析结果显式打印出来，一秒钟的事，能避免后面一小时的混乱。

3. ICMP 模式：把延迟测准而不是测个热闹

3.1 报文大小、次数、间隔怎么定

默认 8 字节的请求在实际排查里参考价值有限，因为真实业务包远大于此。我的习惯是分两轮测：第一轮保持默认小包，拿到基线；第二轮用-l把包撑到接近业务真实尺寸，比如 1400 字节左右，避开分片边界。两轮结果一对比，如果大包延迟明显抬升或者开始丢包，基本可以锁定链路上有 MTU 或者限速方面的问题。

psping64.exe -l 1400 -c 20 192.168.10.20

次数方面，默认 4 次太少，只能看个大概。做质量评估我一般至少 20 次，理想是 50 到 100 次。原因很直白：偶发丢包和偶发尖峰在 4 个样本里大概率不会出现，样本量不够就等于没测。曾经有个案例，4 次测试全绿，加到 100 次之后发现每隔十几秒固定丢一个包，最后定位到中间设备的某条链路在做周期性的切换动作。这种事只靠 4 个样本永远发现不了。

请求计数参数-c控制发多少个包，把它设成 0 就是一直发下去直到你手动中断，适合观察长时间的稳定性。配合输出重定向，可以挂在那里跑十几分钟，事后慢慢看。

关于间隔，工具本身是收到回包就发下一个，节奏由网络往返时间自然决定，不提供固定的发包间隔参数。想模拟固定频率的探测，得靠外部循环加延时，但那样测出来的数据其实混入了调度误差，一般没必要。

3.2 抖动和丢包的读法

抖动这个词经常被含糊地使用，我给个能落地的算法：拿最大值减最小值，再除以平均值，得到一个相对波动比例。比如最小值 1ms、最大值 15ms、平均值 3ms，波动比例约 4.7 倍，这已经不是"轻微抖动"了，业务侧一定有感知。如果最小值 1ms、最大值 3ms、平均值 1.5ms，比例不到 1.4 倍，属于健康区间。

这种算法简单粗暴，但胜在能快速横向比较不同目标。同一个机房内互访，波动比例超过 3 倍我就认为需要深挖；跨地域访问，标准要放宽，因为物理链路本身的路径切换就会带来波动。

丢包的读法要更谨慎。ICMP 丢包有两种可能：真的丢了，或者对端/中间设备对 ICMP 做了限速和优先级压制。很多设备会主动限制 ICMP 的处理速率，甚至把 ICMP 放在最低优先级队列里。所以当你看到 5% 的 ICMP 丢包，但 TCP 建链 100% 成功且耗时稳定，那大概率不是真丢包，而是 ICMP 被特殊对待了。

验证方法很直接：同一时刻跑一遍 ICMP 和一遍 TCP，如果 TCP 干净而 ICMP 有丢，把 ICMP 的结果当参考、把 TCP 的结果当结论。这个顺序别搞反。

3.3 三种容易误判的情况

第一种是首包延迟偏高。第一次探测往往包含地址解析和路由查找的开销，耗时天然比后续几个包长。如果你只看第一个数就下结论"链路很慢"，那是冤枉它了。看平均值、看后面几个包的稳定性才是正解。

第二种是目标禁 ICMP 但服务正常。这是最常见的误判。表现是 ICMP 全超时，然后有人就认定"这台机器挂了"，实际上业务跑得好好的。遇到 ICMP 全超时，第一步不是继续加大探测力度，而是立刻换 TCP 模式打一个已知开放的端口。这一步能省掉大量无谓的纠结。

第三种是回包路径不对称。去程走一条路、回程走另一条路，在有多出口的环境里非常普遍。这种情况下 ICMP 往返时间反映的是两条路径之和，你拿它去推断单方向的质量会得出错误结论。要判断单向问题，得靠两端的对比测试，或者换别的观测手段。

在这些边界情况下，PSPing 的价值不在于给出一个漂亮的数字，而在于它能快速切换测试维度。一个工具四种模式，切换成本只有几个字符，这才是它真正的效率来源。

4. TCP 模式：验证端口真的开着、连接真的快

4.1 它到底做了什么

TCP 模式的本质是一次标准的连接建立：发 SYN、收 SYN-ACK、回 ACK，然后主动关闭。返回的耗时是这一次完整握手的时间。所以它同时验证了两件事——包能到达目标、目标端口有服务在监听并且接受连接。

这个"同时验证两件事"的特性，让它成为我最推荐的第一诊断步骤。它比 ICMP 更接近真实业务，因为业务流量本来就是 TCP；它又比直接访问应用更轻量，不需要构造完整请求。你拿到一个 3ms 的建链耗时，就知道从你这台机器到这个端口之间的所有环节——本地协议栈、网卡、交换机、路由、防火墙、目标监听队列——加起来是 3ms。这个数字是端到端的、不可辩驳的。

命令形式前面提过，目标加冒号加端口：

psping64.exe -t -n 20 192.168.10.20:3389

这里我把迭代次数加到 20，因为单次建链耗时受服务端监听队列状态影响很大，样本多点才能看出稳定值。跑完之后看最小值，那个数字最接近"无干扰情况下的真实建链开销"。

4.2 端口探测的正确姿势与判读

不同结果对应完全不同的故障方向，我把常见组合列成一张表，实际排查时直接对号：

"连接被拒绝"和"连接超时"这两个结果的区别，是整个排查里信息量最大的分叉点。被拒绝意味着网络是通的，问题在端口这一层，排查范围立刻收窄到目标主机；超时意味着网络可能就不通，排查范围是整个路径。分清这两者，能砍掉一半的无效工作。

我遇到过最典型的一次：某业务端口从办公网访问一直超时，从服务器所在网段访问一切正常。当时有人判断是"链路不通"，准备去查路由。我建议先用被拒绝和超时做区分——结果从办公网测是超时，从其他网段测同端口被拒绝。这个组合说明包能到目标主机（否则不会拒绝），但从办公网过来的包在到达之前就被中间策略静默丢弃了。方向一下子就明确了，最后确认是某台设备上的策略顺序问题。

4.3 用建链耗时区分"远"和"慢"

建链耗时高有两种截然不同的原因：物理距离远导致的固有传播延迟，和中间环节拥塞或处理慢导致的排队延迟。这两者的处理方式完全相反，前者没法优化、只能接受或者做就近部署，后者必须找出瓶颈。

区分方法就是做基线对比。同一时刻、同一源机器，分别测：

psping64.exe -n 20 192.168.10.20 psping64.exe -t -n 20 192.168.10.20:3389

如果 ICMP 平均 1ms、TCP 建链平均 1.2ms，差值只有 0.2ms，说明路径本身很快、中间没有明显处理开销，这个 1.2ms 基本就是固有延迟的下限。如果 ICMP 平均 1ms、TCP 建链平均 80ms，差值 79ms，那这 79ms 花在了某个地方——可能是中间设备在做深度检测、可能是目标主机的连接队列已满在等待、也可能是服务端应用层在 accept 之后又做了什么额外动作。

这个差值分析法几乎不需要额外工具，两个命令三十秒出结果，但能直接把问题从"整个路径"收窄到"某一段"。我把它当成排障的标准起手式，效果比漫无目的地猜要好太多。

提示：测建链耗时尽量用业务真实使用的端口。测 80 端口通不代表 3389 通，很多环境的策略是按端口粒度配置的，逐个端口验一遍才是正解，别用"一个端口通就全通"去推断。

5. UDP 模式：无连接为什么还要测

5.1 它的原理比想象的绕

UDP 是无连接的，没有握手、没有确认、没有重传，那它怎么算往返时间？答案是借力：工具发一个 UDP 包过去，如果目标端口没有监听，对端的协议栈通常会回一个"端口不可达"的 ICMP 消息，工具收到这个消息就算拿到了响应，用时间差算往返。如果端口有监听但应用不回包，那就只能等超时。

理解了这一点，你就能明白为什么 UDP 模式的结果经常看起来"不太对":它测的其实是"包能不能到、对端有没有明确拒绝",而不是"UDP 服务是否正常工作"。一个正常工作的 UDP 服务如果收到你的探测包后什么都不回（很多协议就是这么设计的），你会看到超时，但这不代表服务坏了。

所以 UDP 模式的使用场景比 TCP 窄得多，我用它的场合主要有两个：一是验证 UDP 路径是否通、有没有被策略阻断；二是在某些明确有响应机制的协议场景下快速探活。除此之外，想判断 UDP 服务质量，靠这个模式得不出可靠结论。

5.2 结果不可靠的四种典型情况

第一种，目标端口有服务但应用不响应任意报文。表现为超时，但服务完全正常。这是最容易被误判的一类，尤其是有人拿这个结论去关掉一个其实健康的服务。

第二种，中间设备对 UDP 做了特殊处理。UDP 没有连接状态，很多设备对它的策略比 TCP 宽松，也有些设备会直接限速甚至丢弃非标准端口的 UDP 流量。这种情况下测出来的超时反映的是设备策略，不是服务状态。

第三种，ICMP 回包本身被拦。原理那一节说过 UDP 模式依赖 ICMP 不可达消息，如果路径上恰好对 ICMP 做了限制，那"端口不可达"这个信号就传不回来，你看到的还是超时。这就形成一个很尴尬的局面：TCP 测不出问题，UDP 测全是超时，但两者都不是真相，真相是 ICMP 被拦了。

第四种，目标地址是负载均衡后的地址池。UDP 没有连接状态，每次探测可能落到不同后端，响应行为不一致，结果就是偶发成功偶发超时，看着像链路不稳，实际是后端不一致。

基于这些，我给 UDP 模式的定位是：辅助验证，不作结论依据。它能提供"路径可能是通的"这个弱信号，但要下结论还是得靠 TCP 或者应用层验证。把它当成一个有用的补充视角，而不是决定性证据。

6. 带宽模式：把链路吞吐量测出来

6.1 为什么要预热，为什么测两遍

带宽模式的原理很简单：往目标端口连续发送大量数据，测量单位时间内传输的量。但它有一个必须理解的细节——预热。

TCP 连接刚建立的时候，拥塞窗口很小，发送速率是被逐步"放开"的。如果一上来就统计，测到的数字反映的是慢启动初期的速率，远低于链路实际能力。预热的作用就是先发一批数据把窗口撑开，等速率稳定下来再开始正式统计。工具默认会做若干次预热迭代，你把预热次数调大，结果会更接近真实能力。

这就是为什么同样一条链路，用一两秒的短测试和用十秒的长测试，结果能差出一截。短测试大部分时间都在慢启动阶段，长测试才有足够时间跑到稳态。做带宽评估至少要跑够能覆盖慢启动的时长。

测两遍是因为工具会分别测上传和下载两个方向。这两个方向的数字不一致是常态，尤其在非对称链路上，或者单向限速策略存在的情况下。如果上下行差异明显，那基本可以确认存在单向限制，这个发现对容量规划很有价值。

6.2 报文大小与吞吐的计算

指定请求大小的参数在带宽模式里影响很大。默认值通常只有几 KB，包太小会导致单位时间内需要处理的包数量暴涨，很容易先撞上设备的数据包处理能力上限，而不是链路带宽上限。表现出来就是"带宽上不去，但 CPU 也上不去，链路也没跑满"。

我一般把报文大小设到接近 MTU 的安全值，比如 1400 字节左右，让每个包尽量承载有效载荷，减少包处理开销的干扰。同时配合多次迭代取稳定值。

这里有个很多人不知道的计算，能解释大量"带宽测不准"的困惑。单条 TCP 流的理论最大吞吐，受带宽时延积限制：

最大吞吐 ≈ 窗口大小 / 往返时间

举个具体数字。假设窗口大小 64 KB，往返时间 40ms：

吞吐 = 64 × 1024 × 8 bit / 0.04 s ≈ 13.1 Mbps

也就是说，哪怕链路本身是 1 Gbps，单条 TCP 流在这组参数下理论上也只能跑到 13 Mbps 左右。这不是工具的问题，也不是链路的问题，是 TCP 的流量控制机制决定的。想突破，要么加大窗口（需要两端协商支持），要么开多条并发流。

反过来算带宽时延积：1 Gbps 链路、往返 40ms，那在途数据量需要达到：

1 × 10^9 bit/s × 0.04 s ÷ 8 ≈ 5 MB

5 MB 的窗口才能填满这条管道。默认窗口 64 KB 差了将近 80 倍，这就是长距离高带宽场景下"单流传不动"的根本原因。理解了这套计算，你在看到带宽测试结果远低于链路标称值时，就知道该先怀疑窗口，而不是先去骂网络设备。

6.3 单流瓶颈与定位边界

带宽测试的输出只有两个数字：上行和下行。这两个数字能回答的问题很明确——"在这个源、这个目标、这个端口、当前时刻、单流条件下，能跑到多少"。它回答不了的问题包括：多流聚合能跑多少、并发连接数上限是多少、长时间满载会不会掉速、极端包大小下表现如何。

所以别拿它的数字去写容量报告，也别用它去论证"链路达标"或者"链路不达标"。它是个快速体检工具，不是性能验收工具。快速体检的价值在于：如果连单流都跑不出合理数字，那链路或者策略肯定有问题，可以立刻深挖；如果单流数字正常，那至少说明基础通路没问题，剩下的问题在更高层。

我踩过一次坑，值得说一下。当时判断一条跨地域链路"带宽严重不足"，因为单流测试只有 20 多兆。准备走扩容流程之前，先开四个并发实例重测了一遍，结果加起来跑到了一百多兆。结论立刻反转：链路能力没问题，是单流窗口受限。要是没做这一步验证，扩容申请就白提了，而且真正的瓶颈还会继续存在。

7. 一次跨网段排障的完整记录

7.1 现象描述

某办公网段的用户反馈，访问某个内部管理端口时一直超时，而同网段访问其他服务完全正常。管理侧的同事在自己工位上测了一遍，一切正常，于是初步判断是"用户端网络问题"。这个判断前后拖了两天，用户那边反复重启网络设备也没解决。

我接手之后，第一步不是去用户机器上折腾，而是先在两个不同网段分别做同一组测试，把"用户端问题"这个假设直接证伪或者证实。

7.2 逐层测试的命令与数据

先测基线，确认目标主机在线：

psping64.exe -n 20 10.20.30.40

结果：20 发 20 收，平均 1.2ms，最小 1.0ms，最大 1.8ms。主机在线，路径通畅，抖动很小。这一步排除了主机宕机和链路中断。

再测目标端口，从办公网段发起：

psping64.exe -t -n 20 10.20.30.40:8443

结果：20 次全部超时。到这里出现了一个关键矛盾——ICMP 通，TCP 不通。说明包能到达主机，但目标端口这一层出了问题。

为了区分"端口没开"和"包被拦了"，换一个已知开放的同主机端口测试：

psping64.exe -t -n 20 10.20.30.40:3389

结果：20 次全部建链成功，平均 1.5ms。同一个主机、同一个源、同一时刻，3389 通而 8443 不通。这个组合几乎可以确定：不是网络不通，是 8443 这个特定端口的策略有问题。

为了进一步确认方向，从另一个网段测 8443：

psping64.exe -t -n 20 10.20.30.40:8443

结果：全部返回连接被拒绝。注意，这里是被拒绝，不是超时。

7.3 数据对比与结论

把三组数据放在一起看：

从源网段 B 得到"被拒绝"，说明包到达了目标主机，主机上的监听状态是不接受连接（要么服务没起，要么本地策略拒绝）。从源网段 A 得到"超时"，说明从办公网过来的包在到达主机之前就被静默丢弃了。

两个结论合起来：目标端口本身就没有正常提供服务（这解释了 B 网段的拒绝），同时办公网到该端口之间还有一段策略在静默丢弃（这解释了 A 网段的超时）。这是两个独立问题叠加，如果只看其中一边，永远得不出完整图景。

后续动作就明确了：先在目标主机上确认服务状态和本地策略，再检查办公网到该主机路径上的策略配置。整个排查从接手到定位方向，用了不到十分钟，核心就是三条命令加一张对照表。

注意：这个案例里最有价值的一步是"换源对比"。同一个目标、同一个端口、不同源地址，结果不同，直接把问题范围从"端到端"切割成了"某一段"。这个手法在跨网段、跨区域、跨策略域的排查里通用性极强，成本又极低。

8. 常见问题速查与脚本化套路

8.1 排查速查表

把前面散落的各种情况汇总成一张表，遇到问题先在这张表里找对应行：

8.2 批量端口验证脚本

手工一条条敲太慢，这种活交给循环。下面这段在常见命令行环境下都能跑，思路是把端口列表遍历一遍，每个端口单独测一次，只保留关键信息：

for port in 22 80 443 445 3389 8080 8443; do echo "===== testing port ${port} =====" psping64.exe -t -n 3 10.20.30.40:${port} done

每个端口 3 次，够判断通还是不通，又不至于太慢。如果目标多、端口也多，建议把输出重定向到文件，事后统一分析：

psping64.exe -t -n 5 10.20.30.40:443 > result.txt 2>&1

这里补一个实战细节：2>&1别漏。有些版本的错误信息走标准错误输出，不合并的话文件里只剩正常结果，看着一切正常，实际上失败信息全丢了。这个细节在写巡检脚本的时候特别重要，我曾经因为漏了这个，脚本连续报了三天"全部正常"，实际上目标早就不可达了。

8.3 留证与对比的习惯

做网络排查有个习惯我强烈建议养成：每次测试都把原始输出留下来，别只看屏幕上的数字就往工单里写结论。原因有三：一是数据可以事后复核，二是不同时间点的测试结果可以横向对比，三是和不同人协作时，原始输出比你的转述可信得多。

具体做法很简单，给输出文件加上时间戳和测试目标，一眼就能看出是什么时候测的什么：

psping64.exe -t -n 20 10.20.30.40:443 > "tcp443_20250115_1430.txt" 2>&1

批量场景下可以用循环自动生成文件名，避免手工改来改去出错。文件命名我一般用"模式_目标_时间"这个顺序，排序之后同目标的历次测试会自动聚在一起，做趋势对比特别方便。

最后再分享一个我在实际排查里用得很顺的组合：拿到一个问题，先跑 ICMP 20 次拿基线，再跑 TCP 到业务端口 20 次拿建链数据，两个数字做差。差值小，问题在应用层；差值大，问题在路径或服务端处理；两个都超时，问题在网络通路。三步三十秒，能砍掉后面很多弯路。

这套打法我用了很多年，工具本身没什么神秘的，真正起作用的是"先分层、再切片、最后对比"这个顺序。工具只是把这个顺序里的每一步变得足够快而已。