If you’ve ever tried to run a Minecraft server from home or stitched together a small server network for friends, you’ve bumped into the question of how players reach your world. That’s where IP forwarding enters the picture. It sounds technical, and it is, but it’s also approachable once you see what problems it solves. Whether you’re hosting a Java SMP on a spare PC, renting a VPS, or assembling a proxy-based network for PvP minigames, understanding IP forwarding will save you hours of confusion later.
This guide stays grounded in the realities of hosting: routers that don’t behave, ISP restrictions, subdomains that won’t resolve, and the difference between seeing a random proxy address in your server logs versus the real player’s IP. I’ll explain how IP forwarding works, where it’s used, and how to configure it sensibly for a multiplayer setup.
What IP forwarding means in Minecraft
IP forwarding has two related meanings depending on context:
- At the network edge, IP forwarding means routing packets from one interface to another, often across a NAT boundary. For home hosting, that usually means your router forwarding incoming traffic on a public IP to the private LAN address where your Java server runs. Inside a Minecraft network, IP forwarding refers to a proxy passing a player’s real IP address and profile information to the backend servers, rather than hiding it behind the proxy’s IP. This is crucial for bans, region restrictions, anti-cheat, and analytics that depend on the client’s real address.
That second meaning is what most server owners mean when they talk about “enable ip_forward” or “proxy mode.” If you run BungeeCord, Velocity, or Waterfall in front of Paper/Spigot servers, you want your backend servers to see the real client IP, not the proxy’s.
Without IP forwarding, backend servers log and act on the proxy’s IP for every player. That breaks IP-based rate limits and turns moderation into guesswork. With IP forwarding correctly set up, your SMP, PvP arena, or minigame instances can apply per-user rules accurately and safely across the entire network.
Why you might need it
Consider a small group SMP that starts on a single Paper server. You later add a proxy to funnel players to a creative world and a PvP arena. Suddenly, your ban plugin targets the proxy IP rather than the player who misbehaved. Your anti-bot filter gets confused because every connection appears to come from 10.0.0.2, the proxy’s local address. That’s the blind spot IP forwarding fixes.
A second example: you’re hosting on a home connection, and your friends can’t connect to your server’s private 192.168.x.x address from outside. Router port forwarding gets their traffic to your box, but if you later add a proxy, you still need application-level forwarding so that your backend world sees each player’s real address for rate limiting and security.
When configured well, IP forwarding makes your network more transparent and maintainable. When misconfigured, it opens security gaps big enough to drive a botnet through. The point is not just to turn on a setting; it’s to secure the path end to end so only your proxy can talk to the backend servers.
Core pieces involved
Before we dig into steps, it helps to identify the moving parts and their responsibilities.
- The router or cloud firewall: Handles inbound rules, NAT, and port mapping. For home hosting, this is where you forward 25565 to your server. In the cloud, you open the correct ports in the provider’s security groups or firewall rules. DNS: Translates a friendly name, like play.yourdomain.com, to your public IP. Many admins create subdomains for different modes or regions. The proxy layer: BungeeCord, Waterfall, or Velocity. This is the entry point players connect to. It routes them to backend servers based on commands, permissions, or lobby selectors. Backend servers: Paper/Spigot servers that host worlds such as survival SMP, creative, or a PvP minigame hub. They should be in offline mode when behind a proxy, with a secure forwarding mechanism that verifies the proxy’s identity. Forwarding protocol: BungeeCord forwarding or Velocity’s modern forwarding with cryptographic signatures. The latter is more secure and easier to reason about.
With those pieces in mind, the setup becomes a matter of wiring them together in a way that preserves the client’s identity, limits who can talk to the backend, and keeps your game online through restarts and outages.
Choosing a proxy and forwarding mode
Velocity has become the proxy of choice for many Java server owners. It’s efficient, actively maintained, and offers a secure forwarding protocol that doesn’t rely on IP-based trust alone. Waterfall remains popular and compatible with a lot of older BungeeCord-oriented plugins. Both support IP forwarding, but they do it differently:
- BungeeCord/Waterfall forwarding: The proxy injects the real IP and profile data into the handshake. Backend servers need to trust that only the proxy can connect. Usually you whitelist the proxy’s private IP at the network layer and use a shared secret where supported. It’s workable, but if an attacker can reach your backend server port, they can spoof the handshake without extra safeguards. Velocity modern forwarding: The proxy signs forwarding data using a secret key. The backend server verifies the signature. Even if someone reaches your backend port, they cannot spoof the identity without the key. This is the safer default for new setups.
If you’re starting from scratch, pick Velocity with modern forwarding. If you already used Waterfall and BungeeCord for your multiplayer network and your plugins depend on it, you can stick with it, but tighten firewall rules so only the proxy IP can reach the backend ports.
Where port forwarding fits
Port forwarding and IP forwarding often get mixed up because the terms sound similar. They solve different layers of the puzzle.
Port forwarding on your router or cloud firewall gets traffic to your proxy or standalone server. If players connect directly to one Paper server without a proxy, that’s all you need at the network level: forward TCP 25565 to your PC’s LAN IP or open it on your VPS. If you run a proxy and several backends, you rarely expose backend ports to the public internet. Instead, you expose only the proxy’s port and keep the backend ports private, reachable only from the proxy over a local interface or a private network.
When you run everything on one machine, you don’t need router-level forwarding between the proxy and backends. They talk over localhost. When you spread across multiple nodes, you can build a private network using a provider’s VPC or tools like Tailscale or WireGuard, then allow only that private network to reach backend ports.
Configuring Velocity with modern forwarding
The following is a minimal, sane setup that works for most small-to-medium networks. It trades a tiny bit of convenience for security, which matters once your server is public on the internet.
- In velocity.toml, enable modern forwarding. Velocity will generate a forwarding-secret key if one does not exist. Keep it private. On each Paper backend, set online-mode to false and enforce-secure-profile to true where applicable. Install the Velocity plugin or use recent Paper builds that support built-in Velocity forwarding. In the server config or paper-global.yml, enable Velocity’s modern forwarding and paste the same forwarding-secret. Ensure only the proxy can reach the backend server ports. If all instances are on one host, bind backends to 127.0.0.1. If you use multiple hosts, allow only the proxy’s private IP in the firewall or security group. Do not expose backend ports to the open internet.
When you start the network, check the backend console to confirm it recognizes Velocity forwarding. Most backends log a message that secure forwarding is active. If you see join attempts failing with “modern forwarding is required,” it usually means the key is missing or mismatched between the proxy and that backend.
Configuring Waterfall or BungeeCord forwarding
For existing networks on Waterfall, the steps are familiar but require attention to access control:
- In config.yml, set ip forward to true and onlinemode to true on the proxy. On each backend server, set bungeecord to true in spigot.yml or the equivalent, and set online-mode to false in server.properties. Some admins also set enforce-whitelist to true and rely on the proxy to manage access. Restrict backend ports so only the proxy’s IP can connect. If that’s not possible, use a plugin or firewall to drop handshake attempts that don’t include the expected proxy headers. This reduces the risk of impersonation.
Waterfall networks run well at scale, but the forwarding plane trusts the network path more than Velocity’s cryptographic model. That’s why firewall discipline matters so much.
Dealing with DNS, subdomains, and copy-paste errors
A surprising number of connection issues come down to DNS. You can host online without a fancy domain, but a clean address helps people remember and share your server. If you buy a domain, create an A record pointing play.yourdomain.com to your proxy’s public ip. If your provider owns the domain and offers SRV records, you can point minecraft._tcp to a nonstandard port. SRV works fine for the Java edition, but it’s not as universally supported on every client or launcher, so an A record on 25565 remains the least surprising choice.
Keep subdomains straight as your network grows. If you add smp.yourdomain.com for the survival world, make sure it points to the proxy unless you intentionally bypass it. Routing around the proxy breaks forwarding, which breaks permissions and security. The only reason to target a backend directly is for admin maintenance, and even then, use a private path not known to the public.
Avoid copy-and-paste misfires when moving configs between staging and production. I keep environment-specific secrets in separate files and never commit them to a public repository. Forwarding secrets are small enough that you can regenerate them if exposed, but changing them requires updating every backend. Plan a short maintenance window to rotate keys.
Home hosting realities: your ISP, NAT, and latency
You can absolutely host your own Java server from home for a small group. Plenty of SMPs start there. The blockers are usually outside the game:
- Double NAT: Some ISPs place your router behind their carrier-grade NAT, so you don’t get a true public IP. Port forwarding won’t work in that case. Workarounds include asking your ISP for a public IP, using a VPN with port forwarding, or moving the proxy to a VPS while keeping backends at home through a site-to-site tunnel. Dynamic IP: Residential IPs change. Use a dynamic DNS service to keep a hostname current, or again, put a small proxy on a VPS with a static address and have it forward traffic to your home. Upload bandwidth: SMP gameplay is forgiving, but PvP or heavy redstone contraptions amplify latency. If your upstream is under 10 Mbps, expect strain when more than a handful of players join. In that case, pushing your proxy online to a datacenter and keeping your home machine as a private backend can help local players connect smoothly while the wider internet benefits from a better ingress point.
In all these setups, IP forwarding across the proxy remains the same concept. Only the topology changes.
Bedrock vs Java and where forwarding applies
This guide focuses on Java servers because that’s where BungeeCord and Velocity live. Bedrock has its own ecosystem with GeyserMC bridging Bedrock clients to Java servers and Floodgate managing authentication. If you use Geyser alongside Velocity, modern forwarding still applies between the Java proxy and the Java backends. Bedrock clients connect via UDP on a different port, and Geyser translates their session to the Java side. The rules about limiting access to backend ports and preserving the client identity still matter, but the moving parts differ.
If your community is mixed, consider a single proxy hostname that serves Java on TCP 25565 and Bedrock on UDP 19132, with Geyser behind a reverse proxy like Velocity or integrated into the same host. The sharper the edges are between layers, the less time you spend debugging strange cross-edition edge cases.
Security pitfalls and how to avoid them
The biggest mistake I see is exposing backend servers to the public internet while in offline mode. That invites account spoofing and griefing because the backend trusts the proxy to authenticate players. If someone connects directly to the backend’s port, they bypass that trust. The fix is simple: keep backend ports private and unreachable, and enable either Velocity modern forwarding or strict BungeeCord forwarding behind a firewall.
A close second is forgetting to set online-mode to false on the backend when using a proxy. If both the proxy and backend try to handle authentication, you get inconsistent states, login failures, and profile errors. The proxy should be the single point of online-mode truth in a networked setup.
The third is accepting plugin defaults you haven’t audited. Some anti-bot plugins assume the server sees the real client IP. If forwarding is off, rate limits trip on the proxy’s address and either block everyone or block no one. Check your plugin docs. Most modern plugins work cleanly with Velocity or Waterfall when real IPs are forwarded.
Testing and validation beyond “it boots”
Testing forwarding is more than connecting as yourself and running around spawn. Validate the path and the security.
- Confirm IP visibility. Join from two different networks, then inspect the backend console or logs to ensure it shows two distinct addresses. If both show the proxy’s private ip, forwarding isn’t active. Simulate direct access. From a machine outside your private network, attempt to reach a backend port. It should fail to connect. If it answers, fix the firewall. Check profile and UUID consistency. On a network with online-mode at the proxy and offline-mode on backends, your UUID should be the online-mode UUID at the backend when forwarding is configured. If it changes between proxy and backend, your forwarding is off or your server is trusting the wrong authority. Restart resilience. Bounce the proxy and ensure a backend does not start accepting public connections during proxy downtime. Backends should remain inaccessible from the outside world at all times.
These checks take a few minutes and catch most configuration drift early.
Performance and scaling considerations
IP forwarding by itself doesn’t slow down your server. The proxy adds a tiny amount of overhead, but it usually pays for itself by letting you split load across multiple worlds. For an SMP with a dozen friends, a single node can run Velocity and two Paper servers without strain if you allocate memory wisely, for example 6 to 8 GB total on a 16 GB machine, leaving headroom for the OS and background tasks.
For a busier network, the proxy shines because it lets you isolate workloads: a dedicated instance for the lobby, another for SMP gameplay, a separate JVM tuned for PvP with a smaller view distance and aggressive entity settings. Forwarding ensures every server still sees the real client ip, so your moderation and rate limits carry across worlds.
If you’re chasing every millisecond of latency in competitive PvP, keep the proxy and PvP backend as close together as possible, ideally on the same host or in the same availability zone. Each cross-zone hop adds a few milliseconds. Players feel that during strafes and bow duels even if they can’t name it.
When “free” hurts more than it helps
There’s a temptation to stitch together a free setup: a no-cost DNS hostname, a free reverse tunnel, and a low-power machine under your desk. It can work for a friend group and casual gameplay, but it introduces a lot of brittle links that fail under load. Free reverse tunnels often rate-limit or rotate IPs without notice. Some block inbound TCP at odd hours. If you want your network to be reliably online, budget a few dollars per month for a small VPS to handle ingress. Use it as the stable proxy, then forward over gtop100.com a private tunnel to your home or secondary servers if you want.
Free isn’t bad by itself. It’s unpredictable. Multiplayer communities, especially one with a public ip and open registration, thrive on predictability. Even a tiny paid VM solves more than half of the headaches I see in new server launches.
Practical example: small SMP with a Velocity proxy
Let’s make this concrete. You want one lobby, one SMP world, and one PvP world. You prefer a single host to start, with room to grow later.
- Install Java 17 or newer. Java servers and Velocity run well on this baseline today. Set up Velocity on port 25565. Configure modern forwarding. Keep the generated key in a secure place. Create two Paper servers: smp on port 25566 and pvp on port 25567. Set online-mode to false. Enable Velocity’s forwarding with the same key. Bind both servers to 127.0.0.1 so they are not accessible from outside. In velocity’s config, add two servers: smp and pvp, each pointing to localhost with the above ports. Set the lobby to whichever world you prefer, perhaps a small hub map that routes players with commands or an NPC selector. Configure plugins. Install your permissions plugin on all backends and the proxy where necessary. Ensure any anti-bot or rate limiter tools are proxy-aware so they use the real ip forwarded by Velocity. Set DNS so play.yourdomain.com points to your machine’s public address. Forward TCP 25565 on your router to the proxy if hosting at home. Test from two different networks. Check logs for correct player IPs on the smp and pvp servers.
When you outgrow one host, move the pvp server to a new machine, connect them with a private network, and update the Velocity config to point to the new private address. The forwarding key and method stay the same.
Troubleshooting common errors
“Player moved too quickly” or odd profile mismatches when joining through the proxy often point to online-mode mismatches. Verify the proxy is online-mode true, and the backends are false. If you run Geyser/Floodgate, make sure their configs align with the proxy’s authentication mode.
“Modern forwarding is required but not enabled” on a backend means the backend expects Velocity’s secure forwarding but has no key or a mismatched key. Check the forwarding-secret value on both sides.
“All players show the same IP” indicates forwarding is inactive. On Waterfall, confirm ip_forward is true and that your backend is set to bungeecord mode. On Velocity, verify modern forwarding is enabled and recognized in the backend logs.
“Randoms joined my backend directly” is a red flag. Close the backend ports to the internet, bind to localhost where possible, or apply firewall rules that only accept connections from the proxy’s private ip. If you had the backend in online-mode false during that window, audit permissions and roll back any griefing.
High ping spikes after adding a proxy usually reflect network layout, not IP forwarding. Keep the proxy close to your players or your backends, ideally both. Route through the shortest path. If you host at home and your players are across an ocean, move the proxy to a region closer to the majority so the first hop is shorter.
Final thoughts from the trenches
Every Minecraft network that lasts more than a weekend ends up caring about IP forwarding. It’s a quiet backbone feature that keeps your server logs honest, your anti-cheat effective, and your moderation fair. The steps are not complicated once you separate layers:
- Port forwarding or firewall rules at the network edge so players can reach your entry point. A proxy that terminates client sessions and routes them where they need to go. Secure IP forwarding so backends see the real client identity. Private backend ports and strict access limits so only your proxy can talk to them.
Do this well and everything built on top—SMP economies, PvP ladders, event nights, cross-server chats—feels solid. You can add nodes, move worlds, or experiment with new plugins without breaking the trust model. And when someone asks for your ip to join, you can give them a clean address, confident that your gameplay experience, your network, and your players are protected by a setup that scales with your ambitions.