A running Valheim process does not prove that its crossplay session is reachable. Start with the players' platforms and versions, then check the backend the server actually started, its current registration and the join method. Changing firewalls before identifying that route often leaves the original failure untouched.
This guide covers an existing dedicated server and the stable 1.0 release family, with sources checked on October 17, 2026. Linux examples use the valheim systemd service from our Ubuntu setup guide. Substitute your service name if it differs.
Check the current platform rollout first#
There is a concrete reason to check this before changing the server. Iron Gate's October 15 patch 1.0.20 announcement warns that a delayed Mac App Store release temporarily prevents crossplay with other platforms. That announcement does not establish whether a particular player's store has caught up today. Compare the installed versions and the developer's latest platform notice.
Record each player's store/platform, displayed game version and stable or test branch. Record the dedicated server version from its startup output too. Matching a marketing label such as “1.0” is insufficient when the compatible patch has not reached every platform. Conversely, do not assume that every differently numbered hotfix breaks crossplay: follow the release's compatibility statement.
If this explains why Mac App Store players fail while Steam players join, wait for the compatible client release. Reinstalling the world or widening inbound rules will not supply that client update. Do not downgrade the only copy of an already-converted world to chase a version number.
Confirm which process owns the session#
Read the unit and the current startup log:
sudo systemctl status valheim --no-pager
sudo systemctl cat valheim
sudo systemctl show valheim -p MainPID -p ExecStart -p User -p Environment
sudo journalctl -u valheim -b -n 160 --no-pager
Open the launcher named by ExecStart. Check its final executable line for -crossplay; editing a downloaded launcher has no effect if the service invokes another copy. Keep passwords and join codes out of public diagnostic posts. A launcher can contain a password, and systemctl cat can print it if it is embedded in the unit.
The official server manual distinguishes Steam-only operation from crossplay's PlayFab relay. A mixed-platform group needs the latter. After changing the launcher, restart deliberately and inspect that startup, rather than reading a registration message left over from yesterday:
sudo systemctl restart valheim
sudo journalctl -u valheim --since '5 minutes ago' --no-pager
If startup fails, address the first relevant error. A repeating crash loop is not a connection problem players can fix. Keep the existing world and configuration intact while investigating.
Replace the saved entry with the current join route#
For a first crossplay test, use the current join code from the running session. In the client, open Join Game → Add server and enter it; this is the developer's documented code workflow. Obtain the code after the latest successful startup, rather than assuming a saved entry still points to it.
Crossplay also supports the public address or server list. It does not support a private LAN address or loopback, even when the player and server share a network. That means a failed attempt at 127.0.0.1 or 192.168.x.x does not demonstrate a broken relay. Retest with the code before changing NAT rules.
A 2025 Steam discussion illustrates the diagnostic trap: users reported different outcomes after changing crossplay or switching server-list tabs. Those reports identify symptoms, not a universal current fix. Remove a stale favorite and add the current session; record whether the failure changes from lookup to password prompt or world loading.
Separate server registration from one player's access#
If the server never establishes its relay session, inspect its outbound connectivity, DNS resolution and host/provider network restrictions. Relay access does not require forwarding the Steam game's inbound port range. Keep ordinary outbound access available; do not disable the entire firewall as a test.
If another external player joins the same session, the server's route works for that player. Compare the failing client's platform/build, network and account settings. A controlled test on another normal connection can separate a local network issue from a server-wide one. Record the result before changing VPN, filtering or router settings; avoid treating a forum's “disable VPN” advice as proof of the cause.
Console account restrictions can block cross-network play. Check the account's multiplayer/cross-network permissions, including family settings where applicable. A join code does not override them.
Check mods and admission after the route works#
Use a known vanilla client/server combination as the baseline. Iron Gate's 1.0 FAQ states that mods have no official support and consoles do not support them. A server-side mod that requires client components therefore cannot be assumed compatible with console players.
Preserve the original installation, mod configuration and save before a vanilla comparison. Test a copy or separate world: removing content mods and then saving over the only production world can create a second problem. Compare exact mod versions only after basic vanilla connectivity is established.
If connection reaches authentication but a particular player is rejected, inspect the active save directory's access lists. A populated permittedlist.txt excludes players who are not listed. Use the platform-qualified identity reported by the current server, rather than guessing from a nickname or assuming a Steam identity fits every platform. Preserve the previous list before editing.
Finish with a real join and a useful incident record#
Ask one affected player to join, enter the password and reach the expected world. Repeat from another platform if the original fault crossed platforms. Then verify one controlled restart and obtain its current connection details.
Keep the server build, client platforms/builds, timestamp, exact error, first failing stage and the change that altered the result. An active unit, visible listing or relay message alone is not the acceptance test. If the remaining failure follows one platform rollout, keep that evidence instead of repeatedly rebuilding a working server.
