在Shadowrocket中查看节点测速结果时，用户应优先明确当前设备的主要使用场景，如果以网页浏览、流媒体观看和日常搜索为主，选择TCP延迟数值最低的节点作为主力出口，因为该指标直接决定了每个页面请求建立连接的实际等待时间，与首字节响应速度高度相关。如果设备主要用于外服游戏对战或实时音视频通话，则应切换关注ICMP延迟的稳定性和波动范围，因为UDP游戏数据包的处理路径与ICMP探测高度重合，稳定的ICMP延迟意味着更精准的操作响应。测速后建议记录下各节点的TCP和ICMP延迟数值及测试时段，观察多天内的趋势变化，一旦发现某个节点的TCP延迟相对于其ICMP延迟持续攀升至百毫秒以上差值，应立即切换至备用节点避免服务质量持续劣化。日常浏览场景下将节点列表按TCP延迟升序排列并固定使用头部节点，游戏场景下则重点关注ICMP延迟的跳动范围，若某节点的ICMP延迟在多次测速中稳定且无超时记录，即可作为游戏专用出口。同时注意测速时间点对结果的影响，提前在目标使用时段进行测速，并以最近的测速结果作为节点选择的最终依据，确保所选节点在实际使用的网络窗口中具备最优表现。
探测机制与协议层级的本质差异
ICMP延迟基于网络层探测，反映的是路由节点的基本响应速度
ICMP延迟测试使用的是ping命令所依赖的网络层协议，Shadowrocket在测速过程中会向目标服务器发送一个ICMP回显请求数据包，当目标服务器收到该包并返回回显应答时，应用会记录从发出到接收这一完整往返所消耗的时间，并将其显示为ICMP延迟数值。这一过程在协议栈中的层级极低，它不涉及任何传输层的握手协商或应用层的数据交换，仅仅验证了从设备到目标服务器的IP路由是否可达以及网络链路的物理往返时间。因此ICMP延迟本质上是衡量“这条路通不通”和“光信号跑一个来回需要多久”的纯物理指标，与目标服务器上是否运行着具体的业务服务并无直接关系。
TCP延迟基于传输层握手，模拟的是实际连接建立的完整过程
TCP延迟测试则完全模拟了真实网络连接建立的流程，Shadowrocket会向目标服务器的特定端口发送一个SYN同步报文，当服务器回应SYN-ACK确认报文后，应用再发送ACK完成三次握手的最后一个步骤，记录从发出第一个SYN到完成整个握手流程所消耗的全部时间作为TCP延迟数值。这一过程不仅包含了ICMP延迟中的网络传输耗时，还额外包含了目标服务器的操作系统在接收到连接请求后分配资源、调度线程处理SYN队列以及生成SYN-ACK响应的全部处理时间，反映的是服务器端操作系统在实际处理连接请求时的真实性能表现。
两个协议在防火墙和路由策略中的处理优先级不同
由于ICMP协议常用于网络诊断，许多网络运营商会将ICMP数据包标记为低优先级，在路由节点发生拥塞时率先丢弃这些探测包以保障业务流量的正常传输，这种策略可能导致ICMP延迟在高峰期显著增大甚至超时，但实际的TCP业务流量却依然畅通。反观TCP协议是承载真实数据传输的协议，运营商和路由节点通常给予其更高的处理优先级以保障用户正常的网页访问和邮件收发体验。这种优先级差异使得ICMP延迟在特定网络环境下可能无法准确反映TCP流量的实际转发状态，用户需要认识到两个协议在同一网络路径上可能获得完全不同的服务质量。
目标服务器响应负载差异对测试结果的影响
TCP延迟直接受服务器当前连接队列和处理负荷的影响
当一台代理服务器处于高负载状态时，其操作系统维护的TCP半连接队列和全连接队列可能已经接近饱和，新到达的SYN请求需要等待队列中的旧连接被处理后才能获得响应，这一排队等待时间会直接累积在TCP延迟的测量值中。而ICMP回显应答通常由服务器内核中的网络层模块直接处理，不经过连接队列和应用层的调度逻辑，即使服务器应用层已经极度繁忙，内核依然能够快速响应ping请求，使得ICMP延迟保持低数值而TCP延迟却持续攀升。因此当用户看到ICMP延迟理想而TCP延迟却高得异常时，几乎可以断定目标服务器正在经历高负载或应用层处理瓶颈。
防火墙策略对ICMP和TCP流量的不同处理路径
部分代理服务器的网络架构中，ICMP和TCP流量可能被防火墙或负载均衡器引导至不同的处理路径，其中ICMP请求可能直接被边缘路由器响应而不触及后端服务器，而TCP请求则需经过多层安全检测和负载均衡后才到达实际运行代理服务的进程。这种架构差异会导致ICMP延迟极低但TCP延迟显著偏高，因为ICMP并未穿越真正构成性能瓶颈的复杂链路。用户在使用测速结果评估节点时，应该认识到TCP延迟比ICMP延迟更贴近真实代理服务的可用性状态。
TCP延迟能提前感知代理进程的故障而ICMP无法感知
当代理节点上运行的服务进程因内存溢出或配置错误而卡死时，服务器的操作系统内核可能仍然能够正常响应ping请求，使得ICMP测速结果显示节点可达且延迟正常，但代理服务进程却已经无法完成任何新的TCP连接握手。这种情况下TCP延迟测试会因握手步骤无法完成而直接超时，用户据此可以立即判断该节点已不可用。对于Shadowrocket用户而言，优先参考TCP延迟能够更早地发现节点故障，避免因ICMP结果的假性正常而持续使用失效节点。
两者在测速结果中的数值分布规律解读
典型网络环境下TCP延迟始终高于或等于ICMP延迟
由于TCP握手过程包含了ICMP回显往返的全部路由耗时，并且额外叠加了服务器端处理SYN请求的系统调用开销和队列调度耗时，TCP延迟在绝大多数情况下都会略高于或等于同节点的ICMP延迟。如果用户看到某个节点的TCP延迟数值反而低于ICMP延迟，这通常不是协议特性导致的正常现象，而是因为两次测速分别发生在网络质量差异极大的不同时间窗口，或测速过程中目标节点的路由发生了切换。正常情况下两者之间的合理差值范围在十至五十毫秒之间，如果TCP延迟超出ICMP延迟百毫秒以上，则说明服务器端的连接处理存在显著瓶颈。
ICMP延迟稳定但TCP延迟大幅波动反映服务器负载不稳
当用户多次测速发现ICMP延迟始终稳定在一个较小区间而TCP延迟却在数十毫秒至数百毫秒之间剧烈跳动时，这种模式清晰地指向了服务器端的连接处理性能存在波动，可能是由于同一服务器上承载了过多用户或在特定时段被攻击流量耗尽资源。在这种情况下，用户应该以TCP延迟的高位数值作为实际使用的预期延迟，而不是被ICMP的稳定表现所迷惑，因为在真正访问网络时每个请求都需要经过TCP握手，服务器的高负载状态会直接转化为页面加载的卡顿感受。
两种延迟同时升高反映基础网络路径问题而非服务器性能
当ICMP延迟和TCP延迟同步升高且两者数值接近时，问题根源几乎可以确定不在服务器端的处理能力上，而是从设备到代理服务器之间的整条网络路径存在拥塞或路由绕行，此时无论是ping探测还是真实的TCP握手都需要穿越同一条拥挤的物理链路。这种模式下用户无法通过更换节点内部的配置来解决延迟问题，正确的应对策略是切换至地理位置更近或路由链路不同的其他节点，从物理层面缩短传输路径或避开拥塞的骨干网段。
对日常网页浏览体验的代表性差异
TCP延迟直接决定了网页首字节的等待时间
当用户在Shadowrocket开启代理访问网站时，浏览器发出的第一个网络操作就是向目标网站服务器发起TCP连接请求，这一过程涉及SYN、SYN-ACK和ACK三个数据包的完整交换，其全部耗时完全由TCP延迟决定。换句话说TCP延迟是多少，用户点击链接后页面开始加载前的等待时间就至少是那个数值，因为首字节必须等待握手完成后才能开始传输。相较之下ICMP延迟并不参与任何真实的网络连接过程，它无法代表用户在实际访问页面时面临的等待时长。
ICMP延迟无法反映服务器端应用程序的处理瓶颈
想象一个场景，代理节点的ICMP延迟仅为十毫秒，但TCP延迟却高达五百毫秒，用户在此时访问页面时每一次请求都要花费半秒钟来等待连接建立，累积下来页面加载的总耗时将远超正常水平。此时的用户体验完全由五百毫秒的TCP延迟主导，十毫秒的ICMP数据在用户感知层面等同于不存在，因为它代表的是“网络这条物理路径有多快”而非“这台服务器现在工作得怎么样”。因此以TCP延迟作为页面加载速度的预测指标远比ICMP延迟更具参考价值。
低ICMP配合高TCP时浏览器卡顿但ping工具显示“良好”
这种反差现象在用户群体中极为常见，用户使用ping工具测得节点延迟极低，便在主观上认定节点处于健康状态，却在实际浏览网页时感受到频繁的卡顿和响应滞后。这种认知偏差的根源在于测速工具选择了错误的测量对象，ping所测量的ICMP延迟只验证了网络可达性，完全没有触及服务器应用层的服务能力，而用户感知到的卡顿恰恰来源于应用层的响应处理效率。培养“TCP延迟优先”的认知习惯能够帮助用户快速识破这类误导性的测试结果，将注意力集中在真正影响体验的指标上。
对外服游戏等实时应用的代表性差异
游戏操作的实时响应更依赖ICMP延迟的稳定性而非绝对值
与外服游戏服务器的通信路径中，UDP数据包占据主导地位，这些数据包的处理路径与ICMP探测包高度相似，两者均以极低的协议栈开销直接进出网卡，不过经历操作系统的TCP连接管理和队列调度。因此ICMP延迟的数值和抖动幅度能够非常准确地反映游戏数据包在网络上传输的物理时延，而TCP延迟则因包含了服务器端针对SYN请求的额外处理开销，无法代表UDP数据包的实际通信耗时。当用户以游戏体验为主要关注点时，ICMP延迟反而比TCP延迟更有参考价值。
TCP延迟对游戏流畅度的参考价值远低于网页浏览
游戏与普通网页浏览在协议使用上的根本差异，导致了测速结果对两种活动的预测能力完全不同。游戏数据包多为UDP短报文，不涉及TCP连接管理和流控机制，因此服务器端的TCP半连接队列长度不会影响UDP报文的处理速度，TCP延迟高并不必然意味着游戏UDP丢包或高延迟。用户需要根据实际使用场景选择关注的测速指标，如果主要用于游戏，优先参考ICMP延迟的稳定性；如果主要用于网页浏览，则将TCP延迟作为主要决策依据。
游戏场景下ICMP延迟的微小波动对手感影响巨大
外服射击类游戏中，操作指令发出到命中判定返回所经历的全过程与ICMP回显请求的往返路径高度重合，因此ICMP延迟的每一次抖动都可能转化为玩家视角中准星偏移或伤害判定的时间误差。即使ICMP延迟平均值仅为六十毫秒，如果其波动范围在正负二十毫秒之间高频跳动，玩家依然会感受到明显的操作粘滞感，这比TCP延迟绝对值是否理想更加关键。对于竞速和电竞类游戏用户，Shadowrocket的ICMP测速结果是比TCP延迟更具指导价值的筛选依据。
综合判断与测速结果的实际使用建议
日常网页浏览和流媒体观看首选TCP延迟低的节点
当用户的使用场景主要是搜索信息、查阅资料、观看视频或处理邮件时，每一次页面点击都伴随着新的TCP连接建立过程，TCP延迟直接决定了这些操作的响应速度。推荐用户在当前节点列表中按TCP延迟数值进行排序，选择延迟最低且波动范围在十毫秒以内的节点作为日常主力，同时以ICMP延迟作为排除网络基础路由故障的辅助参考。
外服游戏和实时语音通话优先关注ICMP延迟的稳定性
如果用户的使用需求集中在在线竞技和实时对战的场景中，选择节点时应重点关注ICMP延迟的短期抖动范围和丢包率，而不是TCP延迟的绝对值。稳定在较低区间的ICMP延迟能够保证游戏指令的实时传输精度，而TCP延迟即使相对较高也不会直接影响UDP游戏数据包的收发效率，两者的应用场景存在明确的界限。
长期使用的节点应同时监测两个数值的趋势变化
随着节点服务商调整服务器配置或上游路由发生变化，一个节点可能从“低TCP低ICMP”的最佳状态退化至“低ICMP高TCP”的高负载状态，这种退化在短期内可能被忽略但在长期使用中显著损害体验。建议用户每周至少执行一次全面的节点测速，记录各节点的TCP和ICMP延迟数值及其变化趋势，当发现某个节点的TCP延迟连续一周显著上升时及时切换至备用节点，避免在节点性能劣化后仍持续依赖同一出口。
常见问题FAQ
为什么ICMP延迟超时但TCP延迟却正常？
这种情况通常发生在目标服务器或中间路由设备配置了防火墙策略，主动丢弃或拒绝处理ICMP数据包以降低攻击风险，却允许TCP协议正常通行。该现象在部分注重安全的机房和云服务商中较为常见，此时ICMP测速结果完全失效，用户应以TCP延迟作为节点可用性的唯一判断依据，忽略ICMP的超时报错。
测速时TCP和ICMP延迟相差多少算合理？
在正常网络环境下，TCP延迟通常会比ICMP延迟高出十至五十毫秒，这是由TCP三次握手的额外处理开销决定的。如果两者差值超过一百毫秒，则说明目标服务器的连接处理存在较大延迟，很可能处于高负载状态或防火墙策略导致SYN请求被排队处理，用户应考虑切换至其他节点以获得更流畅的访问体验。
流媒体播放卡顿应该参考哪个延迟？
流媒体播放的卡顿主要受到TCP延迟和节点带宽的共同影响，但TCP延迟是决定因素之一，因为它直接控制了视频分片请求的首字节响应时间。建议用户在播放流媒体时选择TCP延迟最低且下载测速结果最高的节点，ICMP延迟在此场景下的参考价值有限。
延迟测试的时间点不同，结果差异很大，哪个为准？
网络延迟会因时段、服务器负载和全球网络拥塞程度而产生剧烈变化，测速结果仅代表测量瞬间的网络状态。建议用户在早中晚三个不同时段分别测速并取综合表现最佳的节点作为主力，同时在抢购或游戏等关键活动前五分钟重新测速确认节点的实时状态，以最新一次的测速结果为准进行选择。