Port Forwarding for Game Servers: Complete Guide

You installed the server software, watched the console spit out its startup lines, and joined from the same PC using localhost. Everything worked. Then you sent the address to a friend and they got a connection timeout. This is the single most common wall people hit when hosting from home, and it is not a bug in the game. Your server is running fine. It is just sitting behind a wall that your router built on purpose, and nobody told you the wall was there.

This guide explains what that wall is, how to make a hole in it safely, how to check the hole is actually open, and — importantly — how to recognise the situations where no amount of configuration will help you.

Why nothing can reach you by default

Your home network has one public IP address. Your router owns it. Every device behind that router — your PC, your phone, the smart bulb in the hallway — has a private address that only means something inside your house. Those private addresses look like 192.168.1.47 or 10.0.0.12 or 172.16.x.x. They are not routable on the public internet. Nobody outside can dial them.

When you open a web page, your PC sends a packet out through the router. The router rewrites the source address to its own public IP, notes in a table that "traffic coming back on this port belongs to the machine at 192.168.1.47", and forwards it. The reply comes back, the router checks its table, and hands the packet to the right machine. That is NAT — Network Address Translation. It is doing bookkeeping so that many devices can share one address.

Now reverse the direction. A stranger sends a packet to your public IP on port 25565. The router looks at it and asks: which of the fourteen devices in this house is this for? There is no entry in the table, because nobody inside started this conversation. So the router drops it. Silently. Your friend sees a timeout.

Port forwarding is you writing an entry into that table manually and permanently. You are telling the router: anything arriving on port 25565, send it to 192.168.1.47, always, whether or not that machine asked for it.

That is the whole concept. The rest is detail — but the detail is where people lose entire evenings.

The game port and the query port are not the same thing

This distinction causes more confusion than anything else in home hosting, and it produces two symptoms that look completely unrelated.

The game port carries actual gameplay. Player movement, chat, entity updates, the stuff that makes the game a game. If this port is closed, nobody can connect at all.

The query port exists so that something other than a player can ask the server a question: are you up, what map are you on, how many people are connected, what is your name. Server browsers use it. So do monitoring tools, Discord status bots, and every public server list — including JoinGG's listings. It is a small, separate conversation on a separate port, and it is often UDP even when the game port is TCP.

Now the two failure modes.

Joinable but invisible. You forwarded the game port, your friends connect happily, and yet your server never appears on any list, or appears permanently offline. The query port is closed. The list's checker knocks and gets nothing back, so it concludes you are down. Players who already know your address are fine. Players discovering you are not, and discovery is the whole point of listing. This trips up a lot of FiveM owners in particular, where the query behaviour has changed across artifact versions and a server can be perfectly healthy while reporting nothing — there is a fuller write-up of that specific trap in the FiveM artifact and query guide.

Visible but unjoinable. Rarer, and more annoying. Your listing shows a green tick and a player count, but connections fail. The query port is open and the game port is not, or the game port is forwarded to the wrong internal machine, or it is forwarded on the wrong protocol.

Before you touch your router, find out both port numbers for your specific game. Source-engine titles like Counter-Strike, Team Fortress 2 and Garry's Mod conventionally use one port for game traffic and a nearby one for queries, and they are usually configurable in the server's launch parameters. Minecraft's Java edition uses one port for both play and its status ping. Rust, 7 Days to Die and FiveM all have their own arrangements. Read your server software's documentation rather than assuming.

Find your local IP

Open a command prompt on the machine running the server and run ipconfig on Windows or ip addr on Linux. You want the IPv4 address of the adapter you are actually using — if the machine has both Wi-Fi and Ethernet, and one is unplugged, you will see two entries and only one matters.

Note it down. Note the default gateway too; that is your router's address on the inside, and it is how you will reach its admin page.

Make that address stop moving

Here is the trap that catches people a week later, when everything was working and now it is not.

Your router hands out addresses by DHCP, on a lease. Leases expire. Reboot your PC, or the router, or lose power for an afternoon, and your server machine can come back with a different local address. Your forwarding rule still points at the old one. Now the rule sends traffic to your partner's laptop, which is not running a game server, and the port is dead.

Two fixes.

A DHCP reservation is the better option. You tell the router: this specific MAC address always gets this specific IP. The machine still uses DHCP and still gets everything else automatically. Nothing on the PC changes. If you move the server to another machine later, you change one line on the router.

A static IP set on the machine itself also works. Configure the adapter with a fixed address, subnet mask, gateway and DNS. Pick an address outside the router's DHCP pool, or the router may hand the same address to something else and you get an address conflict that manifests as random, maddening dropouts.

Reservation is cleaner. Static works. Doing neither means your server breaks on a schedule you cannot predict.

TCP, UDP, and forwarding the right one

TCP is a conversation with acknowledgements and retransmissions. UDP is fire-and-forget. Most real-time game traffic is UDP because a late packet is worse than a lost one — you do not want the game pausing to redeliver a position update from two seconds ago.

