Valheim dedicated server ports: Steam vs crossplay relay

Valheim dedicated server ports depend on the backend: Steam uses the configured UDP port and the next port, 2456–2457 by default, while crossplay relay needs no router forwarding. Before adding another rule, find out which route your running server uses. This guide gives you a minimal port map, separates the computer’s firewall from the router, and ends with a check from outside your network. Allow about 20 minutes once the server starts successfully and a friend is available to test. The examples follow current documentation; they are not claims that we tested your router, platform or world.

Match Valheim dedicated server ports to the running backend#

For a mixed-platform Valheim group that does not want one friend’s PC to be the host, we recommend Game Hosting. The integrated game panel keeps configuration and restarts together with three free backup slots; the game’s joining and version requirements still apply to every player.

Check the configuration that actually launched the process. The presence of the crossplay argument changes which networking instructions apply, even when every player owns the Steam edition.

Iron Gate’s dedicated-server manual distinguishes these two routes:

Before changing the backend, inspect the server launch arguments and defaults in the startup file that actually runs; a sample script or wrapper setting may not match the active configuration.

The argument selecting the relay is:

-crossplay

Without it, the manual says only Steam users can join. With it, use supported crossplay clients and the relay’s joining rules. A Steam player can join a crossplay server, so the client’s storefront alone does not tell you which backend the server uses.

Read the copied startup script, service configuration or panel setting used for the current instance. Editing an unused default script changes nothing. If you alter the backend, restart using the server’s documented shutdown and startup procedure, then inspect the new output before continuing. Record the selected world and instance name so you do not test a second process by mistake.

If you have not chosen where the process will run, start with the dedicated-server route comparison. Home hardware, a VPS and a managed service place different controls in your hands, but the backend distinction still comes first.

Map the Steam UDP pair before editing the router#

For Steam networking, write down the configured base port and add one. That pair is the target for your rules; copying a wider range from an old tutorial is unnecessary for the documented default setup.

The official manual specifies the base-and-next-port formula. The community server container maintainer explicitly documents UDP transport for the default pair and also recognizes the crossplay forwarding exception. You do not need to use Docker to understand that distinction.

The Docker deployment walkthrough applies that pair in Compose and shows how to keep the world mounted when replacing the container.

These are port calculations, not tested deployments. The corresponding custom argument fragment is:

-port 2460

Keep the rest of your working launch configuration intact. Changing only a router rule does not move the server to the new port. Update the actual launch setting and the matching rules together, then confirm which instance starts.

The default base does not make 2458 universally necessary. That number can become relevant with another configured base or a component that explicitly requires it. Check a mod’s own documentation before adding exceptions; do not turn a component-specific requirement into a vanilla rule.

When running multiple instances, allocate non-overlapping pairs and record their world names. Bases of 2456 and 2457 overlap at 2457. Also avoid treating the second port as an instruction for every joining interface: this guide does not prescribe an unverified Steam Favorites query-port workflow.

Allow the server through the host firewall#

The host firewall controls traffic at the machine running the process. A router forward cannot grant that permission for you, and an application exception on your gaming client is not necessarily an exception for the dedicated server.

On Windows, the official manual tells you to allow the server when the firewall requests permission. Check that the rule identifies the dedicated-server executable you actually run and applies to the network profile in use. If you configure inbound port rules for the Steam route instead, match the UDP pair you recorded.

1. Identify the actual server application

   Locate the executable through the running instance’s launch configuration. Distinguish it from the game client and from an old server installation left elsewhere on disk.

2. Inspect the applicable rule

   Check the rule’s enabled state, application or UDP ports, network profile and scope. Use the permissions appropriate to the chosen backend and the machine’s network policy.

3. Check other managed firewall layers

   On Linux, inspect the firewall system that machine uses. On a VPS, check whether its provider also filters traffic outside the guest operating system. A rule in one layer does not establish permission in another.

Do not disable the firewall to make the checklist shorter. A narrowly scoped rule is easier to understand and remove when the server is retired. Likewise, a new executable path after reinstalling may require reviewing an application rule even if the port numbers have not changed.

For crossplay, skipping inbound router forwarding does not mean the application can operate without internet access. Restrictive outbound or application policies still need attention. Diagnose that policy with its administrator instead of opening an arbitrary inbound range.

Forward the Steam pair to a stable local address#

For a Steam server behind a home router, forward the UDP pair to the local address of the server machine. This tells the router where unsolicited incoming traffic for those ports belongs. It does not replace the host firewall rule.

