Latency issues

Going through Infinity-Filter adds a small hop. Total latency is player-to-edge RTT + edge-to-backend hop, typically 3–6 ms on top of a direct connection. Higher than that usually means a misconfiguration.

Step 1 — Establish a baseline

Run the Latency Test. Compare the edge-to-backend RTT of every PoP to your backend.

• The lowest one is your reference. If your current CNAME region isn’t that one, change it (it’s non-disruptive).

Step 2 — Check the player-side ping

From the player’s machine:

bash

$ mcstatus play.example.com:25565 pingClick to copy

14.2 ms

Compare with a known-good baseline (e.g. their ping to a Cloudflare endpoint):

bash

$ ping 1.1.1.1Click to copy

8.4 ms

If the IF ping is 14 ms and the baseline is 8 ms, the IF overhead is 6 ms — that’s normal.

Common causes of unexpectedly high ping

Wrong CNAME region

If your backend is in Germany but the CNAME points to front-ca, every connection routes through Canada. Players in Europe see ~100+ ms instead of ~10 ms.

Fix: run the Latency Test and pick the closest PoP.

Bedrock / voice through a dedicated IP in a different PoP

Bedrock and voice traffic always route via the dedicated IP. If the dedicated IP is in a different PoP than your Java edge, you pay an extra ~10–15 ms versus the closest Java region. This is by design.

If the regional gap is too large, contact support — admins can migrate the dedicated IP to another PoP without changing the CNAME.

Player ISP routing

Sometimes a player’s ISP routes traffic via a suboptimal transit. This is independent of Infinity-Filter — the same player would see the same ping to any provider in the same PoP.

Run a traceroute from the player’s machine to confirm:

bash

$ tracert play.example.com # WindowsClick to copy$ traceroute play.example.com # Linux/MacClick to copy

If the route bounces through unrelated cities (e.g. a German ISP routing through London to reach Frankfurt), the issue is upstream of IF.

Backend slow to respond

If mcstatus shows healthy ping but joining feels laggy:

• Backend CPU saturated.
• Backend disk I/O saturated.
• Per-tick lag on the Spigot server.

The Latency Test only measures network-layer RTT; it doesn’t catch backend application-layer slowness.

Lag spikes during attacks

During a DDoS, the upstream filtering layer is busy dropping malicious packets. Brief latency spikes are normal.

If lag persists after the attack ends:

• Check the Mitigation tab. Under Attack mode may still be on.
• Check Analytics for sustained high CPS that’s keeping the antibot warmed up.

Latency depends on backend type? (VPS vs. dedicated)

No. Backend-to-edge latency depends only on geographic proximity, not on whether the backend is a VPS or a dedicated server. A VPS 1 km from our PoP has lower edge-to-backend RTT than a dedicated server 500 km away.

Common one-line diagnoses

What’s next