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

Look at the ping the player actually sees in their Minecraft client — the signal-strength bars on the server list, or the value shown when hovering them (and in the Tab player list once connected).

A few ms of overhead on top of a direct connection is expected and normal. If a player reports a much higher ping than others in the same region, the cause is almost always one of the items below.

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 the client shows a 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