Router interfaces differ, so match the fields by their purpose rather than hunting for one universal menu label. Record the existing configuration before changing it, especially if someone else maintains the network.

1. Reserve the server's local address

   Use the router’s DHCP reservation controls to keep the server machine at a stable private address. Verify the device identity and its current address; do not point the rule at the computer you happen to be browsing from.

2. Create the UDP mapping

   For the default setup, set the external range to 2456–2457 and the internal range to 2456–2457, targeting the reserved server address. If the interface accepts single ports only, create the two matching entries.

3. Save and inspect the resulting rule

   Confirm UDP, the correct destination and both port numbers. For a custom base, substitute its complete pair. Keep external and internal ports identical for this simple setup.

The private destination in that rule is not the address you send an outside friend. It identifies the machine inside your network. The friend’s Steam internet test uses the public address and configured base port, covered below.

An unresolved upstream restriction is a reason to investigate the ISP arrangement or consider the native relay. Use the no-forwarding route checklist for CGNAT and router restrictions to evaluate that choice before paying for a tunnel. Keep those alternatives separate from whether you typed the local rule correctly.

Use crossplay relay without router forwarding#

Choose native crossplay when it fits your crew’s platforms and you want the documented relay route. The official manual says this backend does not require port forwarding. That option is available to self-hosters; renting a server is not a prerequisite for using it.

Enable the crossplay argument in the real launch configuration, restart appropriately and read the current startup output. Keep the configured port recorded: the manual says it still distinguishes multiple servers using the same public address. Do not erase working instance settings simply because the router-forwarding step disappears.

The relay changes the joining test as well. The manual supports a public address with port, a join code or the server list, and explicitly excludes local and loopback addresses. A client sitting beside the server must still use a documented crossplay route.

Platform compatibility is a separate check. Iron Gate’s September 18 patch 1.0.15 notice says crossplay remains functional during its staggered rollout. That dated statement is not proof that your particular clients, permissions or mods work together. Consult subsequent official notices when testing, and do not declare incompatibility from differing visible patch numbers alone.

If your goal is to stop maintaining the host machine and its network, we recommend Game Hosting’s Valheim servers with an integrated panel and free backups. A rental changes who operates the infrastructure; Valheim’s native crossplay relay also works for self-hosters, and changing hosts cannot repair a platform compatibility issue.

Choose the right endpoint for the test#

Match the endpoint to both the backend and the client’s location. An address that makes sense on your LAN can be meaningless to a friend elsewhere, and crossplay excludes local IP joining altogether.

Share the base port with the address, not the entire two-port range. The range belongs in your network configuration. Use your real address; an example private address copied from a guide cannot identify your server.

For consoles, the official crossplay FAQ documents joining with a code. Use the current client interface and a code from the running instance. This is not a claim that every console has identical menu labels or that codes are the only supported route.

A generic TCP port checker does not test this UDP game connection. Likewise, appearing in a list does not prove a player can finish joining, and a startup readiness message does not prove the internet path is open. Keep those observations as separate pieces of evidence. The useful acceptance result is entry into the intended world through the intended route.

Confirm access from outside your network#

Finish with a friend on another network, using a supported client and the joining route you intend the crew to use. These are checks for your environment, not results we obtained on your behalf.

1. Confirm the intended instance is running

   Inspect the current launch configuration and startup output. The official manual identifies Game server connected as its readiness message. Record the backend, configured base port and selected world before sending connection details.

2. Have the outside player join

   Send the endpoint appropriate to that backend and the server password privately. Ask the player to enter the world, then confirm you can see each other in the intended location. Test each platform your mixed-platform crew actually needs.

3. Repeat after a controlled restart

   Stop and restart through the documented server procedure. Confirm the same configuration returns, obtain current joining details and have the outside player reconnect. A one-time join does not verify the configuration survives your normal restart.

4. Keep a short acceptance record

   Record the date, server and client versions, platform, backend, base port, endpoint type and result. Keep passwords and private connection details out of public support posts.

If the server never becomes ready, start with its launch output. If Steam works locally but the outside test fails, inspect the public route and both filtering layers. If crossplay fails, first exclude a local or loopback endpoint and review current platform notices. Those observations narrow the next investigation without opening more ports at random.

Change one relevant setting, record it and repeat the same test. Once the outside player can reliably enter the correct world after a restart, save the working map with your server notes: backend, UDP pair where applicable, machine destination and tested joining route.