Some games use TCP. Minecraft Java's protocol is TCP. Source-engine games are UDP for gameplay. Some servers use both: TCP for an RCON admin port or a web panel, UDP for play.

Many router interfaces offer a "TCP/UDP" or "Both" option. Use it if you are unsure and the port is dedicated to your server. Forwarding a protocol the server does not use costs nothing — the packets arrive and the server ignores them. Forwarding only TCP when the game speaks UDP costs you the whole evening.

When you create the rule you will be asked for an external port, an internal port, and an internal IP. Keep external and internal identical unless you have a reason not to. It is legal to accept traffic on one external port and deliver it to a different internal one — useful when two machines both want port 27015 — but it makes every future debugging session harder, and players must then use the external number.

I said I would not give brand-specific click paths, and I mean it. Router firmware changes between models and between updates, so any menu path I wrote today would be wrong for someone next month. Search your router's model number plus "port forwarding" and you will find current screenshots. The concepts above are what you are looking for once you are in there.

Windows Firewall will still block you

This is the second wall, and it is inside your PC.

Even with a perfect forwarding rule, Windows Firewall may drop the incoming packet at the network adapter. Some server software creates its own firewall rule during installation and some does not. Java-based servers are a frequent offender, because the rule gets attached to a specific java.exe — update your Java runtime, the path changes, and the old rule now covers a binary that no longer exists.

Create an inbound rule. Outbound is almost never the problem; your server can already talk out. Specify the port and the protocol, and prefer a port-based rule over a program-based one, since the port survives software updates and reinstalls. Apply it to the Private profile at minimum. If your network is classified as Public — which happens more often than you would expect, particularly after a network adapter change — a rule scoped only to Private will not fire, and you will swear the rule exists while packets keep vanishing.

Antivirus suites frequently ship their own firewall that sits above the Windows one. If you have one, it needs its own rule. Turning the whole thing off to test is a valid diagnostic step and a terrible permanent state.

Actually testing whether the port is open

Do not test from inside your own network. This is the most common false result in the entire process.

When you connect to your own public IP from a machine on your LAN, you are relying on NAT hairpinning — the router recognising that the traffic is destined for itself and looping it back inside. Some routers do this. Many do not. A failure from inside proves nothing, and a success from inside does not prove outside access works either.

Test from genuinely outside. Options that work:

Use an online port checker. Give it your public IP and the port. It attempts a connection from its own servers, which is exactly the perspective you care about. Note that most of these check TCP only, so a UDP-only game port may report closed even when it is fine — a real limitation, not a bug on your end.

Tether your phone to mobile data, turn Wi-Fi off, and try to connect. This is the closest thing to a genuine test for a UDP game.

Ask someone else to try. Slow, but definitive.

Watch the server console while any of this happens. A connection attempt that reaches the server leaves a trace, even a rejected one. Silence in the console during an external attempt means the packet never arrived, which points at the router or the firewall. An error in the console means the packet arrived and something else went wrong — a whitelist, a version mismatch, a full server. That distinction narrows your search enormously.

If people can connect but immediately drop, or the server appears empty on lists despite active players, the problem has moved past port forwarding into configuration and visibility territory; the common reasons nobody joins a server covers that ground.

CGNAT: when you cannot forward at all

Some connections genuinely cannot be port-forwarded, and no configuration fixes it.

Carrier-Grade NAT means your ISP has run out of public IPv4 addresses and put you behind a second layer of NAT at their end. Your router does not have a public IP. It has a private one issued by the ISP, shared with other customers. You can create forwarding rules all day; they apply to a router that the public internet cannot reach either.

How to spot it: look at the WAN IP shown in your router's status page and compare it to what a "what is my IP" site reports. If they differ, you are behind another layer of NAT. Also suspicious is a WAN address starting 100.64. through 100.127. — that range is reserved specifically for carrier NAT. Mobile broadband and 5G home internet are behind CGNAT almost universally. Fixed-line connections vary by provider and by region.

Your options:

Ask your ISP for a public IPv4 address. Some provide one on request, some charge a small amount, some offer it only on business plans, and some flatly refuse. It costs nothing to ask.

Use a tunnel. A relay service or a small cloud instance with a public address can accept connections and forward them to your home machine over an outbound connection you initiate. This works, sidesteps CGNAT entirely, and adds latency proportional to how far your traffic detours. For a small friends-only server it is often acceptable. For anything competitive it is not.

Rent hosting. At this point you are paying for a machine that already has a reachable address, which is most of what you were fighting for.

IPv6 changes the shape of the problem

IPv6 gives every device its own globally routable address. There is no NAT and therefore nothing to forward. What there is instead is a firewall on your router that blocks unsolicited inbound traffic by default — sensible, since without it every device in your house would be directly exposed. You open a hole in that firewall rather than creating a translation rule.

