[Network] Severe Packet Loss & High Ping Specifically for Cloudflare WARP (AS13335) UDP Traffic

Community Technical Support Crashes, Connection, Update Problems & Advice
1

image
image1122×678 170 KB

image
image1122×694 180 KB

  1. Issue Summary:
    When connecting via Cloudflare WARP, the game experiences severe latency (600-999ms) and constant packet loss (>20%). However, rigorous UDP testing through the same WARP tunnel to other destinations shows near-perfect connectivity.

  2. Test Methodology & Evidence:
    To isolate the issue, I conducted a 11,000+ packet UDP trace using Trippy (ICMP/UDP) targeting 8.8.8.8 while connected to the exact same Cloudflare WARP node used for War Thunder.

*Trippy Results: 11,282 packets sent, only 40 failed. Packet Loss: 0.4% . Latency is stable.
*In-Game Results: Ping fluctuates between 600ms and 999ms. Packet Loss (PL) hits 20% to 37% consistently in matches.

  1. Technical Deduction:
    The discrepancy proves that local ISP and the WARP tunnel are functioning perfectly. The failure is occurring on the “Last Mile” between Cloudflare’s egress node and Gaijin’s game servers .

It is highly likely applying strict QoS throttling or dropping UDP packets originating from Cloudflare’s AS13335 range on the network path.


2
  • Loss% = 7% ：在这一跳，Trippy 发出的探测包有 7% 没有收到任何响应 。也就是说，有 7% 的“回声”消失了。
  • Fail = 0.5% ：Trippy 在发送环节 就失败的探针比例非常低，只有 0.5%。Fail 列在 Trippy 中特指“发送失败的探针数量”，是工具层面的发送错误，而非等待响应超时。

关键推论 ：如果真的是网络链路在大量丢数据包，理论上发送环节本身也会更容易出问题，Fail 不会只有 0.5%。7% 的 Loss 远远高于 0.5% 的 Fail ，说明绝大多数“消失的响应”并不是因为包没能发出去，而是发出去了，但那一跳的“主人”选择不回应 。

🎭 这 7% 的 Loss 大概率是“伪丢包”

中间路由器（尤其是骨干网设备）的 CPU 主要任务是转发数据，处理诊断用的 ICMP 响应只是“副业”。为了不让自己过载，它们会主动限速甚至直接丢弃 ICMP 探测包 。

这正好解释了你的数据：发送基本正常（Fail 0.5%），但大量探针被路由器“已读不回”（Loss 7%） 。多个来源都印证了这一点：孤立的中间跳点出现丢包，最常见的元凶就是设备限速；阿里云的文档也明确指出，某跳出现丢包但后续跳点恢复正常，基本可以判定是 ICMP 策略限速所致。

–关于LOSS和FAIL的解释

3

The command from terminal is :sudo trip -u 8.8.8.8

-u : udp