7 Days to Die Server Ports: What to Open and What Not

The default 7 Days to Die server ports are TCP 26900 and UDP 26900 through 26903. Forward that traffic to the computer running the dedicated server, allow it through that computer’s firewall, and keep remote admin ports closed. This guide walks through the home-network setup and an actual join test from outside your Wi-Fi. If you are still choosing a route, compare how to run a dedicated server at home or through a host first; this page covers the network work for the self-hosted branch. If the server uses a custom base port, use the offsets in The Fun Pimps’ current firewall guide instead of copying the defaults blindly.

Map the 7 Days to Die server ports first#

For the default ServerPort value of 26900, forward one TCP port and four UDP ports. The Fun Pimps explains the jobs in its official port table:

The short router rule is TCP 26900 plus UDP 26900–26903, all sent to the server PC’s local address. Do not replace the UDP range with just the ports that appeared open in one forum post or a single server log. A provider’s allocation or a third-party socket observation is not the rule for your own dedicated server.

If you changed ServerPort, read the official table as offsets from BasePort: the TCP query and UDP game ports move with the configured base. Confirm the value in the active server configuration and use the corresponding ports in both your firewall and router. The game also uses Steam networking beyond these server-specific inbound rules; a broad Steam client port list is not a reason to forward every Steam port to the server PC.

Keep Telnet and the web dashboard off the internet#

The game join does not need the remote administration ports. The default Telnet port is TCP 8081; the web dashboard uses TCP 8080. Treat both as management interfaces, not game traffic. Keep them closed on the router and do not add them to the game firewall rules below.

If you administer the machine from another network, use a private VPN or a deliberately secured access path and follow the server software’s current authentication guidance. The official port article lists these only when remote administration is intended. A router rule that exposes them to every internet address turns a convenient control into a public attack surface.

A hosted control panel can provide a separate admin route. Game Hosting’s dashboard includes a live 7 Days to Die server console; using a panel does not require exposing Telnet 8081 to players. The console is for server administration and does not prove that an outside player can reach the game ports.

Give the server PC a consistent local address#

A router forward points to a device on your home network, such as 192.168.1.42. If that computer gets a different address after a reboot, the rule can keep pointing to the old one even though the server is running. Create a DHCP reservation in the router for the server PC, then use that reserved address as the destination for every game rule.

On Windows, find the active network adapter’s IPv4 address in PowerShell or Command Prompt:

ipconfig

Look under the adapter that connects to your router, not a VPN or virtual adapter. On Linux, list active interfaces and their addresses with:

ip -br addr

Reserve the address in the router’s DHCP or LAN settings. Router vendors use different labels, so follow the manual for your exact model rather than assuming a menu path. If the router cannot reserve an address, set a static address outside its automatic DHCP pool and copy the correct gateway and DNS values. A duplicate address can disconnect another device, so a reservation is safer for most home networks.

Before continuing, note the address you reserved and verify the server PC still has it after reconnecting to the network. If it changed, stop and correct the reservation before adding a forwarding rule.

Allow the game ports through Windows Firewall or UFW#

The router forwards traffic to the PC; the PC’s own firewall still decides whether the server process can receive it. Create only the game rules for the protocol and ports in the table. Use one option for the operating system that runs the server.

For Windows, open an elevated PowerShell window on the server PC and add two inbound rules:

New-NetFirewallRule -DisplayName '7 Days to Die server TCP 26900' -Direction Inbound -Protocol TCP -LocalPort 26900 -Action Allow
New-NetFirewallRule -DisplayName '7 Days to Die server UDP 26900-26903' -Direction Inbound -Protocol UDP -LocalPort 26900-26903 -Action Allow

Check that Windows created both rules:

Get-NetFirewallRule -DisplayName '7 Days to Die server*' | Select-Object DisplayName, Enabled, Direction, Action

On a Linux server using UFW, allow the same traffic and inspect the numbered rules:

sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw status numbered

If UFW is inactive, these commands alone do not tell you how another firewall is configured. Check the firewall actually enabled on the machine or the cloud/VPS provider’s network rules. Likewise, do not leave temporary rules for Telnet or the web dashboard after troubleshooting. When you use a custom base port, replace the defaults with the matching official offsets.

Forward the same ports to the reserved address#

Sign in to the home router and open its port-forwarding, virtual-server or NAT rule page. Use the same local server address for each entry. Router interfaces differ, but each rule needs a protocol, external port, internal port and destination device.

1. Create the TCP rule

   Set the external and internal port to 26900, choose TCP, and set the destination to the reserved address of the server PC.

2. Create the UDP rule

   Set both ends to 26900–26903, choose UDP, and use that same PC address. If the router accepts only one port per rule, add one UDP rule for each port.

3. Save and verify the destination

   Apply the rules, then reopen the page and confirm they still target the reserved IP. Avoid a second rule that maps the same external port to another device.

For a custom ServerPort, match the active base and offsets in the official table, not a remembered range. Keep the protocol attached to each rule: TCP 26900 and UDP 26900–26903 are separate entries. Do not add TCP 8080 or 8081 just because they appear beside the game ports in a broader host setup guide.

If your router supports logging, enable it temporarily while testing and look for traffic to the reserved server address. A saved rule is not proof that packets reached the game; it only confirms that the router has a mapping to try.

Test a real join from outside your home network#

A port checker or a successful ping is not a game join. UDP services may not answer a scanner at all, and testing the public address from the same Wi-Fi depends on whether your router supports NAT loopback. Ask a friend on another connection to try, or use a second PC on a phone hotspot if its data plan allows the game download and connection.

For a PC test, have the outside player use the game’s server browser or direct-connect path with the public address and game port. Keep the client on the same game version and branch as the server. If the player reaches the server, record what changed and keep the router and firewall rules limited to the ports above. That is the confirmation that matters; a router page showing “enabled” is not.

If they cannot join, change one thing at a time:

For PC with PS5 or Xbox Series X|S, port forwarding is only one part of the setup. Check The Fun Pimps’ current dedicated-server crossplay requirements for the server and platform conditions; do not assume that a working PC join proves console eligibility. The modern console release is separate from the abandoned 2016 Xbox One and PS4 edition.

Check double NAT before adding more rules#

If the local server and host firewall look right but nobody outside can join, compare the internet-facing address shown in your router with the public address reported by a reputable IP-check service. If they do not match, your router may sit behind another router or your provider may use carrier-grade NAT (CGNAT). A forwarding rule on the inner router cannot configure the upstream device.

For two routers you control, you can usually bridge one device or forward the same game ports through both. If the upstream device belongs to your ISP, ask whether it offers a public IPv4 address or a supported inbound-forwarding option. Do not disable the ISP gateway’s firewall blindly; that can expose unrelated devices.

If your router or ISP will not accept inbound traffic, we recommend Game Hosting for 7 Days to Die as a managed alternative: the group can use a server connection without configuring your home router, and admins have the panel’s live console instead of exposing the server’s Telnet port. That solves the home-network portion only; it cannot fix a player’s mismatched game version, account restriction or platform incompatibility. For the broader trade-offs, see whether to host your own 7 Days to Die server or rent one.