If you run a Minecraft server long enough, the question of “what IP should we use?” stops being a technical footnote and becomes branding, reliability, and player experience all rolled into one. I’ve managed everything from tiny SMP worlds with a dozen friends to public PvP hubs that saw thousands of unique joins per week. The IP setup was never just a checkbox. It influenced how easily players could connect, how resilient the network was under attack, and how painful migrations felt when a host changed providers or regions.
This guide walks through the choices you’ll face, from raw IPs to domains and proxies, and the trade-offs that come with each one. Whether your world is Java only or you’re experimenting with crossplay, the right addressing strategy can save you go here headaches and help your network grow.
What “IP” Means to Your Players
To players, the server address is a small text box. They copy and paste something from Discord or a website, and they either land in your hub or get stuck on “Connecting to server.” Under the hood, that text can be a raw IPv4 address like 198.51.100.37:25565, a hostname like play.example.com:25565, or a polished domain with a hidden port such as play.example.com that resolves via DNS records to the correct destination.
Each choice hides different complexity. A raw IP is simple but brittle. A domain gives you flexibility to move hosts without asking everyone to update their bookmarks. Add a proxy like Velocity or BungeeCord to handle a full network, and your “IP” becomes a front door that fans out to multiple game modes: SMP, PvP, minigames, creative. The more professional your multiplayer ambitions, the more important that front door becomes.
The Raw IP: Quick, Free, and Fragile
Many new server owners start with the IP from their host. On shared hosting, you’ll be given an IP and port; on a virtual private server or dedicated machine, you usually control port 25565 yourself. This approach is fine for a short-lived event or a private SMP with a handful of friends. It’s easy to share in chat, and you don’t have to touch domain registrars or DNS.
But the perks stop there. If you change hosting providers, that IP changes. Every player who saved the old address will fail to connect, and a surprising number never return after a broken evening. The raw address is also forgettable. People remember words better than numbers and ports. Even a good server struggles to grow if the address doesn’t stick.
Then there’s DDoS exposure. When your players use the raw IP, anyone scanning your network can see the real endpoint. Many budget hosts include basic DDoS filtering, but it’s rarely as good as what you can arrange with DNS-based protection or a proxy layer. If you plan to run an open multiplayer network, especially a PvP or anarchy server where emotions run hot, hiding the real IP behind a robust front door can save your weekend.
Why a Domain Changes the Game
Owning a domain is not just vanity. It’s an abstraction layer between your server and your community. You can move the backend around — new region, new host, new hardware — and your players continue to connect using the same name. Updating the DNS record turns the wheel silently in the background.
A clean address like play.yourdomain.com looks trustworthy and professional. It’s easier to say on a stream, easier to print on a banner, and less error-prone to copy. This helps with organic growth. If your server is public and online for months, the conversion impact is real.
Price-wise, domains are cheap. Most .com or .net names run roughly 10 to 15 USD per year. If you want something thematic for a game network, newer TLDs (.gg, .games, .network) cost more, sometimes 30 to 60 USD annually, but you are paying for branding. For a small SMP that may feel extravagant. For a growing multiplayer community, it’s probably the lowest-cost improvement you can make.
Picking the Right Subdomain Strategy
A structure like play.yourdomain.com for the connection entry point has become the default. Keep it short and memorable. If you run multiple regions or specialized servers, you can create additional records like eu.yourdomain.com or smp.yourdomain.com. Some networks still prefer mc.yourdomain.com because it reads clearly in chat. All of these are fine as long as you commit to one primary address for your main entry and stick with it.
Where teams trip up is inventing five different addresses and asking the community to guess which one is “the real” one. The more options you advertise, the more support messages you will field when a record goes stale or a new proxy deploy breaks only one of them. Keep a single, canonical address for the network entry. If you add others for convenience or testing, consider keeping them unadvertised.
DNS Records: A, AAAA, and SRV Explained
For Minecraft Java Edition, the port defaults to 25565. If your server listens on that port, a simple A record (for IPv4) or AAAA record (for IPv6) is all you need. For example, play.yourdomain.com → 198.51.100.37. Players can enter just play.yourdomain.com. No port exposed, and you can move the IP later without changing the visible address.
If your host forces a nonstandard port, an SRV record lets you hide it. An SRV entry can map play.yourdomain.com to mc.yourdomain.com:25586 behind the scenes so players still type only play.yourdomain.com. SRV works well for Java Edition, though not every DNS provider makes the setup intuitive. You create a record for minecraft.tcp.play with a priority and weight (usually 0, 0), a port, and a target hostname that has an A or AAAA record. Once set, the Minecraft client honors the SRV and connects correctly.
A few points from experience:
- If you can avoid SRV by running on 25565, do so. It’s one less moving part, and some older tooling fails to read SRV correctly. Keep a minimal chain. SRV should point to a hostname with a direct A or AAAA record, not another CNAME that loops around. IPv6 (AAAA) is fine to publish. Many hosts still funnel traffic mostly through IPv4, but dual-stack support has matured. Make sure your firewall rules match both stacks.
That’s one of our two allowed lists; we’ll keep the rest in prose.
Proxies and Networks: Velocity or BungeeCord
Once you operate more than a single world, a proxy becomes the heart of the network. You run a lightweight proxy process that players connect to. Behind it, you run multiple Spigot or Paper servers — maybe one for survival SMP, one for PvP arenas, another for parkour or skyblock. The proxy handles transfers and keeps the visible IP stable.
Velocity has become my default for new builds. It’s performant, easy to configure, and plays nicely with modern Paper forks. BungeeCord remains a proven option with a massive plugin ecosystem. You can’t drop plugins interchangeably between them, so pick one and stick to it. Either way, your public DNS points to the proxy’s machine, not the individual game servers.
This architecture doors off DDoS blasts and gives you a consistent entry point. Players join once, then route internally to the appropriate backend. You can version-split or region-split. You can even add maintenance capacity, sending players to a fallback lobby if the SMP backend restarts.
When you introduce Bedrock Edition support, the addressing layer gets more nuanced. Bedrock uses different discovery and port behavior. Many crossplay stacks rely on Geyser and Floodgate alongside a Java proxy. Bedrock clients usually connect on port 19132. In those cases, you may advertise two addresses: one for Java, one for Bedrock, or a single domain with separate DNS records and ports. The key is clarity. Don’t make your Bedrock players hunt for arcane copy instructions or json snippets.
DDoS Mitigation: Realistic Options for Community Servers
Attackers target public game servers because the impact per dollar is high. Even a brief volumetric flood can knock over a budget VPS and scramble an evening of events. A smart IP strategy reduces the attack surface. Start by keeping the origin IP hidden. If your game process sits behind a proxy or a partner that provides network-layer filtering, do not leak the origin anywhere public.
You have a few paths:
- Use a host that specializes in game DDoS protection. Many reputable providers proxy traffic before it reaches your machine and include anycast or scrubbing by default. Check that their mitigation specifically supports Minecraft protocols, not just generic UDP/TCP floods. Place a dedicated proxy in front, with a provider like TCPShield or similar. This keeps the public DNS pointed at the protection layer. The origin’s IP stays private, and the proxy whitelists which sources are allowed to forward to your backend. Roll your own with a hardened edge VPS running only the proxy, then route internally over WireGuard or GRE tunnels to the backend instances. This takes more networking skill but gives you control at cost.
If your budget is tight, the first option is the most pragmatic. The third gives the most ownership but will eat weekends. Whatever you choose, lock down the backend with firewall rules so that only the proxy’s IP can reach the game ports. Otherwise, someone will bypass your shield with the raw origin IP once it leaks through a ping scraper.
Note for teams chasing “free” options: free DNS by the big registrars is fine for record management, but free DDoS protection that properly understands the quirks of the Minecraft handshake is rarer than marketing suggests. Test devious edge cases — malformed handshakes, large ping requests, connection rate spikes — before relying on it.
Port Choices and Why 25565 Still Wins
For Java, the client expects 25565. Using the standard keeps life simple. If your shared host assigns a random high port, hide it with SRV. When you control the machine, stick with 25565 unless you have a specific reason not to. Firewalls and managed providers often have pre-built rules for that port, and it reduces confusion while players share the address.
For Bedrock, 19132 is the default. Keep it unless your provider forces a change. Bedrock players are more accustomed to entering ports because the client UI exposes separate fields for address and port. Still, aim for defaults if you can.
One painful issue I’ve seen: developers open extra high-numbered ports for RCON or tooling, forget to restrict them, and a scan shows the origin. If you publish anything beyond the proxy’s entry ports, make sure the firewall only permits your admin IPs or a secure tunnel.
Subdomains for Growth Without Fragmentation
As your network matures, you may be tempted to advertise smp.yourdomain.com, pvp.yourdomain.com, and minigames.yourdomain.com as separate entry points. Technically this works, made even easier with SRV, but it splits your brand. Players invite friends with whatever they last copied, and your community fragments into micro-groups that never see the lobby, the shop, or global announcements.
I keep a single front door — play.yourdomain.com — and route internally. If a unique region is necessary for latency (say, NA and EU), separate addresses make sense, but I still lead marketing with the one most of the player base should use. On the back end, a modern proxy or L7 router can bounce a player to the closest region based on geo-IP, as long as you avoid sending them on a ping-pong across the Atlantic every time they rejoin. Test behavior with real players from different regions before publicizing anything.
SSL, SRV, and Web Presence
Minecraft Java connections aren’t HTTPS, so SSL certificates don’t apply to the game protocol itself. They do matter for your website, store, and map if you run a Dynmap or similar tools. The single best way to keep branding consistent is to attach everything to your domain. The store might live at shop.yourdomain.com, the map at map.yourdomain.com, and the server at play.yourdomain.com. Keep the naming clean and obvious, and use the same design language across web and social so that new players trust the address when they copy it.
Some operators use Cloudflare for DNS because it’s fast, free at the base tier, and has a good dashboard. That’s fine, but don’t rely on orange-cloud proxy mode for raw TCP Minecraft unless you add a partner that integrates specifically with their spectrum-like services. The orange-cloud icon is for HTTP and websockets; for Minecraft’s traffic, it won’t proxy unless you pay for the correct plan and feature set. You can still use Cloudflare for DNS-only and point records to a specialized mitigation partner.
Metadata and Discovery: MOTD, Icons, and Status
A polished IP strategy includes what players see when they ping your address in the multiplayer menu. The Message of the Day (MOTD) and server icon load before a player joins. Keep the address, MOTD, and icon aligned: if your network is a friendly SMP with seasonal events, say that. If it’s a competitive PvP arena, make that clear and keep the MOTD light on gimmicks that feel like clickbait. A simple, accurate line beats color-coded noise.
I’ve watched servers improve player retention by 10 to 20 percent after cleaning up the MOTD and server list name to match Discord and website branding. It’s not magic, just consistency. When a friend says “use play.yourdomain.com,” the icon and tagline should reassure newcomers they’ve landed in the right place.
Java-Only, Bedrock-Only, or Crossplay
Your IP decisions depend on what platforms you support:
- Java-only: simplest. Use play.yourdomain.com on 25565. Hide any nonstandard port with SRV if needed. A proxy like Velocity is optional for a single world but recommended once you grow. Bedrock-only: advertise bedrock.yourdomain.com and port 19132. Bedrock players expect to enter both fields. Keep instructions on your site concise and visual. Crossplay: you’ll likely publish two sets of instructions. Java to play.yourdomain.com (25565). Bedrock to bedrock.yourdomain.com (19132). Many networks also route both through the same domain with different ports, but separating the names helps onboarding. If you use Geyser, place it strategically: either at the edge or internally behind the proxy, depending on your plugin stack and where authentication takes place.
That’s the second and final allowed list. From here, we’ll keep the rest as paragraphs.
Performance and Latency: Where to Place the Entry Point
Players feel latency during combat or quick building. If your network focuses on PvP, keep the entry point close to the largest cluster of players. With anycast or global TCP mitigation, traffic can enter near the player and then move across your private backbone, but not every provider offers that at indie budgets. A common pattern is to run the proxy where most players reside and host ancillary services in adjacent regions. If you spin up a new EU proxy for your network, resist the urge to chase every geography at once. Support for two regions well is better than four regions inconsistently.
Metrics will guide you. Track median and 95th percentile ping for active players. When you see persistent high-latency sessions from a second continent, consider an additional entry point. If your player base is mostly local and your budget modest, a single region is fine. Don’t let fear of missing global traffic push you into premature complexity.
Backups, Migrations, and the Day You Change Hosts
The whole reason to use a domain is to survive the day you need to move. Maybe the host’s CPU nodes saturate at peak, or your SMP world creeps past 50 GB and needs NVMe. When you migrate, a smart plan keeps the address stable and the downtime minimal.
In practice, you schedule a quiet window, spin up the new machine in parallel, and test it behind a temporary DNS record not shared with the public. Move worlds and configs, warm the caches if you use a proxy, and simulate load with staff. When confident, change the A or SRV target for play.yourdomain.com. DNS TTLs matter here. If the record has a long TTL (say, four hours), change it a day early to a low TTL like 300 seconds, wait out the old value, then cut over during the window. Afterward, raise TTL again. Most players will follow the new target within minutes. A few ISPs cache aggressively; keep the old server up for a grace period with a friendly MOTD that points people to the new instance in case their DNS hasn’t refreshed yet.
I’ve used that dance a dozen times without drama. The only painful cases were when the origin IP had leaked into public posts and players kept using it. Once your domain is in place, scrub the raw IP from every banner, page, and message you control. If it’s already out there, apply firewall rules so the game port refuses direct connections from the internet, forcing everyone through the domain and proxy.
Security Hygiene Around the Address
Your IP plan is part of your security story. Even if your network is free to join and you run a friendly SMP, the surrounding services need discipline:
- Lock down RCON and admin panels to specific source IPs via firewall. Do not leave RCON open to the world because you assume nobody will guess the password. Rotate secrets when staff change. That includes proxy tokens, backend whitelists, and panel logins. Separate build and production credentials. Staging servers should not share the production proxy address, or they will pop into public server lists by accident. Keep the domain registrar under two-factor authentication. If someone steals your domain, they steal your player base along with it.
I’ve seen more downtime caused by forgotten firewall rules than outright hacks. Write down your port diagram and review it quarterly. When you add a new plugin that exposes a web port, either put it behind an authenticating reverse proxy or disable the public port entirely.
The Human Side: How You Share the Address
Technical choices don’t matter if the address is hard to share. Your website, Discord, store, and voting pages should all use the same format, same capitalization, and the same short explanation. If your server is heavily modded or requires a specific Java version, write that next to the address and keep it updated. Players who find you through a friend will skim and copy. Visual clarity wins.
I favor a simple one-liner under the logo: play.yourdomain.com — Java Edition 1.20.x. If you support Bedrock, add its line below with the port. The more you reduce friction at the “copy” step, the faster new players land in your lobby and start their first session. If you announce events, put the address in the first paragraph where it’s easy to copy on mobile. When a streamer reads your info aloud, a short address and default port keep it crisp.
Budget Scenarios: What You Can Do Right Now
If you’re hosting from home to test plugins or practice administration, use a dynamic DNS service and a domain if you insist on public access, but be realistic. Home connections change IPs, residential ISPs filter traffic, and you expose your household IP. For a real multiplayer network, rent at least a VPS in a data center. With a few dollars per month, you get a stable address and proper bandwidth. A modest plan can run Paper for a small SMP or a proxy in front of a managed game host.
If your budget is essentially zero, you can still make smart choices: use a free DNS provider with your domain, keep the record hygiene clean, run on default ports where possible, and think ahead to how you’ll migrate when you can afford better hosting. Growing servers that start “free” often get stuck later because their player base memorized a raw IP and port. Don’t let that happen. Put a memorable domain in place early, even if the rest of the stack is basic.
A Practical Setup That Works
Here’s a compact example that has served me well running a Java multiplayer network with SMP and PvP:
Register a memorable domain. Create play.yourdomain.com as an A record pointing to a protected proxy instance on port 25565. The proxy runs Velocity with modern forwarding, and only the proxy’s IP is allowed to reach the backend Paper servers via firewall rules. The SMP and PvP servers live on separate machines or containers and register to the proxy. The MOTD is short and specific, the icon matches the site, and the website lists play.yourdomain.com in the header. A staff-only DNS record points to a staging proxy for updates and testing. When migrating providers, lower TTL a day early, test the new proxy at a secret subdomain, then flip the A record at the scheduled time.
For crossplay, add bedrock.yourdomain.com, attach Geyser at the edge or through the proxy depending on your auth model, and publish the Bedrock port clearly. Keep both addresses consistent across every social channel.
Final Judgment Calls
There isn’t a single canonical answer for every network, but some principles rarely fail:
- A custom domain beats a raw IP for memory, resilience, and credibility. Default ports reduce friction. SRV is a useful fallback, not a first choice. Hide origin IPs behind a proxy or provider that understands Minecraft traffic. One canonical entry address avoids community fragmentation. Plan for migration on the day you choose your IP format, not after you need it.
Do these, and your players will barely think about the IP at all. They’ll copy a simple address, join your world, and talk about the gameplay — not the connection details. And that’s the quiet sign your infrastructure choices are serving the network, not the other way around.