Dedicated IPs
Order a dedicated IP for Bedrock, Geyser or voice modules — and understand its lifecycle.
A dedicated IP is a public IPv4 reserved for a single network. It is required for Bedrock (via Geyser) and for voice modules (PlasmoVoice, SimpleVoiceChat). Java-only setups don’t need one.
When you need a dedicated IP
| Use case | Dedicated IP required? |
|---|---|
| Java Edition players over CNAME | ❌ Shared edge is enough |
| Bedrock Edition players via Geyser | ✅ Required |
| PlasmoVoice / SimpleVoiceChat | ✅ Required |
| Votifier / NuVotifier | ✅ Required |
The reason: Bedrock’s UDP packets only carry the client IP — they don’t include a connected hostname. Domain-based filtering is impossible the way it is for Java, so each Bedrock setup needs a unique IP to be unambiguously identified at the edge.
How to order one
Open Network → Backends. At the top of the page, the Dedicated IP card shows either the current status or an Order Dedicated IP button.
Clicking the button opens the Dedicated IP dialog, which lets you pick the region the IP will live in. Each region shows its stock status — pick one that’s In stock and click Next.
Once payment is completed, the panel delivers a dedicated CNAME in the form:
{uid}.ip.infinity-filter.com
That CNAME — not the resolved IP — is what you use everywhere (Geyser backend module, Bedrock DNS, voice module backends).
How it behaves
One dedicated IP = one network Dedicated IPs cannot be shared across networks. Multi-network Bedrock setups need one each.
Bound to one PoP A dedicated IP lives in a single PoP. Moving it to another PoP is an admin-side operation; the CNAME stays the same — only the resolved IP changes.
Inbound only The dedicated IP is used solely for player → IF traffic. Outbound (IF → backend) uses the standard IF proxy ranges, so backend firewall allowlists should target those ranges, not the dedicated IP.
Mitigation preserved Using a dedicated IP doesn't reduce mitigation capacity — the dedicated IP internally redirects to multiple machines.
Latency cost Bedrock and voice traffic always route via the dedicated IP, which may sit in a different PoP than your Java edge. Typical added latency vs. the closest Java region is ~10–15 ms.
Pricing details
- Prorated checkout mid-cycle is normal. A dedicated-IP order in the middle of a billing period may show €0 due now, with the full charge applied at the next billing cycle.
- The Bedrock plan costs more than a raw dedicated IP because it bundles UDP mitigation infrastructure — UDP is significantly harder to filter than TCP. The IP itself is only one component of what’s billed.
- Out-of-stock regions can still be served. If a region shows out of stock in the panel, an admin can provision one manually on request — the CNAME is still delivered the same way.
Using the dedicated CNAME
For Bedrock
Add a CNAME on the subdomain players use:
bedrock.example.com. 300 IN CNAME {uid}.ip.infinity-filter.com.
No SRV needed. No port to advertise to players — Bedrock always uses port 19132. See Geyser integration.
For voice modules
The voice_host configured in your Velocity/BungeeCord proxy and in every Spigot backend must point at the dedicated CNAME (the value is identical everywhere; only the listening port may differ per server).
In the panel, the voice module backend is the proxy’s IP and the proxy-side plugin’s listening port — not the per-Spigot port. See Voice integrations.
For Java (optional)
Java can use a dedicated CNAME too, but it requires an extra SRV record:
play.example.com. 300 IN CNAME {uid}.ip.infinity-filter.com.
_minecraft._tcp.play.example.com. 300 IN SRV 0 5 25565 play.example.com.
Most Java-only setups don’t need this — the shared edge works perfectly. See SRV records.
Renewal caveat
During subscription renewal, billing has been observed to wrongly flag a dedicated IP for cancellation — breaking Bedrock and voice modules. If a working module suddenly stops after a renewal, this is almost always the cause. Contact support and we’ll re-enable it platform-side.
What’s next
Last updated: May 28, 2026