On this page
Key points
- Two problems, different controlsA saturated network path and repeated application logins need different evidence and defenses.
- A proxy needs a protected backendChanging the public address does not prevent direct access to an origin that remains exposed.
- Accept a working player journeyCheck authentication, lobby access, backend switching and ongoing play, not only the server-list response.
Identify the edition, public entry point and real service path
Map the connection a player actually uses: public name and port, any protection endpoint, the game proxy, lobby and game backends. Include a separate resource-pack service or management panel if it shares the same host or network. Record the owner of each component. A protection plan cannot be evaluated solely from the IP shown in a hosting panel.
Minecraft Java normally uses TCP for gameplay; Bedrock uses a different transport. A custom listener, cross-edition gateway or optional query service adds its own requirements. The Java service described by Peeryx must not be assumed to cover Bedrock or every gateway. Submit the actual topology, game versions and required protocols for compatibility review.
Distinguish network floods from bot and login pressure
A network flood can consume the uplink or packet-processing capacity before the game software can make a decision. Repeated connection attempts, status requests or logins can instead consume work at the proxy, authentication stage or backend. Both can happen together, but one bandwidth graph cannot establish which layer is failing.
Compare network bytes and packets, connection counters, proxy logs and application health over the same time interval. Record whether new players, existing players or a single backend are affected. A bot count is not a bandwidth measurement, and a low bandwidth figure does not prove the connection path has enough processing capacity.
An application anti-bot control cannot recover packets already lost upstream. Conversely, upstream volume reduction does not replace version compatibility, authentication or game-specific admission controls. Choose the layer that can relieve the observed bottleneck and test normal players after each policy change.
Limit direct backend access before relying on a proxy
A new public proxy address does not make an old backend address unreachable. Review both IPv4 and IPv6 exposure, additional listeners and shared-host restrictions. The permitted proxy-to-backend path should be explicit; a public game listener and administrative access are different services with different owners.
Restrict backend access to the required proxy paths. Identity forwarding is a separate trust control, not a substitute for network access restrictions. PaperMC and SpigotMC both document backend isolation for proxy deployments.
Prepare a change record containing permitted proxy sources, backend destinations and ports, who can update the rules and how to recover administrative access. Verify allowed proxy traffic and rejected direct access from an authorized external test point. Do not replace the current firewall with a generic command copied from an article.
Check Velocity and BungeeCord identity forwarding separately
Velocity modern forwarding requires compatible servers and matching forwarding configuration. BungeeCord-compatible legacy forwarding is a different format. Select the supported mechanism for the actual versions; do not treat the mode names as interchangeable.
Keep the trust boundary visible in the deployment record: which component authenticates the player, which forwards identity and which backend accepts that information. Review plugins that use the player address, UUID or permissions. A connection that reaches the backend but fails an identity check is not proof that DDoS filtering blocked it.
Follow the proxy project’s current configuration documentation and protect forwarding secrets. Do not disable player authentication at the public entry point merely to make a failed test pass. Peeryx compatibility review must consider the proposed delivery; this guide does not assert universal support for every proxy chain.
Choose protection around the addresses and routing you control
A single public Minecraft Java endpoint and a hosting network advertising many prefixes do not have the same delivery scope. A game-specific service should be reviewed around its origin and connection requirements. Protected Transit IP is a network service with its own addressing, routing and handoff conditions. A gaming option on transit and a standalone game-delivery offer are separate purchases.
If you operate compatible filtering equipment, local controls may form another layer. They still need transport capacity upstream and a clear path through the network. Avoid counting a software licence, a port speed or a provider’s shared network figure as reserved capacity for one game server.
Move the entry point with a reversible plan
Record the existing public name, address, listener and routing before a change. Determine whether the delivery changes DNS, a proxy destination or the network route. Check what clients have cached and how the old endpoint will be retired. Lowering a DNS TTL is not proof that every player has already refreshed it.
Agree on the acceptance window, observations and rollback owner. Retain an approved way to recover the previous service while testing. Additional proxies can change source visibility, latency and failure dependencies; compare measurements from relevant player networks instead of promising a universal latency improvement.
Test the whole player journey
Use normal clients from representative external networks. Start with a successful baseline, then repeat the same sequence after the planned change. Test new connections separately from existing sessions and record the time, client version, destination and result. A successful ping or server-list response is only one observation.
| Stage | Evidence to record | What it does not prove |
|---|---|---|
| Name and destination | The address and port used by the test client | That the proxy can reach the correct backend |
| Connection and login | A new player completes authentication | That all backends or versions work |
| Lobby and server switch | The player reaches each intended backend | That unrelated backends have the same policy |
| Normal play | Actions remain usable under representative player load | An independently measured attack-capacity benchmark |
| Agreed recovery | The user journey works after the chosen path change | Survival of untested router, power or upstream failures |
Questions about Minecraft protection and proxies
Is hiding the backend IP enough?
No. Names and published addresses can change while the origin remains directly reachable. Validate backend access restrictions and the intended proxy path; obscurity is not an access-control policy.
Does anti-bot protection replace network DDoS protection?
No. They address different resource limits. Identify where loss or work exhaustion starts, then combine appropriate network and application controls without assuming either covers every layer.
What should I send for a compatibility review?
Send the edition and versions, hosting provider, public endpoint, proxy and backend layout, required protocols, typical player load and the exact symptom. Do not send private keys, passwords or forwarding secrets.