The practical catch is reach. A player whose connection is IPv4-only cannot connect to an IPv6-only address. Plenty of connections are still IPv4-only, and the game itself may not support IPv6 at all. Treat IPv6 as an addition, not a replacement: if your ISP gives you both, run both. If you have IPv6 only because you are on CGNAT for IPv4, you have solved the problem for some of your players and none of the rest.

What you are actually exposing

An open port is a door with your server software standing behind it. The security of that door is the security of that software.

Every server binary has had vulnerabilities. Popular ones get scanned constantly by automated tools that sweep whole address ranges looking for known-vulnerable versions. This is not paranoia, it is background noise on the internet, and it is why running an outdated build with an open port is a genuine risk rather than a theoretical one.

Some sensible habits:

Keep the server software patched, especially anything that accepts uploads or executes user-supplied content. Modded servers are a larger surface than vanilla ones by definition, and plugin code runs with the server's privileges.

Run the server under a limited account, not an administrator one. If something is compromised, the damage is bounded by what that account can reach.

Never forward the RCON or remote admin port to the public internet. It is a remote code execution channel by design. Administer over a VPN or from the local network.

Forward only the ports you need. Each one is a separate door.

Understand that you are publishing your home IP address. Anyone who joins can see it, and that opens you to being a target for denial-of-service attacks — the classic revenge move after a ban. A home connection has no scrubbing capability and your ISP will not filter for you. When a home server gets attacked, the whole household loses internet, not just the game. Handling attacks against a small server goes into what is and is not possible about that.

Also consider what else is on your network. Your server machine sits on the same LAN as everything else you own.

When to stop and rent something

Home hosting is a genuinely good way to run a private server for friends, learn how the software behaves, and test configurations without paying for the privilege. Many people never need more, and a small Minecraft or Left 4 Dead 2 server for a handful of regulars runs happily on a spare desktop.

The signs you have outgrown it are fairly clear.

Your upload bandwidth is saturated. Domestic connections are asymmetric — download is generous, upload is not — and upload is what a server needs. Every connected player consumes it continuously. The symptom is that everyone lags at once, and it gets worse with each additional player.

Downtime matters to somebody. If you reboot for a Windows update and people notice, you have obligations that a desktop under a desk cannot meet.

You are on CGNAT and the workarounds have become the hobby.

You do not want your home IP public any more.

The machine has other jobs. A server sharing a CPU with your own gaming session will produce tick lag every time you launch something demanding.

At that point, renting is buying a reachable address, an uncontended upload pipe, and someone else's power supply. The cost breakdown for 2026 sets out what those things actually run to, and the free routes for a Minecraft server covers the no-cost end of it if budget is the reason you are hosting at home in the first place.

Common questions

Do I need a static public IP from my ISP? Not usually. Most residential IPs change rarely — often only after a long outage or a router replacement. A dynamic DNS hostname updates automatically when your address changes and gives players a name to connect to instead of digits. Useful, free from several providers, and it means you are not re-messaging everyone after every change.

Why can I join with localhost but my friends cannot? Because localhost never leaves your machine. It bypasses the router, the firewall's inbound rules and NAT entirely. It only proves the server process is running and listening, which is worth knowing but is the very first step, not the last.

My port checker says closed but my friend can connect. Most online checkers test TCP. If your game uses UDP, the checker cannot see it. Trust the human.

Can I run two servers for the same game on one connection? Yes, on different ports. Configure each server to listen on its own port and create a separate forwarding rule for each. Remember the query ports need separate entries too, and players will need the port number in the address for anything that is not the game's default.

Does port forwarding slow my internet down? No. The rule is a lookup in a table the router already maintains. What affects your connection is the traffic itself — a busy server eating your upload bandwidth will make everything else in the house feel worse, and that has nothing to do with the forwarding rule.

Is UPnP a shortcut? It lets software request its own forwarding rules automatically, so it can save you the manual step. It also lets any program on your network open ports without asking you, including things you did not install deliberately. Many people disable it and forward manually for exactly that reason. If you use it, verify the rule it created rather than assuming.

My server works but it is not showing on server lists. Query port, nine times out of ten. Check that it is forwarded, on the right protocol, and that the server is configured to answer queries at all. The other common cause is a listing that has not been verified or refreshed — what makes a listing trustworthy explains what checkers look for and why some servers get filtered out even when they are up.

Working through it in order

Confirm the server runs locally. Note the game port and the query port. Find the machine's local IP and pin it with a reservation. Forward both ports on the correct protocol. Add inbound Windows Firewall rules by port. Test from outside your network, watching the console as you do. If nothing arrives at all, check for CGNAT before you rebuild the rules a fourth time.

Most failures are one of four things: the wrong protocol, a local IP that moved, a firewall rule that was never created, or an ISP that was never going to let this work. Go through them in that order and you will find yours.